全部博文(141)
分类:
2011-09-29 09:14:28
.NET 业务框架开发实战之九 Mapping属性原理和验证规则的实现策略
前言:之前的讨论一直关注在怎么从DAL中获取数据,以及数据的Mapping问题。实际上,一个业务框架最主要的作用就是简化业务逻辑的编写和开发。
本篇的议题如下:
1. 框架的借鉴
一个框架的产生不是那么简单的,有很多的问题需要Richard去考虑:
在开发的过程中,Richard 一直使用Visual Studio IDE开发。而且每次随着VS新版本的发布,总是伴随着新技术的产生。很多的时候,开发人员只是关注在新技术的使用和学习上。但是对于新技术,还有另外一 方面是很值得关注的:实现的原理,和为什么这样实现,即,思想。新技术,毫无疑问是一些大师们思考的结果,从他们的思想中借鉴,益处是很大的。
在Richard学习的过程中,有一个地方特别引起来他的关注:那就是依赖属性概念的提出,先是WPF,然后在他学习WF的时候,也看到了依赖属性的再次使用。他考虑,把依赖属性的思想使用到自己正在开发的业务框架中来。
首先,他分析了现在的依赖属性的实现方式(以WPF为例),
在Richard一直认为,一个属性的声明是很简单的,而且长期以来Richard都一直使用下面的方式:
比较而言,依赖属性最大的好处就于:给普通的属性提供更加多的信息,而且提供了更多的功能:验证,触发回调事件。当然,使用普通的属性也能达到:
相比而言,依赖的属性的方式更加优雅,而且扩展性也好。
还有一点比较重要的就是,一旦把一个属性变为依赖属性,那么.NET Framework就开始管理这个属性,如自动的验证,值的改变和跟踪。这样就把任务交给了Framework,开发人员做事情就比较方便了。
Richard想起了之前在开发业务类中遇到的问题:例如下面的代码:
很多的时候,在增加或者更新一个Product的时候,由于逻辑的需要,往往要判断ProductName不为空,而且Price要大于零等。所以每次都需要写代码判断:
问题还不止这些,如果在其他的业务类中也需要同样,而且类似的验证,那只有一行行的写类似的代码,最好的情况就是copy一些代码。
这样写代码确实很累,后面Richard也想用一些方式来改进,用到了Enterprise Library中的Validation验证模块,于是代码就变成了下面的样子:
使用声明的开发,AOP 的思想,其实这样的方式相比之前而言,确实已经很不错了。在把业务类的数据保存的时候只要调用Validation验证模块的Validate()方法就 行了。确实很方便,但是存在的问题就是:每次调用Validate()方法时候,就会把这个业务类的所有属性都会检查一遍(那些加了验证标签的属性),这 样,性能方面不好,而且还不能针对某一个属性单独的验证。
2. 综合考虑
Richard 还考虑到了另外的一点:之前一直在解决mapping的问题,说到底就是把从DAL中拿到的数据赋值给业务类的属性。而且还要基于业务类创建查询对象,最 后把查询对象解析为SQL语句,所以还要保存业务属性和DAL中数据实体属性的对应关系,即哪个业务属性对应哪个数据实体属性(也是表字段)。
综合上面的考虑,Richard决定把依赖属性的优势利用起来(自动的验证,数据改变跟踪,另外加上权限的验证),而且给依赖属性更多的元数据信息:把mapping的字段信息保存在依赖属性中。所以,现在属性的声明如下:
在上面的属性声明中,就指定从业务类(如,Product)的属性从哪个数据实体(typeof(m_Product))的哪个属性(如,Id)取值。
RegisterProperty就是把属性的信息保存在一个字典中:
Dictionary
其中PropertyInfo继承了IPropertyInfo接口。
最后的结果就是:所有业务类的mapping属性都被保存在了一个全局的静态字典中。
另外还有一个全局的静态字典用来保存每个属性所对应的验证规则:
Dictionary< IPropertyInfo,List
所有的验证规则都是从ICheckRule接口继承。
一个比较强大的属性就产生了。当然,在mapping属性中的验证只是基本的验证,还有更加复杂的业务验证将会放在其他的地方,实现方式或者类似WPF那么:采用回调,如new ValidateValueCallback(FrameworkElement.IsMarginValid)。
所以,借鉴于mapping属性就解决了三个问题:
版权为和博客园所有,欢迎转载,转载请标明出处给作者。