canonical

  ORM（Object Relational Mapping）技術為什么是有效的？對這個問題一般的答案是ORM解決了面向對象技術和關系數據庫之間的阻抗匹配問題。但是任何一種成功的技術，它的支持理由都不會是單一的。在Witrix平臺的實踐中，ORM的如下幾個特性是關鍵性的：
  1. 主鍵和對象之間的一一對應關系。在Web應用中，前臺瀏覽器持有的只能是對象的某種表示, 因此一種locator機制是最基礎的要求。
  2. Container結構。Container所擁有的信息包括其所有元素以及元素之間的關系。因為Container具有全局知識,所以它可以解決對象圖中的循環依賴問題。正是因為session中一級緩存的存在，才能在實體延遲加載的情況下保證對象引用的唯一性，保證a.b.c.a == a。在程序設計中，所有支持對象圖的Container結構都是non-trivial的，都必然是有價值的。例如spring容器在配置管理方面最重要的價值就在于可以管理循環依賴的對象創建過程。而在witrix平臺的前臺所定義的ControlManager管理器其核心作用就在于協調前臺控件之間的消息響應依賴關系。從spring的配置文件可以清楚的看出，bean的聲明過程是順序進行的，但是bean的創建過程是非順序結構的。在數學上，我們說系統的拓撲(topology)發生了變化。
   A a = new A();  B b = new B();  a.setB(b); b.setA(a);
  3. 對象作為復雜屬性的集合。關系數據庫中保存的都是原子性數據，每一列都是不可再分解的原始數據類型，數學上稱之為標量(scalar). 而ORM引擎返回的直接就是嵌套的復雜數據類型，因此不再需要一個額外的造型過程．雖然總是返回全部數據列不是很優化，但是這種強制性的較粗的處理粒度使得前臺程序可以有更多的選擇自由．
  4. 對兩兩關系的內蘊表達及充分利用．關系數據庫中所保存的是系統分解后的表示，即關系被分解了而不是被表達了，外鍵對數據關系只起到一種約束作用，它對于查詢語句的構建并沒有直接的影響．所有數據之間的關系都必須在查詢的時候明確指定出來，即調用者必須擁有數據關系的知識，而不是數據本身擁有這些知識．在如下的sql語句中
  　select * from a, b
    where a.fldA = b.fldB
    and a.fldC = 1 and b.fldD = 2
a.fldA = b.fldB 可以稱為關聯條件，而a.fldC=1可以稱作是坐標條件．SQL的復雜性很大程度上來源于我們頻繁的需要在各處指定完全一樣的關聯條件而無法把它們抽象成可復用的組分．在ORM所提供的對象空間中，對象之間的兩兩關聯只要指定一次，就可以在增刪改查等各種操作過程中起到作用，特別是在對象查詢語句中，可以通過兩兩關聯自動推導出多實體之間的關聯關系，雖然推導出的結果未必是最優化的．
　　select from a where a.fldC = 1 and a.b.fldD = 2
   在Witrix平臺中，我們做了大量的工作以確保對象上的復合屬性（例如a.b.fldD）和本征屬性(例如a.fldC)在使用上是完全等價的．這些工作的結果并不僅僅是減少了一些應用層的代碼量，它使得系統結構發生了深刻的變化．復合屬性把單表模型推進到了業務主題模型，使得單一業務對象可以聚集某一范圍內的相關結構信息,這才使得witrix的模型分解技術成為可能。因此在我們看來，HQL是hibernate價值的集中體現．
   5. POJO提供了純粹的first class的持久化結構空間．采用POJO結構可以充分利用現有語言及開發工具中的一系列基礎設施，大大降低了持久化結構的構造成本．而透明的get/set操作使得我們可以完全基于相對知識對持久化結構進行變換，在完全不依賴外部環境信息（例如數據庫連接和ResultSet界面）的情況下解決系統的主要業務結構問題．這一切成為可能在技術上都源于AOP(Aspect Oriented Programming)所引入的重新詮釋的能力，它使得我們可以將對象上的某種相對操作重新詮釋為對數據庫的相應操作．
   http://canonical.javaeye.com/blog/37064
     6. Entity具有活動能力．Entity并不是完全被動的數據容器，而是可以定義復雜動作的對象．在Witrix平臺中，后臺程序大致具有如下結構
        Entity  ---- 結構問題
      Handler ---- 業務動作定義
      BizFlow ---- 動力學問題
 Handler類似于J2EE中傳統的Service層，只是一般實現的方法要少的多．而BizFlow是某種結合了界面表示的流程引擎．基于實體結構使得系統在細粒度處具有某種活動能力，便于我們構造一些局部結構來解決問題，因而也就緩解了大量操作在Service層的堆積過程，有利于維護系統整體結構的對稱性．
    -----------    ==>   -------------|--
    -----------                               |--
    
    通過對于ORM技術的理論分析，Witrix平臺采取了一些和一般J2EE架構不同的設計．實際上目前J2EE架構下的常見的DAO模式在使用ORM技術的情況下往往不是合適的選擇，因為DAO的一般設計是封裝某個實體相關的操作，它直接破壞了ORM的container結構。原先我們只需要EntityManager.get(entityClass, id)這一通用方法既可得到各種數據實體對象，而現在需要對每種實體調用不同的Dao函數，顯然這是對系統結構的重大破壞。在Witrix平臺的設計中沒有獨立的DAO層，它通過通用的EntityDao統一完成所有對象的存取過程，而不是每個XXXManager繼承公共的Dao類。即整個系統架構中盡量維護數據存取過程的統一性而不是實現它的分散化。
　　在Witrix平臺的Workflow引擎，Wiki引擎等模塊的設計中，IWorkflowStore和IWikiStore等類的設計類似于DAO模式，是對存取方式的一種封裝。在比較復雜的模塊中，對于存取邏輯做出一定的封裝是需要的。但是注意到Store類的設計和實體框架的設計相比，其結構可分解性要相差很多，它基本上只提供對外的服務接口。如果我們能夠對于文件系統等存儲設施作出充分多的工作，我們一樣可以對于非關系數據庫的某些存取形式完成Container結構，只是這個工作量過大，而我們一般并不需要對非通用的存取結構掌握如此充分的知識。
    　實體結構隱含的擴展了系統的同時性視圖，a.b.c.a == a 所隱含表達的事實是a,b,c是同時存在的．http://canonical.javaeye.com/blog/33797　在某些時候，例如當我們需要將系統結構順序化，序列化的時候，這種同時性會成為一種障礙．因此Witrix平臺中數據同步所使用的ETL(Extract Transform Load)引擎是基于表結構（分解后信息）的，而不是基于實體結構（關聯信息）的．實際上，關系模型在某種意義上是系統分解后的必然結果，因此隨著我們對系統的理解的粒度要求越來越精細，很可能最終需要我們明確意識到關系對象本身的存在性，最終實體模型會非常近似于關系模型．只不過在實體模型級列中我們選擇的余地更大，關系模型可以看作是它的某種極限．理想的情況是在不同的時刻我們可以使用不同的關系抽象，只是受限于目前的實現技術，在系統構建時刻基礎的關系結構往往就被固化下來．