比较SDO与DAO

Earlier today, I was asked to explain the difference between SDO and DAO. I did not have a short and succinct answer ready at the time so I decided to put together this short article for future reference.

I thought it would be useful to start with the descriptions of DAO and SDO from their respective creators.

From the Core J2EE Design Patterns - Java Blueprints Web site:

The Data Access Object (or DAO) pattern:

• separates a data resource's client interface from its data access mechanisms
• adapts a specific data resource's access API to a generic client interface

The DAO pattern allows data access mechanisms to change independently of the code that uses the data.

From the SDO specification:

Service Data Objects (SDO) is a data programming architecture and an API.

The main purpose of SDO is to simplify data programming, so that developers can focus on business logic instead of the underlying technology.

SDO simplifies data programming by:

• unifying data programming across data source types
• providing support for common application patterns
• enabling applications, tools and frameworks to more easily query, view, bind, update, and introspect data.

So there are some obvious similarities between the goals of DAO and SDO. Most notably:

• Both SDO and DAO provide a language-native API to abstract client code away from underlying data source APIs
• Both SDO and DAO can be used with any data source (database, XML document, enterprise system etc)

However, there are some significant differences:

• DAO is a design pattern and SDO is a specification. This is a huge difference. Because SDO is a specification, vendors can build standards-compliant tools, drivers, and frameworks. This means that rather than having developers manually design and code DAO objects from the ground up at the start of each new project it is more likely that developers will utilize existing tools and frameworks for SDO and significantly reduce development time and costs. It should be noted that tools, such as FireStorm/DAO, do exist for DAO developers today but because DAO is not standardized and is not based on a specification, these tools are not liked by some developers.
• SDO offers a disconnected model where a data graph (a hierarchical collection of data objects) can be modified offline from the data source and easily passed between distributed services (as a Java object or as an XML document) and then sent back to the Data Access Service later on where the changes will be applied to the data source. The DAO design pattern does not cater for these requirements.
• SDO offers both a dynamic API and specifies how a static API can be code-generated from the data source’s schema. This gives the user a choice between dynamic and static API access to their data and both can be used in the same application. DAO does not offer a dynamic API therefore forcing the developer to drop back down into a lower-level API, such as JDBC, whenever dynamic access is required.
• SDO defines a set of SDO data types to ensure portability between different data source types and for compatibility between languages. To date, SDO implementations exist for Java, C++, and PHP. DAO is a Java standard and does not address these issues.
• SDO is particularly well suited to applications based on the Service Oriented Architecture (SOA) design pattern. The latest version of the SDO specification was released in conjunction with the Service Component Architecture (SCA) specification. SCA enables peer-to-peer interactions between services in a distributed SOA architecture. SCA is the industry response to Microsoft’s Indigo/WCF strategy and is probably the most important development in SOA/Web Services in the past couple of years.

The most obvious question is when to use DAO and when to use SDO.

DAO is an excellent choice for abstracting away from persistence technologies such as JDBC, EJB CMP, or Hibernate, because it provides a way to insulate the data access code in an application from the underlying persistence technology (which can be then changed as required) as well as simplifying application development. When the DAO code is code generated using tools such as FireStorm/DAO then development time can be drastically reduced.

SDO is an excellent choice for applications that are used in service-oriented architectures, in environments with multiple programming languages, or where disconnected data access is required.