[原创].NET 业务框架开发实战之七 业务层初步构想

时间:2021-09-28 01:01:40

原文:[原创].NET 业务框架开发实战之七 业务层初步构想

.NET 业务框架开发实战之七 业务层初步构想

前言:本篇主要讲述如何把DAL和BLL衔接起来。

  本篇议题如下:

  1.       DAL和BLL之前的Mapping

  2.       如何Mapping

  3.       再次构思

  系列文章链接:

[原创].NET 分布式架构开发实战之一 故事起源

[原创].NET 分布式架构开发实战之二 草稿设计

[原创].NET 分布式架构开发实战之三 数据访问深入一点的思考

[原创].NET 分布式架构开发实战之四 构建从理想和实现之间的桥梁(前篇)

[原创].NET 分布式架构开发实战五 Framework改进篇

[原创].NET 业务框架开发实战之六 DAL的重构

[原创].NET 业务框架开发实战之七 业务层初步构想

[原创].NET 业务框架开发实战之八 业务层Mapping的选择策略

[原创].NET 业务框架开发实战之九 Mapping属性原理和验证规则的实现策略

[原创].NET 业务框架开发实战之十 第一阶段总结,深入浅出,水到渠成(前篇)

[原创].NET 业务框架开发实战之十 第一阶段总结,深入浅出,水到渠成(后篇)

  1.       DAL和BLL之前的Mapping

首先,业务类和数据实体类不是一 一对应的关系,换句话说,不是一个业务类就一定对应数据库中的一张表。业务类是用只是使用数据实体中的数据而已,所以一个业务类中的数据往往来自多个数据实体。

每个业务类都是有自己的一些属性的,把数据以数据实体或者DataTable的形式从DAL获取之后,BLL类就使用这些数据,BLL不会把这些原生的数据实体暴露给UI。BLL类会把UI中要是用的数据装入到自己的属性中。

所以在这个过程中就有一个赋值的过程,或者称为mapping映射。当Richard提出这个想法后,项目组的同事就问他:为什么要做的这么复杂,还要一 一 的赋值,为什么不直接把数据实体给UI使用,为什么一定要在中间这么转一下呢?

Richard分析了一些原因:

1.       如果直接把数据实体给了UI,那么UI那端就很清楚DAL了,以后数据访问方式从ADO.NET 到了EF,那么UI 就动了,又回到以前了。

2.       在BLL中可以对从DAL取出来的数据进行一些处理,如转换格式,计算,组合等。

Richard想到把BLL和DAL彻底的解耦:业务类中不存在数据实体类的引用。这样设计之后灵活性就很大了。最后达到的效果就是:通过配置,配置业务类每个属性的数据的来源。而这个业务类完全不知道这些数据到底来源于哪个或者哪些数据实体。

这样确实很灵活,Richard兴奋不已。

  2. 如何Mapping

  初步想法通过配置文件。如现在有一个Product的业务类,定义如下:

[原创].NET 业务框架开发实战之七 业务层初步构想代码
    public class ProductBL
    {

        public string ProductName { get; set; }

        public decimal Price { get; set; }

        public string Description { get; set; }        

    }

  那么如何给这些属性赋值,同时也不引用数据实体。Richard用配置文件来实现的,这里Richard就约定了:配置文件的名字就是“业务类的名字”+“Mapping.xml”.所以Product的配置文件就是ProductBLMapping.xml

[原创].NET 业务框架开发实战之七 业务层初步构想代码
<?xml version="1.0" encoding="utf-8" ?>
<BusinessModel name="ProductBL" mappingTo="DAL.ProductEntity" >
  <property name="ProductName" mappingTo="Name" type="System.String"/>
  <property name="Price" mappingTo="Price" type="System.Decimal"/>
  <property name="Description" mappingTo="Description" type="System.String"/>
</BusinessModel>

  然后再运行的时候就通过反射来赋值。

  现在问题又来了:

  1.       每次都是通过反射来赋值,性能很成问题。

  2.       如果配置文件出错,调试很不方便。

  3.       如何处理一个业务类对应对个数据实体的情况,如:

[原创].NET 业务框架开发实战之七 业务层初步构想代码
    public class ProductBL
    {
        public string ProductName { get; set; }
        public decimal Price { get; set; }
        public string Description { get; set; }

        //来自CustomDAL
        public string CustomerName { get; set; }

    }

  但是好处很明显:

  1.       DAL和BLL解耦

  2.   很便于查询对象的实现。例如:在UI代码写:

ICriteria condition=CriteriaFactory.Create(typeof(ProductBL).Where("ProductName", Operation.Equal,"book");

  当然ProductName是业务类ProductBL的属性,在查询对象最后解析为SQL语句的时候就可以利用ProductBLMapping.xml来生成SQL。

  (注:小洋请大家想想,上面的思想来自于.NET中哪个开源框架?)

 

  对于性能方面,Richard尝试这样解决:

在第一次Mapping的时候,就把这些mapping的信息保存在静态字典中,下次在mapping的时候,就不用再读配置文件了,而且读内存中的字典。

但是这样,随着业务类的增加,内存使用也加大,而且赋值方式还是反射。

  3.       再次构思

Richard接着考虑:如何处理一个业务类对应对个数据实体的情况?于是配置文件就改为了:

[原创].NET 业务框架开发实战之七 业务层初步构想代码
<?xml version="1.0" encoding="utf-8" ?>
<BusinessModel name="ProductBL" >
  <property name="ProductName" mappingTo="DAL.ProductEntityName" type="System.String"/>
  <property name="Price" mappingTo="DAL.ProductEntityPrice" type="System.Decimal"/>
  <property name="Description" mappingTo="DAL.ProductEntityDescription" type="System.String"/>
  <property name="CustomerName" mappingTo="DAL.CustomerEntity.Name" type="System.String"/>  
</BusinessModel>

基本的问题算是解决了,但是性能的问题依然存在。

Richard又开始考虑更加好的方式。

本篇就写到这里,谢谢各位。

下篇:.NET 业务框架开发实战之八 业务层Mapping的选择策略

 版权为小洋和博客园所有,转载请标明出处给作者。

    http://www.cnblogs.com/yanyangtian

[原创].NET 业务框架开发实战之七 业务层初步构想的更多相关文章

  1. &lbrack;原创&rsqb;&period;NET 业务框架开发实战之八 业务层Mapping的选择策略

    原文:[原创].NET 业务框架开发实战之八 业务层Mapping的选择策略 .NET 业务框架开发实战之八 业务层Mapping的选择策略 前言:在上一篇文章中提到了mapping,感觉很像在重新实 ...

  2. &lbrack;原创&rsqb;&period;NET 业务框架开发实战之十 第一阶段总结,深入浅出,水到渠成(后篇)

    原文:[原创].NET 业务框架开发实战之十 第一阶段总结,深入浅出,水到渠成(后篇) .NET 业务框架开发实战之十 第一阶段总结,深入浅出,水到渠成(后篇) 前言:接着上篇来. 系列文章链接: [ ...

  3. &lbrack;原创&rsqb;&period;NET 业务框架开发实战之九 Mapping属性原理和验证规则的实现策略

    原文:[原创].NET 业务框架开发实战之九 Mapping属性原理和验证规则的实现策略 .NET 业务框架开发实战之九 Mapping属性原理和验证规则的实现策略 前言:之前的讨论一直关注在怎么从D ...

  4. &lbrack;原创&rsqb;&period;NET 业务框架开发实战之六 DAL的重构

    原文:[原创].NET 业务框架开发实战之六 DAL的重构 .NET 业务框架开发实战之六 DAL的重构 前言:其实这个系列还是之前的".NET 分布式架构开发实战 ",之所以改了 ...

  5. &lbrack;原创&rsqb;&period;NET 分布式架构开发实战五 Framework改进篇

    原文:[原创].NET 分布式架构开发实战五 Framework改进篇 .NET 分布式架构开发实战五 Framework改进篇 前言:本来打算这篇文章来写DAL的重构的,现在计划有点改变.之前的文章 ...

  6. &lbrack;原创&rsqb;&period;NET 分布式架构开发实战之四 构建从理想和实现之间的桥梁&lpar;前篇&rpar;

    原文:[原创].NET 分布式架构开发实战之四 构建从理想和实现之间的桥梁(前篇) .NET 分布式架构开发实战之四 构建从理想和实现之间的桥梁(前篇) 前言:上一篇文章讲述了一些实现DAL的理论,本 ...

  7. &lbrack;原创&rsqb;&period;NET 分布式架构开发实战之三 数据访问深入一点的思考

    原文:[原创].NET 分布式架构开发实战之三 数据访问深入一点的思考 .NET 分布式架构开发实战之三 数据访问深入一点的思考 前言:首先,感谢园子里的朋友对文章的支持,感谢大家,希望本系列的文章能 ...

  8. &lbrack;原创&rsqb;&period;NET 分布式架构开发实战之二 草稿设计

    原文:[原创].NET 分布式架构开发实战之二 草稿设计 .NET 分布式架构开发实战之二 草稿设计 前言:本篇之所以称为草稿设计,是因为设计的都是在纸上完成的.反映了一个思考的过程. 本篇的议题如下 ...

  9. &lbrack;原创&rsqb;&period;NET 分布式架构开发实战之一 故事起源

    原文:[原创].NET 分布式架构开发实战之一 故事起源 .NET 分布式架构开发实战之一 故事起源 前言:本系列文章主要讲述一个实实在在的项目开发的过程,主要包含:提出问题,解决问题,架构设计和各个 ...

随机推荐

  1. Fluent Nhibernate and Stored Procedures

    sql:存储过程 DROP TABLE Department GO CREATE TABLE Department ( Id INT IDENTITY(1,1) PRIMARY KEY, DepNam ...

  2. java Exchanger 2

    //Listing 6-3. Using an Exchanger to Swap Buffers import java.util.ArrayList; import java.util.List; ...

  3. mapreduce执行流程

    角色描述:JobClient:执行任务的客户端JobTracker:任务调度器TaskTracker:任务跟踪器Task:具体的任务(Map OR Reduce) 从生命周期的角度来看,mapredu ...

  4. ab压力测试工具-批量压测脚本

    ab(Apache benchmark)是一款常用的压力测试工具.简单易用,ab的命令行一次只能支持一次测试.如果想要批量执行不同的测试方式,并自动对指标进行分析,那么单靠手工一条一条命令运行ab,估 ...

  5. IOS中获取文件路径的方法

    iphone沙箱模型的有四个文件夹,分别是什么,永久数据存储一般放在什么位置,得到模拟器的路径的简单方式是什么. documents,tmp,app,Library. (NSHomeDirectory ...

  6. 商业模式画布及应用 - MBA智库文档

    商业模式画布及应用 - MBA智库文档 商业模式画布及应用

  7. 看完让你彻底搞懂Websocket原理

    偶然在知乎上看到一篇回帖,瞬间觉得之前看的那么多资料都不及这一篇回帖让我对 websocket 的认识深刻有木有.所以转到我博客里,分享一下.比较喜欢看这种博客,读起来很轻松,不枯燥,没有布道师的阵仗 ...

  8. Go语言核心之美-必读

    Go语言核心之美开篇了!.不管你是新手还是一代高人,在这个系列文章中.总能找到你想要的! 博主是计算机领域资深专家并且是英语专8水平,翻译标准仅仅有三个:精确.专业.不晦涩,为此每篇文章可能都要耗费数 ...

  9. Linux配置外网访问mysql

    stream{    upstream abc{        server 192.168.8.249:3306;    }    server{        listen 9211 ; prox ...

  10. Jmeter进行接口测试

    原文地址:https://www.cnblogs.com/nancyzhu/p/8035042.html web接口测试工具: 手工测试的话可以用postman ,自动化测试多是用到 Jmeter(开 ...