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官方網站

      由於有你,更精彩！