[原创].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方法。

　　系列文章链接:



1．第二种Mapping方法。

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

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

代码

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