原文:[原创].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 分布式架构开发实战五 Framework改进篇
[原创].NET 业务框架开发实战之八 业务层Mapping的选择策略
[原创].NET 业务框架开发实战之九 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”按钮，出现了如下的界面：
这是一个专门用来配置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