Andy Grove's Weblog

Following on from my posting Choosing a Java Persistence Strategy I decided to blog further on the topic of persistence choices that a developer must make. In this posting I will give an overview of Data Access Objects (DAO) and Object Relational Mapping (ORM) and talk about some of the differences between them.

Data Access Object (DAO)

DAO offers a very simple method of mapping Java objects to Databases. To build a Customer DAO a developer would write a Customer class which contains one attribute for each field in the customer table, and a CustomerDao class which contains methods for inserting, updating, selecting, and deleting customer rows. The CustomerDao class would typically contain JDBC code for executing the necessary SQL statements.

The DAO design pattern has the following advantages:

• Simple – can be understood by most Java developers
• Separation of data (DTO) and behaviour (DAO)
• Designed for distributed architectures (DTO classes can be passed between tiers and DAO classes can be exposed as J2EE Session Beans or Web Services)
• No runtime container required (DAO code can be unit tested on the client)
• Can result in highly efficient code if DAO code is designed to take advantage of database capabilities (stored procedures, joins, etc).

The DAO design pattern has the following disadvantages:

• Requires large volumes of implementation code to be written (unless a DAO Code Generator is being used)
• Writing code to navigate the object model requires some understanding of the database schema

Object Relational Mapping (ORM)

There are many ORM tools on the market and they provide a number of different capabilities and coding styles. Examples of ORM technologies/products include EJB, JDO and Hibernate.

When using an ORM approach it is quite common for the Java object model to be developed first (possibly using a UML tool), with relationships between classes modeled as Collections. The mapping between the Java classes and the database tables are modeled using a graphical tool and stored in configuration files that will be used by the ORM runtime.

The ORM approach has the following advantages:

• Java domain model uses natural Java programming style (uses Collections and Iterators to navigate relationships)
• ORM runtime can provide capabilities such as Caching, Auditing that would have to be hand-coded using the DAO approach

The ORM approach has the following disadvantages:

• Data and behaviour are not separated
• Façade needs to be built if the data model is to be made available in a distributed architecture
• Each ORM technology/product has a different set of APIs and porting code between them is not easy

Using DAO with ORM

It is possible to use both DAO and ORM within the same project (for instance, a DAO tier could be provided to make data available to remote clients). It is also possible to build (either by hand or using a code generator) a DAO façade onto an ORM domain model, giving the benefits of the ORM runtime and the distributed capabilities of the DAO design pattern.

Summary

DAO and ORM are both valid approaches to persistence and the choice between them needs to be considered on a per-project basis.

Resources:

• Core J2EE Patterns - Data Access Object [Sun Microsystems]
• Data Access Object Overview [CodeFutures]