SDO與DAO

原文鏈接：
http://www.codefutures.com/weblog/andygrove/archives/2006/03/sdo_versus_dao.html
說明：文章版權歸作者Eta Huang和goCom社區共同所有，轉載必須註明本文作者和出處。

前不久總有人問我SDO和DAO之間的區別，我當時無法給出一個簡短的回答，所以我決定把那些小文章彙總到這裏，爲以後參考之用。
我覺得開始最好分別聽聽DAO和SDO的作者是怎麼描述各自的東東的。

摘自《Core J2EE Design Patterns - Java Blueprints》網站:
“Data Access Object (or DAO) 模式:

×將一個數據源的客戶端接口與數據訪問機制分離
×將一個特定的數據源訪問接口適配成一個通用的客戶端接口（譯者按：Java中就是JDBC啦 ）
DAO模式使得數據訪問機制可以獨立於訪問數據的代碼進行變動。 ”

在SDO規範中則寫有這麼一段話：
“Service Data Objects (SDO)是一種數據編程架構和一組API。
SDO主要用於簡化數據編程，讓開發人員能集中解決業務邏輯問題而不是底層技術（譯者按：每個規範中似乎都有這麼一套說辭，類似於十六中全會 ）
SDO通過以下手段簡化數據編程：
×統一不同類型的數據源的數據訪問編程
×提供一套一致的應用模式的支持
×讓應用、工具和框架能夠更便捷地查詢、瀏覽、綁定、更新和獲取數據的元信息。”

很顯然，DAO和SDO的目標有很多共同點. 最值得注意的一點就是:

×SDO和DAO均提供了一套語言級的API將客戶端代碼從底層數據源API中抽象出來
×SDO和DAO都可以用在任何數據源上（數據庫，XML文檔，企業系統，等等)

不過，它們之間也有一些顯著的差異：

×DAO是一種設計模式，而SDO是一個規範。這是一個相當大的差異。由於SDO是一個規範，開發商可以開發於標準兼容的工具、驅動或框架。這意味着開發者不用在項目一開始就從頭開始手工設計和編寫DAO對象的代碼，而是利用已有的SDO工具和框架以大大減少開發的時間和費用。需要一提的是，雖然有FireStorm/DAO這樣的DAO框架，但由於DAO的實現不是標準化的也沒有相應的規範，所以一些開發者不是甚喜歡這類工具。

×SDO提供了脫機模式的訪問，data graph（樹狀結構的數據對象的集合）可以脫離數據源離線修改，輕易地在分佈式服務間傳遞（以Java對象或XML文檔的方式），之後再發回到數據訪問服務層並持久化到數據源中。DAO設計模式則沒有相關的要求

×SDO 既提供了動態API，也規定了如果通過數據源的schema來生成靜態API的代碼（譯者按：即POJO和getter/setter方法生成）。這使得用戶可以在動態和靜態API訪問方式間選擇，並且可以在一個應用中同時使用兩種方式！DAO則沒有提供動態API,這樣一來爲了動態訪問數據，開發人員不得不退回到使用類似JDBC的這樣的低級API。

×SDO 提供了一套SDO的數據類型來保證不同類型的數據源和不同語言之間的可移植性和兼容性。現在SDO已經有了Java, C++, 和 PHP上的實現. DAO則是Java標準，並沒有涉及類似的話題

×SDO 特別適合與基於Service Oriented Architecture (SOA) 架構的設計模式。SDO規範的最新版本已經和SCA規範一起發佈了。SCA實現了分佈式SOA架構下服務之間的點到點互動。SCA是業界對微軟的 Indigo/WCF 戰略的強有力的迴應，也許是這兩年 SOA/Web Services 上最重要的發展。

剩下的問題顯然是何時使用DAO，何時使用SDO.

DAO對於將客戶端代碼從各種類似JDBC, EJB CMP, 或 Hibernate等持久化技術中抽象出來是一種很不錯的選擇, 它讓應用中的數據訪問代碼與底層的持久化技術（有可能被要求替換）互相隔離，同時簡化了應用的部署。當DAO代碼可以使用FireStorm/DAO這樣的工具來生成的時候，開發時間被大大減少了。

對於用於面向服務架構下的應用、多語言環境或需要以脫機方式訪問數據的情況，使用SDO開發應用則是個很不錯的選擇。