ORM原型概念

http://www.cnblogs.com/chenkai/archive/2011/01/06/1929040.html

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操做上理解. 若有疑問請在留言中提出.