對象關系映射(Object Relation Mapping，簡稱ORM，或O/RM，或O/R mapping)，用于在關系型數(shù)據庫和業(yè)務實體對象之間作一個映射。

一，什么是ORM

從效果上說，它其實是創(chuàng)建了一個可在編程語言里使用的“虛擬對象數(shù)據庫”。說白了就是把關系型數(shù)據庫封裝成業(yè)務實體對象，這樣，我們在具體的操作業(yè)務對象的時候，就不需要再去和復雜的SQL語句打交道，只需簡單的操作對象的屬性和方法。

對象關系映射(Object-Relational Mapping)提供了概念性的、易于理解的模型化數(shù)據的方法。ORM方法論基于三個核心原則：

簡單：以最基本的形式建模數(shù)據。

傳達性：數(shù)據庫結構被任何人都能理解的語言文檔化。

精確性：基于數(shù)據模型創(chuàng)建正確標準化的結構。

典型地，建模者通過收集來自那些熟悉應用程序但不熟練數(shù)據結構的人的信息開發(fā)信息的模型。建模者必須能夠用非技術專家可以理解的術語在概念層次上與數(shù)據結構進行通訊。建模者也必須能以簡單的單元分析信息，對樣本數(shù)據進行處理。ORM專門被設計為改進這種聯(lián)系。簡單的說：ORM相當于中繼數(shù)據。

二，理解ORM

對象-關系映射(Object-Relational Mapping，簡稱ORM)，是隨著面向對象的軟件開發(fā)方法發(fā)展而產生的。面向對象的開發(fā)方法是當今企業(yè)級應用開發(fā)環(huán)境中的主流開發(fā)方法，關系數(shù)據庫是企業(yè)級應用環(huán)境中永久存放數(shù)據的主流數(shù)據存儲系統(tǒng)。對象和關系數(shù)據是業(yè)務實體的兩種表現(xiàn)形式，業(yè)務實體在內存中表現(xiàn)為對象，在數(shù)據庫中表現(xiàn)為關系數(shù)據。內存中的對象之間存在關聯(lián)和繼承關系，而在數(shù)據庫中，關系數(shù)據無法直接表達多對多關聯(lián)和繼承關系。因此，對象-關系映射(ORM)系統(tǒng)一般以中間件的形式存在，主要實現(xiàn)程序對象到關系數(shù)據庫數(shù)據的映射。

面向對象是從軟件工程基本原則(如耦合、聚合、封裝)的基礎上發(fā)展起來的，而關系數(shù)據庫則是從數(shù)學理論發(fā)展而來的，兩套理論存在顯著的區(qū)別。為了解決這個不匹配的現(xiàn)象,對象關系映射技術應運而生。

讓我們從O/R開始。字母O起源于 對象(Object),而R則來自于 關系(Relational)。幾乎所有的程序里面，都存在對象和關系數(shù)據庫。在業(yè)務邏輯層和用戶界面層中，我們是面向對象的。當對象信息發(fā)生變化的時候，我們需要把對象的信息保存在關系數(shù)據庫中。

當你開發(fā)一個應用程序的時候不使用O/R Mapping,你可能會寫不少數(shù)據訪問層的代碼，用來從數(shù)據庫保存，刪除，讀取對象信息，等等。你在DAL中寫了很多的方法來讀取對象數(shù)據，改變狀態(tài)對象等等任務。而這些代碼寫起來總是重復的。

如果打開你最近的程序，看看DAL代碼，你肯定會看到很多近似的通用的模式。我們以保存對象的方法為例，你傳入一個對象，為SQLCOMMAND對象添加SQLPARAMETER，把所有屬性和對象對應，設置SQLCOMMAND的COMMANDTEXT屬性為存儲過程，然后運行SQLCOMMAND。對于每個對象都要重復的寫這些代碼。

除此之外，還有更好的辦法嗎?有，引入一個O/R Mapping。實質上，一個O/R Mapping會為你生成DAL。與其自己寫DAL代碼，不如用O/R Mapping。你用O/R Mapping保存，刪除，讀取對象，O/R Mapping負責生成SQL，你只需要關心對象就好。

一般的ORM包括以下四部分：

一個對持久類對象進行CRUD操作的API;

一個語言或API用來規(guī)定與類和類屬性相關的查詢;

一個規(guī)定Mapping METADATA的工具;

一種技術可以讓ORM的實現(xiàn)同事務對象一起進行DIRTYCHECKING, LAZY ASSOCIATION FETCHING以及其他的優(yōu)化操作。

三，ORM優(yōu)缺點

ORM自其概念被提出，就得到了無數(shù)的響應，花樣繁多的應用框架更是應接不暇。可見，他是有其獨到的優(yōu)勢的。那么他的優(yōu)勢有哪些那：

第一：

ORM最大的優(yōu)勢，隱藏了數(shù)據訪問細節(jié)，“封閉”的通用數(shù)據庫交互，ORM的核心。

他使得我們的通用數(shù)據庫交互變得簡單易行，并且完全不用考慮該死的SQL語句�？焖匍_發(fā)，由此而來。

第二：

ORM使我們構造固化數(shù)據結構變得簡單易行。在ORM年表的史前時代，我們需要將我們的對象模型轉化為一條一條的SQL語句，

通過直連或是DB helper在關系數(shù)據庫構造我們的數(shù)據庫體系。而現(xiàn)在，基本上所有的ORM框架都提供了通過對象模型構造關系數(shù)據庫結構的功能。這，相當不錯。

世上沒有驢是不吃草的(又想好又想巧,買個老驢不吃草)，任何優(yōu)勢的背后都隱藏著缺點，這是不可避免的：

第一：

無可避免的，自動化意味著映射和關聯(lián)管理，代價是犧牲性能(早期，這是所有不喜歡ORM人的共同點)。

現(xiàn)在的各種ORM框架都在嘗試使用各種方法來減輕這塊(LazyLoad，Cache)，效果還是很顯著的。

第二：

面向對象的查詢語言(X-QL)作為一種數(shù)據庫與對象之間的過渡,雖然隱藏了數(shù)據層面的業(yè)務抽象,

但并不能完全的屏蔽掉數(shù)據庫層的設計,并且無疑將增加學習成本.

第三：

對于復雜查詢，ORM仍然力不從心。雖然可以實現(xiàn)，但是不值的。視圖可以解決大部分calculated column，case ，group，having,order by, exists，但是查詢條件(a and b and not c and (d or d))。。。。。。

四，正確看待ORM

ORM為何而生

在數(shù)月以前，我有幸參加了一個公司內部的組件發(fā)布會。令我深感意外的事，一向無人關心的組件發(fā)布會這次變得人山人海，在漫長的新版本介紹之后。每個開發(fā)組長都跳出來抱怨上一個版本的問題，并且宣布與剛發(fā)布的新版本也是無法滿足他們的需要的。一切都是如此的混亂，以至領導層不得不采用鎮(zhèn)壓的方式來平息怒火沖天的人們。

在會后的那個晚上，我仔細回想了這次沖突。因為據我了解，這一系列的組件非常完美的完成了他所被期待的功能�？墒菫槭裁催�是會被抱怨如此那。

我覺得，可能，他(組件)是沒有被正確使用了。

不知道還有誰記得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構架只能是一個helper，他定位與此，而不是完整的數(shù)據持久層。他的設計者從來就沒把他定位于取代一切的超級美女。ORM致力為長久以來的程序員與”重復勞動”的戰(zhàn)爭而助拳。與任何一個helper一樣，他有自己的不足，他有優(yōu)點也有缺點。

無數(shù)的開發(fā)人員試圖將使用ORM的框架構架自己項目的數(shù)據持久層，很多人感受到了ORM的優(yōu)勢，他們歡心鼓舞。但是很不幸，也有很多人失敗或是深受蹉責。

還有許多人，無奈的編寫著很多ORM不適合作的事情。其實想一想，被自己舍棄了的以前的helper工具，難道真的一無是處了?

ORM與DB Helper Library

很多人可能都接觸過這類的helper，每個公司都有自己的helper。許多Helper提供了很多的強大的功能，封閉交互底層，實體類支持，提供SQL翻譯功能。ORM比之這些Helper只是多提供了一層，他嘗試封閉的自動化的(或是映射文件)來實現(xiàn)關聯(lián)。以前，這都是我們手打的。(靈活替換數(shù)據庫也算ORM優(yōu)點，ORM優(yōu)勢和缺點。。。(小雨))

問題就在與有些人發(fā)現(xiàn)封閉的自動化關聯(lián)滿足他們需要了，所以ORM對他而言是成功的。而有些人發(fā)現(xiàn)封閉的自動化關聯(lián)不適合他們的項目，所以ORM被詬病。

我的觀點是ORM試圖取代helper，為此提供了更多的功能。他為了應付更加嚴格和復雜的企業(yè)需求而不斷發(fā)展，在很多情況下，這些工具開始具有自身的復雜性，使得開發(fā)人員必須學習使用它們的詳細規(guī)則，并修改組成應用程序的類以滿足映射系統(tǒng)的需要，使用它們所面臨的復雜性反而蓋過了所能獲得的好處。在我們的大部分項目中Helper依然是我們構建數(shù)據持久層的主力，ORM或許在有些項目(模塊)中可以獨攬一切，但是ORM(就目前而言)無法面對一切考驗。

五，數(shù)據持久化

上面有提到很多人使用ORM的框架構架項目的數(shù)據持久層，什么事數(shù)據持久層?這就要理解數(shù)據持久化了。

理解數(shù)據持久化

數(shù)據持久化就是將內存中的數(shù)據模型轉換為存儲模型,以及將存儲模型轉換為內存中的數(shù)據模型的統(tǒng)稱. 數(shù)據模型可以是任何數(shù)據結構或對象模型,存儲模型可以是關系模型、XML、二進制流等。

狹義的理解，持久化僅僅是指把對象數(shù)據永久保存在數(shù)據庫中，數(shù)據在計算機中一般由兩個存儲地，內存為暫存，數(shù)據庫可以理解為永存;廣義的理解，持久化包括和數(shù)據庫相關的各種操作，封裝了數(shù)據訪問細節(jié)，為大部分業(yè)務邏輯提供面向對象的API。

簡單的理解持久化可以在二個層面：應用層和系統(tǒng)層：

應用層：如果關閉(shutdown)你的應用然后重新啟動則先前的數(shù)據依然存在。

系統(tǒng)層：如果關閉(shutdown)你的系統(tǒng)(電腦)然后重新啟動則先前的數(shù)據依然存在。

數(shù)據持久化好處

使用數(shù)據持久化有以下好處：

1、松散耦合，程序代碼重用性強，使持久化不依賴于底層數(shù)據庫和上層業(yè)務邏輯實現(xiàn)，更換數(shù)據庫時只需修改配置文件而不用修改代碼。

2、業(yè)務邏輯代碼可讀性強，在代碼中不會有大量的SQL語言，提高程序的可讀性。

3、持久化技術可以自動優(yōu)化，以減少對數(shù)據庫的訪問量，提高程序運行效率。

數(shù)據持久化對象的基本操作有：保存、更新、刪除、查詢等。

由此可知，數(shù)據持久層也就是與數(shù)據交互的那一層次，所以有時候有見到ORM框架介紹：是一個數(shù)據持久層(ORM)框架。

以上內容是關于理解ORM和數(shù)據持久化的介紹，要想了解更多相關信息、教育培訓內容，請隨時關注唯學網，小編會第一時間為大家更新、跟進最新信息。