[原创].NET 分布式架构开发实战五 Framework改进篇

.NET 分布式架构开发实战五 Framework改进篇

　　前言：本来打算这篇文章来写DAL的重构的，现在计划有点改变。之前的文章，园子里的朋友给出了不少的反馈，特别感谢金色海洋和Virus两位朋友的一些反馈。周末的这两天，对文章中开发的那个Framework做了一些改进，虽然说系列文章会慢慢的给出代码，但是这两天的一些想法让我很兴奋，迫不及待的和大家分享一下，也当是对文章中以后给出的Framework先睹为快吧。

　　系列文章链接:

[原创].NET 分布式架构开发实战之一故事起源
[原创].NET 分布式架构开发实战之二草稿设计
[原创].NET 分布式架构开发实战之三数据访问深入一点的思考
[原创].NET 分布式架构开发实战之四构建从理想和实现之间的桥梁(前篇)
[原创].NET 分布式架构开发实战五 Framework改进篇
[原创].NET 业务框架开发实战之六 DAL的重构
[原创].NET 业务框架开发实战之七业务层初步构想
[原创].NET 业务框架开发实战之八业务层Mapping的选择策略
[原创].NET 业务框架开发实战之九 Mapping属性原理和验证规则的实现策略
[原创].NET 业务框架开发实战之十第一阶段总结，深入浅出，水到渠成（前篇）
[原创].NET 业务框架开发实战之十第一阶段总结，深入浅出，水到渠成（后篇）

　　本篇文章涉及技术不多，主要是些想法(代码部分正在实现)。

　　最主要的改进主要在于业务层开发的简化。

　　大家都知道系统的核心就是业务逻辑层了，业务逻辑的代码往往得我们一行行的敲代码，而且不同的系统，每次都得一行一行的重头来写，这样的开发的效率可想而知了。基于这个原因，所以很有必要用一些工具和方法来加速开发。

　　经过这两天的思考，个人认为最大的改进就是：业务逻辑类的图形化配置。我先给出图的示例，然后再详细的说明这个思想。

　　大家知道，在一个BLL类中包含了大量的业务规则和验证规则，而且这些规则往往需要手工来写，特别是一个业务类的一些属性，要对他们的数据类型，长度，格式，状态更改跟踪，是否可以读写等进行验证，虽然说现在已经有了一些类库可以使用，如Enterprise Library中的Validation组件，但是我们还是要写代码，如果把这些规则通过图形化的拖拽的方式，或者图形的配置方式来生成C#代码，然后需要定制的部分再手动的修改，这样开发就简化多了(甚至可以把自动生成的代码和需要手写的代码分别放在partial类中，大家可以想想VS中开发Window程序时，VS就把那些自动生成的代码放到了另外的一个partial类中)。用过Enterprsie Library的朋友已经很清楚那个图形化配置工具的威力。

　　首先，来看第一个图(设计的草图)。

　　当我们新添加了一个业务类的以后，假设这个业务类的为 Product，在”解决方案”管理器中点击右键，选择”配置业务类”，就会弹出图形化的配置窗体，从草图中可以看出：

1. Properties，为业务类添加的属性。

2. DataProvider，这个配置表明了业务类使用哪个数据提供者：AdoDotNetProvider,LinqProvider,EntityFrameworkProvider.(这些Provider就是之前DAL系列文章最终会完成的那些Provider)

3. MappingType这个业务类和那个数据来源体映射，这里有两个选择：DataTable,DataEntity(Linq实体或者EF实体，DataTable 的改进是来源于金色海洋和virus，thanks)

4. MappingTypeName:这个配置项就表明这个业务类会和哪个数据来源体的属性进行映射，如，在上面选择了MappingType为DataEntity，而且选择DataEntity的名字MS_Product(通过Linq生成的实体，对应数据库中的MS_Product表)。当然，一个业务类的属性字段可能来自多个DataEntity的组合，所以，这里的MappingTypeName是多个。