Step by Step-构建本身的ORM系列-ORM改进方案思考(上)

1、开篇

      在以前的篇幅中，咱们讲述了ORM的step by Step来说述ORM的实现方案，那么下面咱们来说述下ORM关于咱们前面的设计方案的一些过程改进和

优化，包括咱们在前面的ORM中，有很大的一部份内容，咱们并无考虑或者想到的内容。这里提出来单独来分析和思考，固然若是您有更好的想法或者

思路，均可以提出来，咱们你们一块儿来实现一个比较好的ORM方案，固然能够说是重复造轮子，关键是符合本身的口味就好，目前不少的开源的ORM或者

说是微软原生的产品，都是不错的，不过仍是用本身的习惯，同时也能够加大本身对底层实现的理解，写出更优秀的代码。

2、本章简介

      本章主要是针对ORM系列中的一些方案考虑的不全面或者说是考虑不完善的部分，进行了相应的改进及思考，主要进行改进的方面有以下几点：

      一、Orm中内置验证框架的支持和日志处理。(上)

      二、Orm提供对数据权限的控制。(上)

      三、Orm支持离线事务并发机制。(上)

      四、Orm底层提供对元数据的原生支持。

      五、Orm提供内置的缓存服务支撑模块。

      六、Orm对于在对象与关系之间的互相转换过程当中的优化。

      七、Orm中提供AOP方面的接入点。

3、本章内容

       一、开篇。

       二、本章简介。

       三、本章内容。

       四、Orm中内置验证框架的支持和日志处理。

       五、Orm提供对数据权限的控制。

       六、Orm支持离线事务并发机制。

       七、本章总结。

       八、系列进度。

       九、下篇预告。

       十、平台推广。

4、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的方式就是经过动态代理的形式。在代理模式那篇也有相关的简介。

5、Orm提供对数据权限的控制

      一说权限，你们都知道，权限是一个系统必须的组成部分，而且权限没有控制好的系统，通常不能称之为一个完整的系统，或者说是不完善的系统，

权限是一个系统的基本组成部分，控制好权限，才能使系统更好的使用，才能使信息更安全，是系统的使用者协做，不然，就是一团糟，那么咱们如何来控

制数据权限呢？固然，我这里也不班门弄斧，说权限，这块不是个人强项，可是我仍是给出本人的一些思路吧，固然若是你有不错的意见和建议，请您指

导！我在此谢过了。

      通常的控制流程以下：

      

      用户登录进来后能看到本身操做的导航栏，固然这里的菜单属于业务权限的部分，尚未涉及到数据权限的部分。

      

      在这种状况下，对于不是本身建立的记录只能修改或编辑，这样的限制级别，就限制到了数据权限的级别，那么咱们如何来控制呢？固然无非是以下

的几种形式：

      

      上面是我理解的几种数据权限限制的几种控制方式，都能达到权限控制的目的，可是固然方案的选择，毕竟有好有坏，也有性能及安全和实现成本等

方面的要求，那么个人建议方案是什么呢？我理想的方案是在数据源时就进行过滤，因此我指望的方式是在ORM中内置数据权限的功能，那么具体如何来

作呢？我给出个人思路(个人思路不必定最好，或者是最笨的实现方案，那么若是你有好的，那么请你提出来)。

       

       经过这样的控制级别来达到控制数据权限的目的。

       关于用户帐户、用户角色、用户模块之间的关系，就不用详说了，你们都是比较熟悉这个方面的内容，我这里只是讲述如何在ORM中内置与数据权限

的控制方案。

       通常状况下，在ORM咱们都会内置一个回话的状态，记录固然登录用户与服务器之间创建的回话的信息，包括当前用户的我的信息等。

       咱们在处理相关数据权限的时候，咱们能够进行这样的处理。一个用户可能有多个角色，关于多个角色之间如何进行权限控制，或者角色的优先级及

每一个角色的模块设计可能都会有所不一样等。所以，咱们可能会有多种的设置形式。

       个人想法是在后台经过可视化的配置来完成对模块的权限设置，经过一个单独的权限控制表，该表用来记录，权限的控制模块，及该模块的数据的配

置方式，例如，该模块是否进行数据权限的限制，而且该模块如何限制，对于数据的增删修改及对应特殊角色的权限等等。经过这些信息，我来判断是否对

该模块进行数据权限的控制等。

       具体的过程可能以下：

       

       固然，可能我在考虑使用的易用性及其余方面还有欠缺，还请各位权限方面的高手，提出不一样的意见和建议。欢迎你们拍砖。

6、Orm支持离线事务并发机制

      以前，咱们关于离线的事务并发机制，咱们有过这个方面的陈述，一种方案是加全部的执行操做时的数据信息，经过where字句的拼写等，还有一种

方案是经过版本号的方式来作，固然通过权衡，我推荐的方式，仍是经过版本号的方式来操做会比较方便，就是在每个where语句后面都加上版本号，比

如说在执行update和delete语句的时候，都须要这样的操做。固然select语句可能就不须要这样的限定了，固然，也可能和设置的事务的级别有关，若是

设置事务的级别到-可读写(读垃圾数据)的级别的话，那么还可能会产生其余的问题，读到脏数据的状况。

       咱们以前也讲述过这个方面的方案，主要是下面的2种形式：

       一、在执行编辑或者删除操做时where条件自动加入其余的额外属性。举个例子来讲明吧：

       

       经过上面的方式，咱们就能完成并发的事务的操做控制。

       二、经过版本号的形式：例如咱们如今在数据库表设计的时候，即为每一个表添加一个版本号，固然这个就须要ORM内部的原生的支持了，这个如何去

作呢？我想咱们能够经过内部的一个方法去生成版本号，每次操做完数据，同时也要更新版本号。例如咱们的版本号的方法生成的以下：

       

       经过上面这段代码，咱们取得一个内部生成的版本号，那么咱们在实现根据版本号来更新或者删除记录时的代码以下：

       

       经过上面的这样的实现方式就能够完成离线并发的事务的控制，固然可能还有其余的比较好的可行方案，均可以请您提出来，谢谢您的答复！

7、本章总结

       本章也没有什么特别的新内容，都是基于现有的一些ORM中可能具有的实现，或者是已经包含的内容，我只是改进以前的我写的ORM中设计当中没

有考虑到或者设计中存在不足的方面，固然因为我的能力或者水平有限，致使的写的内容，还不够深刻或者说是考虑的不全面，还请各位多多的指点和批

评，您的建议或者意见就是对我最大的鼓励，谢谢！

8、系列进度

        一、Step by Step-构建本身的ORM系列-开篇

        二、Step by Step-构建本身的ORM系列-数据访问层

        三、Step by Step-构建本身的ORM系列-配置管理层

        四、Step by Step-构建本身的ORM系列-对象映射层[上]

        五、Step by Step-构建本身的ORM系列-对象映射层[中]

        六、Step by Step-构建本身的ORM系列-对象映射层[下]

        七、Step by Step-构建本身的ORM系列-测试ORM框架

        八、Step by Step-构建本身的ORM系列-瓶颈、优化

        九、Step by Step-构建本身的ORM系列-实例

其余相关文章索引

        一、关于ORM中只有XML没有映射实体的思考？期待你们的建议

        二、关于ORM中只有XML没有映射实体的分析

9、下篇预告

        因为最近因为手头的事情较多，最近也是在整理关于系统架构与设计模式方面的内容，因为什么都是刚刚起步，目前要作的工做还有不少，目前更多

的是侧重关于思考方面的内容，包括之前的知识的梳理等，因此目前并无加快写博客的内容，因为目前和一些之前的志同道合的朋友们联合创业，固然一

切都是新的开始，我能力也不强，不出众，可是仍是想一切都本身努力来过，去作本身想作的事情，谢谢你们，我会尽快把这些系列都梳理完毕，不可是对

本身，也算对你们有个交待！

10、平台研究

      因为本身已经决定好要出来闯一闯，因此最近主要是完善平台的技术说明书及相应的资料的整理，咱们的平台也已是一个久经考验的平台，咱们推

崇的原则是，使用免费，但愿你们在使用的过程当中多提出宝贵的意见和建议。

      以前读过相关平台的朋友，应该都知道这个平台的功能的强大之处，或者说是该平台的功能的易用性和高灵活性，固然平台目前也在不断的完善中，

还但愿你们多提出宝贵的意见和建议，由于有你才完美！

      相关资料与Bolg

      一、AgileEAS官方博客

    二、AgileEAS平台使用介绍

    三、AgileEAS官方网站

      由于有你,更精彩！