[原创].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的方式:就是直接一个个的赋值,如:

      

ExpandedBlockStart.gif 代码
        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方式,很清楚:在配置文件中ProductBLProductName对应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也没有一下就开发出下面的工具,一切还是处于设计阶段。

      

[原创].NET 业务框架开发实战之八 业务层Mapping的选择策略_第1张图片
      

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

 

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

 

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

[原创].NET 业务框架开发实战之八 业务层Mapping的选择策略_第2张图片
 

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

 

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

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

 

   public   string  ProductId {  get set ; }

  
this .ProductName  =  productEntity.Id;

 

 

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

ExpandedBlockStart.gif 代码
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

 

 

你可能感兴趣的:([原创].NET 业务框架开发实战之八 业务层Mapping的选择策略)