Step by Step-建構自己的ORM系列-ORM改進方案思考(上)

一、開篇

      在之前的篇幅中，我們講述了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;

        }

        #region 相關Get方法

        public string ColumnName

            get

            {

                return this.columnName;

            }

        public int ColumnLength

                return this.length;

        public System.Data.DbType ColumnDbType

                return this.dbType;

    }

   具體的實體類的使用代碼如下：

  /// <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

              return this.age;

              this.age = value;

      [Validate("", 60, System.Data.DbType.String)]

      public string Name

              return this.name;

              this.name = value;

      public string Email

              return this.email;

              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中設計當中沒

有考慮到或者設計中存在不足的方面，當然由于個人能力或者水準有限，導緻的寫的内容，還不夠深入或者說是考慮的不全面，還請各位多多的指點和批

評，您的建議或者意見就是對我最大的鼓勵，謝謝！

八、系列進度

        1、 Step by Step-建構自己的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系列-執行個體

其他相關文章索引

關于ORM中隻有XML沒有映射實體的思考？期待大家的建議 關于ORM中隻有XML沒有映射實體的分析

九、下篇預告

        由于最近由于手頭的事情較多，最近也是在整理關于系統架構與設計模式方面的内容，由于什麼都是剛剛起步，目前要做的工作還有很多，目前更多

的是側重關于思考方面的内容，包括以前的知識的梳理等，是以目前并沒有加快寫部落格的内容，由于目前和一些以前的志同道合的朋友們聯合創業，當然一

切都是新的開始，我能力也不強，不出衆，但是還是想一切都自己努力來過，去做自己想做的事情，謝謝大家，我會盡快把這些系列都梳理完畢，不但是對

自己，也算對大家有個交待！

十、平台研究

      由于自己已經決定好要出來闖一闖，是以最近主要是完善平台的技術說明書及相應的資料的整理，我們的平台也已經是一個久經考驗的平台，我們推

崇的原則是，使用免費，希望大家在使用的過程中多提出寶貴的意見和建議。

      之前讀過相關平台的朋友，應該都知道這個平台的功能的強大之處，或者說是該平台的功能的易用性和高靈活性，當然平台目前也在不斷的完善中，

還希望大家多提出寶貴的意見和建議，因為有你才完美！

      相關資料與Bolg

      1、

AgileEAS官方部落格     2、 AgileEAS平台使用介紹     3、 AgileEAS官方網站       因為有你,更精彩！

作者：

IT行者-何戈洲

出處：

http://www.cnblogs.com/hegezhou_hot/

2007年大學畢業後便投入到計算機行業中，先後涉足（電信、電子商務、教育、醫療、工程建築、項目管理、房産）等行業,目前有比較豐富的技術及行業經驗，技術方面涉及（Java、Go、.NET、Python、設計模式、系統架構、PM管理流程、軟體工程、靈活開發、SOA、雲計算、大資料、區塊鍊、WF、SAAS等領域），結合業務可提供（EIP、ERP、HIS、B2B、B2C、B2B2C、CRM、OA、O2O等）業務及技術解決方案，随着時間的推移，目前已逐漸轉向管理方面，歡迎同行一起交流學習，個人平時愛好體育運動、音樂、旅遊等，向往豐富多彩的生活旅程。如有問題或建議，請多多賜教！

本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接配接，如有問題，可以通過

[email protected]

 聯系我，非常感謝。

其他聯系方式：

電話：[phone]

聯系人：何戈洲

微信聯系我：

回報文章品質，你可以通過快速通道評論：