對象關(guān)系映射(Object Relation Mapping，簡稱ORM，或O/RM，或O/R mapping)，用于在關(guān)系型數(shù)據(jù)庫和業(yè)務(wù)實體對象之間作一個映射。
一，什么是ORM
從效果上說，它其實是創(chuàng)建了一個可在編程語言里使用的“虛擬對象數(shù)據(jù)庫”。說白了就是把關(guān)系型數(shù)據(jù)庫封裝成業(yè)務(wù)實體對象，這樣，我們在具體的操作業(yè)務(wù)對象的時候，就不需要再去和復(fù)雜的SQL語句打交道，只需簡單的操作對象的屬性和方法。
對象關(guān)系映射(Object-Relational Mapping)提供了概念性的、易于理解的模型化數(shù)據(jù)的方法。ORM方法論基于三個核心原則：
簡單：以最基本的形式建模數(shù)據(jù)。
傳達性：數(shù)據(jù)庫結(jié)構(gòu)被任何人都能理解的語言文檔化。
精確性：基于數(shù)據(jù)模型創(chuàng)建正確標(biāo)準(zhǔn)化的結(jié)構(gòu)。
典型地，建模者通過收集來自那些熟悉應(yīng)用程序但不熟練數(shù)據(jù)結(jié)構(gòu)的人的信息開發(fā)信息的模型。建模者必須能夠用非技術(shù)專家可以理解的術(shù)語在概念層次上與數(shù)據(jù)結(jié)構(gòu)進行通訊。建模者也必須能以簡單的單元分析信息，對樣本數(shù)據(jù)進行處理。ORM專門被設(shè)計為改進這種聯(lián)系。簡單的說：ORM相當(dāng)于中繼數(shù)據(jù)。
二，理解ORM
對象-關(guān)系映射(Object-Relational Mapping，簡稱ORM)，是隨著面向?qū)ο蟮能浖_發(fā)方法發(fā)展而產(chǎn)生的。面向?qū)ο蟮拈_發(fā)方法是當(dāng)今企業(yè)級應(yīng)用開發(fā)環(huán)境中的主流開發(fā)方法，關(guān)系數(shù)據(jù)庫是企業(yè)級應(yīng)用環(huán)境中永久存放數(shù)據(jù)的主流數(shù)據(jù)存儲系統(tǒng)。對象和關(guān)系數(shù)據(jù)是業(yè)務(wù)實體的兩種表現(xiàn)形式，業(yè)務(wù)實體在內(nèi)存中表現(xiàn)為對象，在數(shù)據(jù)庫中表現(xiàn)為關(guān)系數(shù)據(jù)。內(nèi)存中的對象之間存在關(guān)聯(lián)和繼承關(guān)系，而在數(shù)據(jù)庫中，關(guān)系數(shù)據(jù)無法直接表達多對多關(guān)聯(lián)和繼承關(guān)系。因此，對象-關(guān)系映射(ORM)系統(tǒng)一般以中間件的形式存在，主要實現(xiàn)程序?qū)ο蟮疥P(guān)系數(shù)據(jù)庫數(shù)據(jù)的映射。
面向?qū)ο笫菑能浖こ袒驹瓌t(如耦合、聚合、封裝)的基礎(chǔ)上發(fā)展起來的，而關(guān)系數(shù)據(jù)庫則是從數(shù)學(xué)理論發(fā)展而來的，兩套理論存在顯著的區(qū)別。為了解決這個不匹配的現(xiàn)象,對象關(guān)系映射技術(shù)應(yīng)運而生。
讓我們從O/R開始。字母O起源于 對象(Object),而R則來自于 關(guān)系(Relational)。幾乎所有的程序里面，都存在對象和關(guān)系數(shù)據(jù)庫。在業(yè)務(wù)邏輯層和用戶界面層中，我們是面向?qū)ο蟮摹．?dāng)對象信息發(fā)生變化的時候，我們需要把對象的信息保存在關(guān)系數(shù)據(jù)庫中。
當(dāng)你開發(fā)一個應(yīng)用程序的時候不使用O/R Mapping,你可能會寫不少數(shù)據(jù)訪問層的代碼，用來從數(shù)據(jù)庫保存，刪除，讀取對象信息，等等。你在DAL中寫了很多的方法來讀取對象數(shù)據(jù)，改變狀態(tài)對象等等任務(wù)。而這些代碼寫起來總是重復(fù)的。
如果打開你最近的程序，看看DAL代碼，你肯定會看到很多近似的通用的模式。我們以保存對象的方法為例，你傳入一個對象，為SQLCOMMAND對象添加SQLPARAMETER，把所有屬性和對象對應(yīng)，設(shè)置SQLCOMMAND的COMMANDTEXT屬性為存儲過程，然后運行SQLCOMMAND。對于每個對象都要重復(fù)的寫這些代碼。
除此之外，還有更好的辦法嗎?有，引入一個O/R Mapping。實質(zhì)上，一個O/R Mapping會為你生成DAL。與其自己寫DAL代碼，不如用O/R Mapping。你用O/R Mapping保存，刪除，讀取對象，O/R Mapping負(fù)責(zé)生成SQL，你只需要關(guān)心對象就好。
一般的ORM包括以下四部分：
一個對持久類對象進行CRUD操作的API;
一個語言或API用來規(guī)定與類和類屬性相關(guān)的查詢;
一個規(guī)定Mapping METADATA的工具;
一種技術(shù)可以讓ORM的實現(xiàn)同事務(wù)對象一起進行DIRTYCHECKING, LAZY ASSOCIATION FETCHING以及其他的優(yōu)化操作。
三，ORM優(yōu)缺點
ORM自其概念被提出，就得到了無數(shù)的響應(yīng)，花樣繁多的應(yīng)用框架更是應(yīng)接不暇�？梢�，他是有其獨到的優(yōu)勢的。那么他的優(yōu)勢有哪些那：
第一：
ORM最大的優(yōu)勢，隱藏了數(shù)據(jù)訪問細(xì)節(jié)，“封閉”的通用數(shù)據(jù)庫交互，ORM的核心。
他使得我們的通用數(shù)據(jù)庫交互變得簡單易行，并且完全不用考慮該死的SQL語句�？焖匍_發(fā)，由此而來。
第二：
ORM使我們構(gòu)造固化數(shù)據(jù)結(jié)構(gòu)變得簡單易行。在ORM年表的史前時代，我們需要將我們的對象模型轉(zhuǎn)化為一條一條的SQL語句，
通過直連或是DB helper在關(guān)系數(shù)據(jù)庫構(gòu)造我們的數(shù)據(jù)庫體系。而現(xiàn)在，基本上所有的ORM框架都提供了通過對象模型構(gòu)造關(guān)系數(shù)據(jù)庫結(jié)構(gòu)的功能。這，相當(dāng)不錯。
世上沒有驢是不吃草的(又想好又想巧,買個老驢不吃草)，任何優(yōu)勢的背后都隱藏著缺點，這是不可避免的：
第一：
無可避免的，自動化意味著映射和關(guān)聯(lián)管理，代價是犧牲性能(早期，這是所有不喜歡ORM人的共同點)。
現(xiàn)在的各種ORM框架都在嘗試使用各種方法來減輕這塊(LazyLoad，Cache)，效果還是很顯著的。
第二：
面向?qū)ο蟮牟樵冋Z言(X-QL)作為一種數(shù)據(jù)庫與對象之間的過渡,雖然隱藏了數(shù)據(jù)層面的業(yè)務(wù)抽象,
但并不能完全的屏蔽掉數(shù)據(jù)庫層的設(shè)計,并且無疑將增加學(xué)習(xí)成本.
第三：
對于復(fù)雜查詢，ORM仍然力不從心。雖然可以實現(xiàn)，但是不值的。視圖可以解決大部分calculated column，case ，group，having,order by, exists，但是查詢條件(a and b and not c and (d or d))。。。。。。
四，正確看待ORM
ORM為何而生
在數(shù)月以前，我有幸參加了一個公司內(nèi)部的組件發(fā)布會。令我深感意外的事，一向無人關(guān)心的組件發(fā)布會這次變得人山人海，在漫長的新版本介紹之后。每個開發(fā)組長都跳出來抱怨上一個版本的問題，并且宣布與剛發(fā)布的新版本也是無法滿足他們的需要的。一切都是如此的混亂，以至領(lǐng)導(dǎo)層不得不采用鎮(zhèn)壓的方式來平息怒火沖天的人們。
在會后的那個晚上，我仔細(xì)回想了這次沖突。因為據(jù)我了解，這一系列的組件非常完美的完成了他所被期待的功能�？墒菫槭裁催�是會被抱怨如此那。
我覺得，可能，他(組件)是沒有被正確使用了。
不知道還有誰記得James Elliott的那句話：
As good object-oriented developers got tired of this repetitive work,
their typical tendency towards enlightened laziness started to manifest itself
in the creation of tools to help automate the process. When working with relational databases,
the culmination of such efforts were object/relational mapping tools.
ORM構(gòu)架只能是一個helper，他定位與此，而不是完整的數(shù)據(jù)持久層。他的設(shè)計者從來就沒把他定位于取代一切的超級美女。ORM致力為長久以來的程序員與”重復(fù)勞動”的戰(zhàn)爭而助拳。與任何一個helper一樣，他有自己的不足，他有優(yōu)點也有缺點。
無數(shù)的開發(fā)人員試圖將使用ORM的框架構(gòu)架自己項目的數(shù)據(jù)持久層，很多人感受到了ORM的優(yōu)勢，他們歡心鼓舞。但是很不幸，也有很多人失敗或是深受蹉責(zé)。
還有許多人，無奈的編寫著很多ORM不適合作的事情。其實想一想，被自己舍棄了的以前的helper工具，難道真的一無是處了?
ORM與DB Helper Library
很多人可能都接觸過這類的helper，每個公司都有自己的helper。許多Helper提供了很多的強大的功能，封閉交互底層，實體類支持，提供SQL翻譯功能。ORM比之這些Helper只是多提供了一層，他嘗試封閉的自動化的(或是映射文件)來實現(xiàn)關(guān)聯(lián)。以前，這都是我們手打的。(靈活替換數(shù)據(jù)庫也算ORM優(yōu)點，ORM優(yōu)勢和缺點。。。(小雨))
問題就在與有些人發(fā)現(xiàn)封閉的自動化關(guān)聯(lián)滿足他們需要了，所以O(shè)RM對他而言是成功的。而有些人發(fā)現(xiàn)封閉的自動化關(guān)聯(lián)不適合他們的項目，所以O(shè)RM被詬病。
我的觀點是ORM試圖取代helper，為此提供了更多的功能。他為了應(yīng)付更加嚴(yán)格和復(fù)雜的企業(yè)需求而不斷發(fā)展，在很多情況下，這些工具開始具有自身的復(fù)雜性，使得開發(fā)人員必須學(xué)習(xí)使用它們的詳細(xì)規(guī)則，并修改組成應(yīng)用程序的類以滿足映射系統(tǒng)的需要，使用它們所面臨的復(fù)雜性反而蓋過了所能獲得的好處。在我們的大部分項目中Helper依然是我們構(gòu)建數(shù)據(jù)持久層的主力，ORM或許在有些項目(模塊)中可以獨攬一切，但是ORM(就目前而言)無法面對一切考驗。
五，數(shù)據(jù)持久化
上面有提到很多人使用ORM的框架構(gòu)架項目的數(shù)據(jù)持久層，什么事數(shù)據(jù)持久層?這就要理解數(shù)據(jù)持久化了。
理解數(shù)據(jù)持久化
數(shù)據(jù)持久化就是將內(nèi)存中的數(shù)據(jù)模型轉(zhuǎn)換為存儲模型,以及將存儲模型轉(zhuǎn)換為內(nèi)存中的數(shù)據(jù)模型的統(tǒng)稱. 數(shù)據(jù)模型可以是任何數(shù)據(jù)結(jié)構(gòu)或?qū)ο竽Ｐ?存儲模型可以是關(guān)系模型、XML、二進制流等。
狹義的理解，持久化僅僅是指把對象數(shù)據(jù)永久保存在數(shù)據(jù)庫中，數(shù)據(jù)在計算機中一般由兩個存儲地，內(nèi)存為暫存，數(shù)據(jù)庫可以理解為永存;廣義的理解，持久化包括和數(shù)據(jù)庫相關(guān)的各種操作，封裝了數(shù)據(jù)訪問細(xì)節(jié)，為大部分業(yè)務(wù)邏輯提供面向?qū)ο蟮腁PI。
簡單的理解持久化可以在二個層面：應(yīng)用層和系統(tǒng)層：
應(yīng)用層：如果關(guān)閉(shutdown)你的應(yīng)用然后重新啟動則先前的數(shù)據(jù)依然存在。
系統(tǒng)層：如果關(guān)閉(shutdown)你的系統(tǒng)(電腦)然后重新啟動則先前的數(shù)據(jù)依然存在。
數(shù)據(jù)持久化好處
使用數(shù)據(jù)持久化有以下好處：
1、松散耦合，程序代碼重用性強，使持久化不依賴于底層數(shù)據(jù)庫和上層業(yè)務(wù)邏輯實現(xiàn)，更換數(shù)據(jù)庫時只需修改配置文件而不用修改代碼。
2、業(yè)務(wù)邏輯代碼可讀性強，在代碼中不會有大量的SQL語言，提高程序的可讀性。
3、持久化技術(shù)可以自動優(yōu)化，以減少對數(shù)據(jù)庫的訪問量，提高程序運行效率。
數(shù)據(jù)持久化對象的基本操作有：保存、更新、刪除、查詢等。
由此可知，數(shù)據(jù)持久層也就是與數(shù)據(jù)交互的那一層次，所以有時候有見到ORM框架介紹：是一個數(shù)據(jù)持久層(ORM)框架。
以上內(nèi)容是關(guān)于理解ORM和數(shù)據(jù)持久化的介紹，要想了解更多相關(guān)信息、教育培訓(xùn)內(nèi)容，請隨時關(guān)注唯學(xué)網(wǎng)，小編會第一時間為大家更新、跟進最新信息。
據(jù)庫培訓(xùn).png)
