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

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

开始之前希望在这下面的两点上达到共识：
1.
最好不要把DAL的数据实体（Linq或者Entity Framework生成的），或者原生的DataTable暴露给UI那边（除非一定要，或者有特殊的原因）。
2.
UI使用的是BLL类（或者基于消息的Scheme格式）。

今天的议题如下：
1．第二种Mapping方法。
2．第三种Mapping方法。

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”按钮，出现了如下的界面：



[align=center] [/align]

　　这是一个专门用来配置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