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

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

　　前言：之前的讨论一直关注在怎么从DAL中获取数据，以及数据的Mapping问题。实际上，一个业务框架最主要的作用就是简化业务逻辑的编写和开发。

　　本篇的议题如下：

框架的借鉴
综合考虑

　　系列文章链接:



　　1. 框架的借鉴

　　一个框架的产生不是那么简单的，有很多的问题需要Richard去考虑：

避免重新造轮子
借鉴现有的成熟的框架的思想

在开发的过程中，Richard一直使用Visual Studio IDE开发。而且每次随着VS新版本的发布，总是伴随着新技术的产生。很多的时候，开发人员只是关注在新技术的使用和学习上。但是对于新技术，还有另外一方面是很值得关注的：实现的原理，和为什么这样实现，即，思想。新技术，毫无疑问是一些大师们思考的结果，从他们的思想中借鉴，益处是很大的。

在Richard学习的过程中，有一个地方特别引起来他的关注：那就是依赖属性概念的提出，先是WPF，然后在他学习WF的时候，也看到了依赖属性的再次使用。他考虑，把依赖属性的思想使用到自己正在开发的业务框架中来。

首先，他分析了现在的依赖属性的实现方式(以WPF为例)，

代码

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

public string ProductId
{

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

在上面的属性声明中，就指定从业务类(如，Product)的属性从哪个数据实体(typeof(m_Product))的哪个属性(如，Id)取值。

RegisterProperty就是把属性的信息保存在一个字典中：

Dictionary<Type,List< IPropertyInfo>>

其中PropertyInfo继承了IPropertyInfo接口。

最后的结果就是：所有业务类的mapping属性都被保存在了一个全局的静态字典中。

另外还有一个全局的静态字典用来保存每个属性所对应的验证规则：

Dictionary< IPropertyInfo,List<ICheckRule>>

所有的验证规则都是从ICheckRule接口继承。

一个比较强大的属性就产生了。当然，在mapping属性中的验证只是基本的验证，还有更加复杂的业务验证将会放在其他的地方，实现方式或者类似WPF那么：采用回调，如new ValidateValueCallback(FrameworkElement.IsMarginValid)。

所以，借鉴于mapping属性就解决了三个问题：

mapping和查询对象的实现
部分验证规则的声明
业务属性的管理

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

　　 http://www.cnblogs.com/yanyangtian

　　下篇讲述：.NET 业务框架开发实战之十 水到渠成，发布框架实现的第一个版本