主要解決如何將數據訪問從應用中分離出來的問題。只要和數據庫打交道的應用，都會碰到這個問題。傳統的C/S架構應用大多將數據訪問和應用的代碼糅合在一起，主要有幾個方面的問題：
o 與具體的數據庫技術緊密耦合，比如我們公司的產品是基於SQL Server的，現在就很難切換的Oracle中去，更不要說是以後的新技術——XML數據庫或面向對象數據庫；
o 應用與數據模型緊密耦合，缺少彈性。
o 難以優化，每個模塊都是由不同的程序員寫的，但是不是每個人都擅長數據庫的開發，所以造成程序的效率低下，而要優化這些代碼成本頗爲昂貴；
o 不便於維護，當程序出現問題的時候，不容易發現問題的來源——來自業務邏輯還是數據訪問邏輯；
這一部分介紹了四種模式：
o 數據訪問器
o 主動域對象
o 對象/關係映射
o 層
第一章：數據訪問器（Data Accessor）模式<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
簡述
“在單一組件內封裝物理數據訪問細節，只公開邏輯操作。應用程序代碼保留底層數據模式的知識，但是與數據訪問只能分開。”
封裝原則
o 公開邏輯操作，封裝物理操作——比如不直接使用SQL語句而用邏輯操作。
o 公開邏輯資源，封裝物理資源——可以充分利用資源，例如連接的共享。
o 封裝平臺細節——平臺無關性。
o 封裝優化細節——將優化的彈性放到數據訪問器中，而不是應用代碼中，這樣可以統一的優化。
適用性
o 需要對應用程序邏輯隱藏物理數據訪問的複雜性和平臺問題。
o 在底層物理數據庫驅動程序所提供的語義職位，需要管理另外的語義。比如應用程序級的鎖定機制。
o 需要定義多個數據訪問實現並在運行時從中選擇。
優點
o 清晰的應用程序代碼——充斥着數據訪問細節的應用程序代碼難以閱讀和維護，使用數據訪問器，可以讓應用程序代碼更加集中到它自身的業務邏輯上。
o 新數據庫特性或平臺的採用——如果數據訪問代碼分佈到整個系統中，如果要使用新的數據庫特性（例如從SQL Server平臺切換到Oracle平臺）就要瀏覽和修改整個系統的代碼，而使用數據訪問器可以將這種細節封裝到一個組件中。
o 結合優化策略——調整應用程序性能時，數據訪問代碼常常是主要的分析焦點，同樣的使用數據訪問器就可以一次引入優化策略而作用於整個系統。
o 可交換的物理數據訪問實現。
缺點
o 限制了應用程序對數據訪問的控制——要求數據訪問器設計要有足夠的通用性。
策略
o 定義通用的邏輯操作——一方面要注意通用性；另一方面也不要引入不必要的複雜性，可以通過研究用例來解決這個問題。我覺得經驗的積累也很重要。
o 留下優化和改進的位置——在開發過程中經常要犧牲功能以保證進度。
o 防止應用程序的抵消用法。
實例化
o 單件（Singleton）數據訪問器實現。
o 初始化和參數傳遞——缺點是需要在類的構造函數和操作定義一個額外的參數。
o 數據訪問器工廠。
第二章：主動域對象模式
簡述
在相關的域對象實現中封裝數據模型和數據訪問細節。主動域對象使應用程序代碼避免了與數據庫的任何直接交互。
主動是指域對象不只是簡單的表示數據，還公開了邏輯操作（初始化、刷新、保存、列表），爲它們的數據完成大多數相關的數據庫交互。操作的命名使用領域的術語命名。
適用性
需要對應用程序邏輯隱藏物理數據模型和數據訪問的複雜性。
需要在單個組件中封裝關於某個域概念的所有數據模型和數據訪問細節。
需要對應用程序邏輯隱藏數據模型的不一致性和晦澀性——遺留數據的適配。
優點
清晰的應用程序代碼
解耦應用程序代碼和數據模型
把相關的數據訪問代碼組織到單個組件中
缺點
數據訪問分佈在多個域對象中
限制了應用程序對數據訪問的控制
第三章：主動域對象模式
簡述
在單個組件中封裝域對象和關係數據之間的映射。對象/關係映射同時把應用程序代碼和域對象從底層的數據模型和數據訪問細節中分離出來。
適用性
需要嚮應用程序邏輯和域對象隱藏物理數據模式和數據訪問的複雜性。
需要在單個組件中封裝域對象映射，以便在數據模型發生變化時可以不修改應用程序代碼或者域對象定義。
需要從域對象映射到多種數據模型而不修改應用程序代碼或域對象定義的通用性。
權衡
依賴於另外的商品化產品
優點
清晰的應用程序代碼
映射到可替換的數據模型
缺點
限制了應用程序對數據訪問的控制
第四章：層
簡述
把處理數據訪問問題的正交應用程序特性疊放在遞增的抽象層中。
適用性
需要分離數據模型、數據訪問細節、域對象映射，或者其它準備獨立修改的正交特性。
都要定義多個遞增的軟件抽象層以簡化開發和維護工作。
需要建立原型或者使用存根或簡化的層實現逐步構造系統，並在以後的開發過程中填入更加靈活或者優化的實現——先讓它工作起來、然後讓它工作得更好。
優點
軟件設計分解
數據訪問特性模塊化
數據訪問細節封裝
多層實現的可插接性
缺點
曾交互和初始化的複雜性
小結
解耦模式這一部分介紹的四個模式主要解決的是將數據的持久化從應用程序邏輯中分離出來。這樣做的主要意義是使應用程序代碼變得清晰，把主要主要精力放在需求和功能方面；另一方面也實現了持久層的可替代性——依賴於接口而不依賴於實現；通過不同層次的抽象還可以保證數據訪問代碼的質量——從而保證系統的性能影響。
數據訪問器模式解決的是底層的東西——數據訪問細節的抽象。
主動域對象和對象/關係映射兩個模式解決的都是如何將數據模型從應用程序代碼中分離出來這個問題，但是它們採用了不同的方式實現對象模型和關係模型的映射，只不過一個是分散的，一個是集中的；一個自力更生、一個依賴於現成的產品（不是絕對的）。
層這個模式給出了進一步分解這個問題的方案——將抽象劃分爲若干層。
