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开发应用则是个很不错的选择。