一、开篇
在之前的篇幅中，我们讲述了ORM的step by Step来讲述ORM的实现方案，那么下面我们来讲述下ORM关于我们前面的设计方案的一些过程改进和
优化，包括我们在前面的ORM中，有很大的一部分内容，我们并没有考虑或者想到的内容。这里提出来单独来分析和思考，当然如果您有更好的想法或者
思路，都可以提出来，我们大家一起来实现一个比较好的ORM方案，当然可以说是重复造轮子，关键是符合自己的口味就好，目前很多的开源的ORM或者
说是微软原生的产品，都是不错的，不过还是用自己的习惯，同时也可以加大自己对底层实现的理解，写出更优秀的代码。
二、本章简介
本章主要是针对ORM系列中的一些方案考虑的不全面或者说是考虑不完善的部分，进行了相应的改进及思考，主要进行改进的方面有如下几点：
1、Orm中内置验证框架的支持和日志处理。(上)
2、Orm提供对数据权限的控制。(上)
3、Orm支持离线事务并发机制。(上)
4、Orm底层提供对元数据的原生支持。
5、Orm提供内置的缓存服务支撑模块。
6、Orm对于在对象与关系之间的互相转换过程中的优化。
7、Orm中提供AOP方面的接入点。
三、本章内容
1、开篇。
2、本章简介。
3、本章内容。
4、Orm中内置验证框架的支持和日志处理。
5、Orm提供对数据权限的控制。
6、Orm支持离线事务并发机制。
7、本章总结。
8、系列进度。
9、下篇预告。
10、平台推广。
四、Orm中内置验证框架的支持和日志处理
目前的方案中，没有提供对数据验证等一些关系数据库之间的安全性和完整性的验证要求，如果ORM框架中能内部支持，或者原生提供这样的实现机
制，那么无疑是个完整的方案，验证框架主要是数据的完整性和临界值等关系数据库及业务方面的数据验证。当然目前我们见到的比较多的解决方案的形
式，一是通过XML配置，二是通过特性的方式来验证，具体的形式可以参考如下形式：
我们这里给出基于特性方式实现的数据验证的解决方案思路,XML的这里不提供代码了。具体的代码如下：
public class ValidateAttribute : Attribute
{
#region 初始化参数
private string columnName;//列名
private int length;//列长度
private System.Data.DbType dbType;//列数据类型
#endregion#region 构造函数
public ValidateAttribute(string colName, int colLength, System.Data.DbType colDbType)
{
this.columnName = colName;
this.length = colLength;
this.dbType = colDbType;
}#endregion
#region 相关Get方法
public string ColumnName
{
get
{
return this.columnName;
}
}public int ColumnLength
{
get
{
return this.length;
}
}public System.Data.DbType ColumnDbType
{
get
{
return this.dbType;
}
}
#endregion
}具体的实体类的使用代码如下：
/// <summary>
/// 测试实体代码
/// </summary>
public class TestEntity
{
private int id;
private string name;
private int age;
private string email;public TestEntity(int id, string name, int age, string email)
{
this.id = id;
this.name = name;
this.age = age;
this.email = email;
}[Validate("",20,System.Data.DbType.Int32)]
public int ID
{
get
{
return this.id;
}
set
{
this.id = value;
}
}[Validate("", 20, System.Data.DbType.Int32)]
public int Age
{
get
{
return this.age;
}
set
{
this.age = value;
}
}[Validate("", 60, System.Data.DbType.String)]
public string Name
{
get
{
return this.name;
}
set
{
this.name = value;
}
}[Validate("", 60, System.Data.DbType.String)]
public string Email
{
get
{
return this.email;
}
set
{
this.email = value;
}
}
}下面我们给出日志的实现方案的思路。
一般来说，日志的处理方案，一个使用开源的免费的日志工具log4net，来很方便的书写日志，它功能强大,可配置性灵活,线程安全,对日志的输出管理
和级别管理方便。该工具通过配置文件，来很方便的配置日志写入的相关设置信息。关于log4net的相关使用，我这里就不介绍了，当然首选方案是它，有
时候可能我们不需要使用log4net或者不能使用的时候，那么我们如何很方便的写入日志呢？或者我们有时候向自定义写入的日志，那么我们的方案又如何
来做呢。
我理解的设计方案如下：
通过配置文件来配置日志的级别，来记录日志写入的日志信息的详细程度，通过特性来标记对每个方法执行过程进行监控。
我们可以通过特性来做，或者AOP的方式来截获某个对象的执行方法的过程，可以在执行这个方法的前后，来写入备注等方式来记录日志。具体的原
理如下：
上面是文字描述的一个大体的流程，下面给出完整的操作流程。
通过上面的形式就可以完成对日志的统一集成，包括，数据验证的日志，SQL执行，方法调用，错误信息，等等相关日志的写入，甚至还可以做到对
数据库发生变更时，也集成日志的写入服务。这里具体的代码我就补贴出来了，我再AOP那篇也讲述了，AOP的一些应用，当然，目前比较成熟的关于
AOP的方式就是通过动态代理的形式。在代理模式那篇也有相关的简介。
五、Orm提供对数据权限的控制
一说权限，大家都知道，权限是一个系统必须的组成部分，并且权限没有控制好的系统，一般不能称之为一个完整的系统，或者说是不完善的系统，
权限是一个系统的基本组成部分，控制好权限，才能使系统更好的使用，才能使信息更安全，是系统的使用者协作，否则，就是一团糟，那么我们如何来控
制数据权限呢？当然，我这里也不班门弄斧，说权限，这块不是我的强项，但是我还是给出本人的一些思路吧，当然如果你有不错的意见和建议，请您指
导！我在此谢过了。
一般的控制流程如下：
用户登陆进来后能看到自己操作的导航栏，当然这里的菜单属于业务权限的部分，还没有涉及到数据权限的部分。
在这种情况下，对于不是自己创建的记录只能修改或编辑，这样的限制级别，就限制到了数据权限的级别，那么我们如何来控制呢？当然无非是如下
的几种形式：
上面是我理解的几种数据权限限制的几种控制方式，都能达到权限控制的目的，但是当然方案的选择，毕竟有好有坏，也有性能及安全和实现成本等
方面的要求，那么我的建议方案是什么呢？我理想的方案是在数据源时就进行过滤，所以我期望的方式是在ORM中内置数据权限的功能，那么具体如何来
做呢？我给出我的思路(我的思路不一定最好，或者是最笨的实现方案，那么如果你有好的，那么请你提出来)。
通过这样的控制级别来达到控制数据权限的目的。
关于用户账户、用户角色、用户模块之间的关系，就不用详说了，大家都是比较熟悉这个方面的内容，我这里只是讲述如何在ORM中内置与数据权限
的控制方案。
一般情况下，在ORM我们都会内置一个回话的状态，记录当然登陆用户与服务器之间建立的回话的信息，包括当前用户的个人信息等。
我们在处理相关数据权限的时候，我们可以进行这样的处理。一个用户可能有多个角色，关于多个角色之间如何进行权限控制，或者角色的优先级及
每个角色的模块设计可能都会有所不同等。因此，我们可能会有多种的设置形式。
我的想法是在后台通过可视化的配置来完成对模块的权限设置，通过一个单独的权限控制表，该表用来记录，权限的控制模块，及该模块的数据的配
置方式，例如，该模块是否进行数据权限的限制，并且该模块如何限制，对于数据的增删修改及对应特殊角色的权限等等。通过这些信息，我来判断是否对
该模块进行数据权限的控制等。
具体的过程可能如下：
当然，可能我在考虑使用的易用性及其他方面还有欠缺，还请各位权限方面的高手，提出不同的意见和建议。欢迎大家拍砖。
六、Orm支持离线事务并发机制
之前，我们关于离线的事务并发机制，我们有过这个方面的陈述，一种方案是加所有的执行操作时的数据信息，通过where字句的拼写等，还有一种
方案是通过版本号的方式来做，当然经过权衡，我推荐的方式，还是通过版本号的方式来操作会比较方便，就是在每一个where语句后面都加上版本号，比
如说在执行update和delete语句的时候，都需要这样的操作。当然select语句可能就不需要这样的限定了，当然，也可能和设置的事务的级别有关，如果
设置事务的级别到-可读写(读垃圾数据)的级别的话，那么还可能会产生其他的问题，读到脏数据的情况。
我们之前也讲述过这个方面的方案，主要是下面的2种形式：
1、在执行编辑或者删除操作时where条件自动加入其他的额外属性。举个例子来说明吧：
通过上面的方式，我们就能完成并发的事务的操作控制。
2、通过版本号的形式：例如我们现在在数据库表设计的时候，即为每个表添加一个版本号，当然这个就需要ORM内部的原生的支持了，这个如何去
做呢？我想我们可以通过内部的一个方法去生成版本号，每次操作完数据，同时也要更新版本号。例如我们的版本号的方法生成的如下：
通过上面这段代码，我们取得一个内部生成的版本号，那么我们在实现根据版本号来更新或者删除记录时的代码如下：
通过上面的这样的实现方式就可以完成离线并发的事务的控制，当然可能还有其他的比较好的可行方案，都可以请您提出来，谢谢您的答复！
七、本章总结
本章也没有什么特别的新内容，都是基于现有的一些ORM中可能具备的实现，或者是已经包含的内容，我只是改进之前的我写的ORM中设计当中没
有考虑到或者设计中存在不足的方面，当然由于个人能力或者水平有限，导致的写的内容，还不够深入或者说是考虑的不全面，还请各位多多的指点和批
评，您的建议或者意见就是对我最大的鼓励，谢谢！
八、系列进度
2、Step by Step-构建自己的ORM系列-数据访问层
3、Step by Step-构建自己的ORM系列-配置管理层
4、Step by Step-构建自己的ORM系列-对象映射层[上]
5、Step by Step-构建自己的ORM系列-对象映射层[中]
6、Step by Step-构建自己的ORM系列-对象映射层[下]
7、Step by Step-构建自己的ORM系列-测试ORM框架
8、Step by Step-构建自己的ORM系列-瓶颈、优化
9、Step by Step-构建自己的ORM系列-实例
其他相关文章索引
九、下篇预告
由于最近由于手头的事情较多，最近也是在整理关于系统架构与设计模式方面的内容，由于什么都是刚刚起步，目前要做的工作还有很多，目前更多
的是侧重关于思考方面的内容，包括以前的知识的梳理等，所以目前并没有加快写博客的内容，由于目前和一些以前的志同道合的朋友们联合创业，当然一
切都是新的开始，我能力也不强，不出众，但是还是想一切都自己努力来过，去做自己想做的事情，谢谢大家，我会尽快把这些系列都梳理完毕，不但是对
自己，也算对大家有个交待！
十、平台研究
由于自己已经决定好要出来闯一闯，所以最近主要是完善平台的技术说明书及相应的资料的整理，我们的平台也已经是一个久经考验的平台，我们推
崇的原则是，使用免费，希望大家在使用的过程中多提出宝贵的意见和建议。
之前读过相关平台的朋友，应该都知道这个平台的功能的强大之处，或者说是该平台的功能的易用性和高灵活性，当然平台目前也在不断的完善中，
还希望大家多提出宝贵的意见和建议，因为有你才完美！
相关资料与Bolg
1、AgileEAS官方博客
2、AgileEAS平台使用介绍
3、AgileEAS官方网站
因为有你,更精彩！
本文转自何戈洲博客园博客，原文链接：http://www.cnblogs.com/hegezhou_hot/archive/2011/03/10/1980137.html，如需转载请自行联系原作者
