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

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

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

前言：在上一篇文章中提到了mapping，感觉很像在重新实现NHibernate。其实文章的本意是想反映出Richard在思考的时候的一些选择：利用现有的，还是最后自己用别的方式实现。如果一上来就说什么什么好，那太武断了，也很片面，系列文章反复的在强调一点：技术有它的适用场景，没有完美的技术。很多的朋友说本系列在近似的开发一个ORM，其实不是：ORM就是把数据库表转为数据实体，但是本篇中是使用已经转换后的数据实体。是把数据实体的数据给业务类。

而且本篇讨论业务类中的mapping，也就是数据的获取方式，当然，业务类的设计远远不止这些。

开始之前希望在这下面的两点上达到共识：

1.  最好不要把DAL的数据实体（Linq或者Entity Framework生成的），或者原生的DataTable暴露给UI那边（除非一定要，或者有特殊的原因）。

2.  UI使用的是BLL类（或者基于消息的Scheme格式）。

今天的议题如下：

1．第二种Mapping方法。

2．第三种Mapping方法。

　　系列文章链接:

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

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

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

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

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

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

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

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

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

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

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

1． 第二种Mapping方法。

Richard思考了配置文件的方式，诚然用配置文件确实灵活，但是灵活也是有代价的，因为Framework最后还得公司的开发人员使用，过多的配置和过高的学习成本使得Framework失去了很大的意义。

Richard开始思考了，想到了还有一种最简单的mapping的方式：就是直接一个个的赋值，如：

代码

       public class ProductBL
       {
         public string ProductName { get; set; }
         public decimal Price { get; set; }
         public string Description { get; set; }

         public void Mapping(m_Product productEntity)
         {
            this.ProductName = productEntity.Name;
            this.Price = productEntity.Price;
            this.Description = productEntity.Description;
         }
        }

　　很明显，这个过程很简单却很繁琐。

　　和之前使用配置文件的方式相比：

　　优点：1. 便于使用和理解

　　     2. 便于调试

　　缺点：1. 和数据实体耦合的很紧(其实这不算是缺点，这是和之前配置文件的方式比较而言认为缺点)。上面的代码中就直接使用了m_Product.（大家可以参看之前一篇文章中用配置文件的优缺点）

2. 编写的过程很繁琐。全部是手动的mapping。

　　而且还有关键的一点就是：查询对象怎么生成最终的SQL语句？

　　例如，下面的代码：

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

如果采用配置文件的mapping方式，很清楚：在配置文件中ProductBL的ProductName对应m_Product实体的Name字段，也就是对应数据库表m_Product的Name字段（因为在BLL中使用的是通过linq或者Entity Framework生成的m_Product实体）。上面的查询对象最后生成类似select * from m_Product where Name=’book’的语句。

 

      Richard想到NHibernate的实现：在NHibernate也有查询对象，在NHibernate中的查询对象的实现也是依赖NHibernate的那个mapping的配置文件的。

并不是说没有查询对象就不行，不用查询对象，用Linq和Entity Framework也是可以实现的。但是数据层就没有“以不变应万变”了的效果，而且开发人员要掌握各种的数据访问技术：ADO.NET, Linq等。（可以参看.NET 分布式架构开发实战之三 数据访问深入一点的思考一文）。

现在Richard面临的问题就是：

1. 不用配置文件mapping，这样查询对象就不好实现。

2. 手动的敲入代码mapping，重复的劳动。

Richard思考是否更好的方式解决上面的问题。于是第三种方式就产生了。

3. 第三种Mapping方法。

第三种mapping的方法就是综合了之前两种mapping的优点，而避开了他们的缺点。

Richard想到解决手动mapping的方法就是：图形化的代码生成来代替手写代码。而且要想办法保存数据库字段的一些信息。

很巧的就是：linq和EF生成的实体中的字段信息就反映了数据表字段的信息。这点可以利用起来。下面的草图是用Visio画出的，代表了Richard的想法。其实Richard也没有一下就开发出下面的工具，一切还是处于设计阶段。

Richard设计出了自动生成代码的工具（工具的开发Richard思考过了，可以采用最简单的实现方式：一个Windows程序。也想过用DSL工具开发，但是DSL得学习过程还是有点复杂的）。

注：虽然说是代码生成工具，其实一开始Richard也是想的很简单：就是一个写文本的操作。

在上面的界面中，选择要和哪个数据实体类mapping，可以通过选择“MappingName”来实现。然后点击“Properties”按钮，出现了如下的界面：

 

　　这是一个专门用来配置mapping的界面：点击“Add”按钮，添加一个业务类的属性，然后用”MappingTo”来设置这个属性的数据从数据实体类的那个字段中获取。在选择数据实体字段的时候，也把这个选中数据实体的字段信息保存起来，供给之后的查询对象使用。

基本思路Richard已经有了。现在的问题就是把上面选选中数据字段信息保存在哪里，而且还得和业务类的属性对应，例如，Id对应业务类Product的ProductId,而不是其他的属性。

在mapping的时候，一般是在业务类中定义一个属性，然后赋值：

  public string ProductId { get; set; }
  this.ProductName = productEntity.Id;

为了保存数据实体字段的信息，业务类的属性声明就改为下面了：

代码

public static readonly PropertyInfo<int> ProductIdProperty = RegisterProperty(
      typeof(Product),
      new PropertyInfo<int>("ProductId",typeof(M_Product)","Id")); 

    public string ProductId
    {

      get { return ReadProperty(ProductIdProperty); }
      set { LoadProperty(ProductIdProperty, value); }
    }

上面的代码通过生成的方式就比较方便，而且上面的属性声明还有更多其他的用途。初一看和WPF中依赖属性很像，确实思路也是从WPF借鉴而来的。这里简称“Mapping属性”。

　　今天就写到这里，真是对不住大家，因为本篇写的比较的啰嗦，而且还没有写完。下篇讲述Mapping属性的实现原理和原因，就是为什么要是用ProductIdProperty那种声明方式。

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

　　http://www.cnblogs.com/yanyangtian