[轉]ORM的優缺點

標籤：

ORM[Object-Relation-Mapping]對象關係映射. 這個名詞已經出來好幾年了.已經不陌生.  以前在項目中針對相對複雜商務邏輯時一般採用領域模型驅動方式進行業務概述,分析和建模. 其中在設計階段我第一次接觸ORM這個概念.  針對實際項目中ORM 採用的是Nhibernate實現底層資料持久化.  當然現在ORM成熟的工具已經很多了. 本篇的目的結合以往實際編程經驗.系統整理ORM原型概念.

<1>什麼是ORM?

解釋這個名詞並不難.先瞭解一下ORM由來. 其實ORM的需求真正由來是在隨著物件導向OO編程開發方法發展而產生的. 如今物件導向[Object]的OO編程已經成為企業級開發中主流開發方法. 而關係型資料庫也成為企業級應用環境中永久存放資料的主流資料存放區系統. 其實到這你應該明白. 同樣的資料一個是在實際編程中一Object物件導向方式體現, 而另外一種就是把這種記憶體對象持久化儲存到硬碟檔案上. 

由此可以說對象[Object]和關係資料是業務實體的 兩種不同表現形式.業務實體Object在記憶體中表現為對象，在資料庫中表現為關係資料.

 

 

 

 

 

 

 

記憶體中的對象之間存在關聯和繼承關係，而在資料庫中，關係資料無法直接表達多對多關聯和繼承關係。因此，對象-關係映射(ORM)系統一般以中介軟體的形式存在，主要實現程式對象到關聯式資料庫資料的映射.

這時有人會問為什麼需要ORM?

先從項目中資料流儲存形式這個角度說起. 簡單拿MVC這種分層模式.來說. Model作為資料承載實體. 在使用者介面層和商務邏輯層之間資料實現物件導向OO形式傳遞. 當我們需要通過Control層分發請求把資料持久化時我們會發現.  記憶體中的物件導向的OO如何持久化成關係型資料中儲存一條實際資料記錄呢？

物件導向是從軟體工程基本原則(如耦合、彙總、封裝)的基礎上發展起來的，而關聯式資料庫則是從數學理論發展而來的.  兩者之間是不匹配的.而ORM作為項目中介軟體形式實現資料在不同情境下資料關係映射. 對象關係映射（Object Relational Mapping，簡稱ORM）是一種為瞭解決物件導向與關聯式資料庫存在的互不匹配的現象的技術.ORM就是這樣而來的.

 

 

 

 

 

 

 

 

 

 

 

 

 

<2>ORM作用與優缺點?

ORM推出在某種程度上打破我們架構上設計.同時也帶來一些沒有使用ORM之前不曾出現問題.  但最值得肯定是編碼效率獲得一定提高.可以把更多精力和時間 從底層資料訪問層代碼重複工作中解放出來.關注程式和業務本身. 這時ORM所帶來程式員生產力提高

另外一個不得不說就是維護的成本. 以前我們用ADO.NeT搭建的龐大 複雜資料訪問層. 我想在MVC架構UI 和Control可以實現層與層之間的解耦.而資料訪問層DAtaAccess Layer卻時候關聯商務邏輯中. 當發生輕微變動時就要修改底層資料訪問層.這樣維護頻率和靈活度.大為令人詬病. 可想而知這樣維護成本也是很龐大費時費力的事情.

ORM體現特點:

<1>提高開發效率.ORM架構自動實現Entity實體的屬性與關係型資料庫欄位的映射.CRUD的工作則可以交給ORM來自動產生代碼方式實現.打打提高我們開發效率. 這樣一來也減少我們維護一個複雜 缺乏靈活性資料訪問層的成本.

<2>NOSQl資料操作.NOSQL 資料庫最近幾年才提出這個概念 主要用在一些開來源資料庫上.類似Repid DB上 而ORM中無需直接操作T_SQL語句，實現資料操作. 其實瞭解作為Hibernate的創始人，Gavin King在設計Hibernate是全然不知T_SQL如何使用. 這讓很多人汗然一把.

<3>來說說目前ORM這種模式缺點.

相信很多用過Herberate或是.NEt版本的.NHerberate的應該瞭解. 我們在搭建好項目結構後. 做好XML資料庫訪問設定檔. 然後就可以輕鬆根據資料實體EntityModel實現資料的CRUD操作. NOSQL的操作讓我們開發效率得到質的飛躍. 可是等項目中期進入測試我們DBA看到資料庫連接SQL語句 說了一句"F**k  連結這麼長的SQL是有病嗎？“ 為何這麼說呢？

假設我們DBA遇到事這樣情境. 類似我們現在做一個系統存取權限驗證. 資料庫設計表之間實現6張表關聯. 在的大資料量情況下. CRM給我們產生一些低效 訪問SQL 照成我們效能一直上不去. 雖然自動產生代碼 但你看NHerberate並不是每次產生代碼都是具有高效能滿足你的需求. 於是你的DBA那天給你說 “哪個XX某某. 你把這段訪問做一下SQL最佳化一下？” 回日:“那是NHerberate自動產生的 和我有什麼關係？” DBA:”於是很抓狂說了一句 多串連情況T_SQL會照成多次訪問死結?必須得最佳化.” 回日:“那時Nherberate自動產生的 我沒法修改啊?” DBA“直接從極度抓狂中陷入崩潰……”

上面杜撰一下一段經曆. 以前使用NHerberate使用過程說明CRM一個問題:

CRM的確定是在一定程度上犧牲了程式的執行效能和固定的思維模式.

A:首先從系統架構來說採用ORM這種方式作為底層資料訪問層.  架構多數採用多層架構方式. 系統架構分層越多 同時物件導向這種編程方式 執行效率也隨之降低. 類似一個普通支援多資料架構方式MyBatis ORM架構架構方式如：

 

 

 

 

 

 

 

 

 

 

B:效能問題.在使用CRM作為資料訪問層系統架構中. 我們大部分的資料CRUD操作交給CRM來自動產生代碼方式實現. 但是CRM內建自動產生代碼只是按照對象關係規則自動產生 不一定能滿足執行效能.類似上面出現情況. 這種情況需要使用額外工具,和配置策略來靈活實現CRM資料訪問.

如上簡單介紹ORM原型概念.搞清楚概念 才能更方面以後CRM操作上理解. 如有疑問請在留言中提出.

[轉]ORM的優缺點