持久化是將程序數據在持久狀態和瞬時狀態間轉換的機制。通俗的講，就是瞬時數據（比如內存中的數據，是不能永久保存的）持久化為持久數據（比如持久化至數據庫中，能夠長久保存）。
定義
持久化（Persistence），即把數據（如內存中的對象）保存到可永久保存的存儲設備中（如磁盤）。持久化的主要應用是將內存中的對象存儲在數據庫中，或者存儲在磁盤文件中、XML數據文件中等等。
持久化是將程序數據在持久狀態和瞬時狀態間轉換的機制。
Java數據庫連接就是一種持久化機制。文件IO也是一種持久化機制。
理解
我們這樣理解：
在一定周期內保持不變就是持久化，持久化是針對時間來說的。
數據庫中的數據就是持久化了的數據，只要你不去刪除或修改。
比如在IE瀏覽器中一次Session會話中Session對象變量也是不變的，是Session容器中持久化。
對象持久化的方式有很多種，根據周期不同有,page,Session,Application。
對象序列化機制需要將對象的狀態保存到文件中，而后能夠通過讀入對象狀態來重新構造對象，恢復程序狀態,
對象序列化的過程是對象持久化的方法之一，把對象保存到文件中。
二個層面
簡單的理解持久化可以在二個層面：應用層和系統層、
應用層
如果關閉(shutdown)你的應用然后重新啟動則先前的數據依然存在。
系統層
如果關閉(shutdown)你的系統（電腦）然后重新啟動則先前的數據依然存在。
特點
對象
持久化是一種對象服務，就是把內存中的對象保存到外存中，讓以后能夠取回。需要實現至少3個接口：
void Save(object o) 把一個對象保存到外存中
Object Load(object oid) 通過對象標識從外存中取回對象
boolExists(object oid) 檢查外存中是否存在某個對象
為什么需要持久化服務呢？那是由于內存本身的缺陷引起的：
內存掉電后數據會丟失，但有一些對象是無論如何都不能丟失的，比如銀行賬號，遺憾的是，人們還無法保證內存永不掉電。
內存過于昂貴，與硬盤、磁帶、光盤等外存相比，內存的價格要高2~3個數量級，而且維持成本也高，至少需要一直供電吧。所以即使對象不需要永久保存，也會因為內存的容量限制不能一直呆在內存中，需要持久化來緩存到外存。
市場
既然持久化服務在看得到的未來還有市場，我們就來看看如何構建一個好的持久化框架，框架是否真的好在于如何在擴展性、縮放性、重用性上取得良好的平衡：
擴展性，如果一個持久性框架不能支持用戶定義的類型，顯然不是一個好的框架。
縮放性，保存和取回對象都需要耗費cpu、帶寬、時間資源，哪一個消耗太多都不能接受。
重用性是我們建立框架的初衷，就是通過框架能夠減少一些編碼和測試的工作量。
這幾個需求往往是互相沖突的，所以關鍵是平衡。
序列化
我們先跳開一下，看看另一個類似的有用概念：序列化也是一種對象服務，就是把內存中的對象序列化成流、或者把流反序列化成對象。需要實現2個接口：
void Serialize(Stream stream,object o) 把對象序列化到流中
object Deserialize(Stream stream) 把流反序列化成對象
序列化和持久化很相似，有些人甚至混為一談，其實還是有區別的，序列化是為了解決對象的傳輸問題，傳輸可以在線程之間、進程之間、內存外存之間、主機之間進行。我之所以在這里提到序列化，是因為我們可以利用序列化來輔助持久化，可以說凡是可以持久化的對象都可以序列化，因為序列化相對容易一些（也不是很容易），所以主流的軟件基礎設施，比如.net和java，已經把序列化的框架完成了。
持久化方案可以分為關系數據庫方案、文件方案、對象數據庫方案、xml數據庫方案，現今主流的持久化方案是關系數據庫方案，關系數據庫方案不僅解決了并發的問題，更重要的是，關系數據庫還提供了持久化服務之外的價值：統計分析功能。剛才我說到，凡是可以序列化的對象都可以持久化，極端的說，我們可以只建立一個表Object(OID,Bytes)，但基本上沒有人這么做，因為一旦這樣，我們就失去了關系數據庫額外的統計分析功能。
關系數據庫和面向對象之間有一條鴻溝，因為二者模式不匹配，所以就存在一個OR映射問題。
意義
興起原因
當持久化興起的時候，逐漸形成了實體層這個概念了。hibernate,jdo,以及博客園的nbear都可謂是大名鼎鼎！有的公司不使用這種ORM框架，他們使用一些自動生成工具生成實體(例如用Codesmith生成)，并生成和該表對應的業務邏輯，于是乎感覺我們的程序好像一下子全都寫好了，下一步就輕松了，我們只要擴展業務即可了！莫非這樣真是那么方便了？在維護上真的是最便捷嗎？其它的持久層解決方案不敢說，但至少我覺得像NHibernate的鼻祖hibernate那種開發機制，在維護還是相當之麻煩呀！一個實體還得對應一個XML文件（雖說這些都可以自動生成）,但是你深入項目的時候去想想，我們的業務真能一切都可以定下來嗎？人的思想總是在變的，客戶的需求就更難以琢磨了！哪天我們要給數據庫加個字段，你想想你必須要走幾步改動？首先我們必須重新生成xml和實體，然后我們必須還得在業務邏輯中增加代碼，還得在視圖層加一個界面(如加一個input輸入框等)！講實話，加一個字段對這種orm框架的改動還是最少的，哪天假如說我們修改了哪個字段的名稱、修改了字段類型，你想想，天吶！很難想像，和這個字段關聯的程序都得改動！如果名稱改了，ok，你可以全部替換它的原先名稱，改成你新的名稱。那類型改了呢？沒辦法只能手工一個個改掉所有的賦值的類型吧？視圖層、控制層中的驗證（js驗證，業務驗證）、邏輯層、實體層，XML配置等等都必須動。搞啥個hql，這和SQL不差不多了嗎（雖然說hql，抽象了數據庫模型）？不過我想沒有程序員不懂sql的吧？況且hql對復雜的語句還是會力不從心的吧！
運用
運用NHibernate框架勢必會運用大量的反射，代價是犧牲性能。當然現今的各種ORM框架都在嘗試使用各種方法來減輕這塊（LazyLoad，Cache），效果還是很顯著的。可是我們犧牲了這么大的性能，而且我是覺得在維護上ORM還是最便捷。
真不知道為啥像hibernate這樣的框架還有一個XML配置文件？如果我真ORM的話，我不能把這些數據關系緩存起來，動態取關系不就行了嗎？這樣我不更靈活了嗎？
當然使用ORM也有它的活的活之處，在維護上那種自動生成的方式(petshop模式)比使用ORM框架維護量上更大一些，那種構架如果是每個數據操作對應一個存儲過程的改動會更會讓人暈頭轉向的。其構架大致如以下描述：
主要由BLL,MODEL,DAL三層構架方式實現，BLL存放的是相關業務，MODEL是相關的數據庫表格實體，DAL業務的SQL（或存儲過程參數）.為了松散耦合，在BLL層和DAL層中間加入了工廠層(Factory)，其作用是方便DAL層的載體變動(如把Sqlserver改成Mysql),在DAL層有一個setObject數據庫字段到實體屬性設置，便于數據庫表格映射成實體。
程序編寫的最大問題就是耦合高，怎么降耦也是開發的一個重中之重。以上述的程序構架來看，如果我改動了數據庫中的其中一個表格的某個字段，程序改動的至少就有三層。如果再按照自動生成方式那種看，DAL中的update,insert,select, setObject都需要改動，如果存在存儲過程的話，像get,getAll,update,insert都必須改動，想象一下這里改動地方有幾處了？而且還需改動Model層，修改量之大可見一斑。當然我們這里可以用自動生成工具生成并替換，可又有誰知道這里面的替換工作量多少?
總之，提倡"高內聚，低耦合"是構架永恒的話題，尋找便捷亦是構架的終級目標。
相關實現
Hibernate
hibernate為應用程序提供了高效的O/R關系映射和查詢服務，為面向對象的領域模型到傳統的關系型數據庫的映射，提供了一個使用方便的框架。
JPA
JPA（Java Persistense API）是EJB3.0的一部分，為其提供了一套O/R關系映射的API，但不僅限于EJB中使用，它也可以在web應用或者應用程序客戶端中被使用，甚至在Java桌面程序中被使用。
Mybatis也是一種orm框架。
參考資料 >
Hibernate中所有包作用詳細講解.李巖的博客.2013-03-21