Previous    Next

The Data Access Object (DAO) Pattern

It's possible to be less ambitious in accessing an RDBMS, and not attempt to map objects directly onto data - or at least, not design business objects that require such a mapping. When we distinguish between business logic and persistence logic, we can decouple business logic from persistent storage by defining a persistence interface that business logic components can use. The Data Access Object pattern (shown in detail in ) uses an abstraction layer of ordinary Java interfaces between business logic and persistence logic components. The implementations of these interfaces handle persistence logic. The DAO pattern is described in Core J2EE Patterns, although it's really just a special case of the Strategy GoF pattern, which we discussed in . In Sun Java Center's examples, the DAO pattern is usually associated with entity beans with Bean-Managed Persistence (BMP). However, it can be used anywhere in a J2EE app. Entity beans provide a similar abstraction between business logic and persistence storage, but they lock us into one way of accessing data and one particular O/R mapping solution: the DAO pattern leaves us a choice. For example, we can use JDBC, JDO or entity beans to implement DAO interfaces. The DAO pattern also has the important advantage of working inside or outside an EJB container: often we can use the same DAO implementations in either location, which increases the flexibility of our architecture. The DAO pattern differs from entity beans or O/R mapping approach in that:

• It isn't necessarily based around O/R mapping. Whereas O/R mapping is concerned with nouns, such as a Customer or an Invoice, persistence facades can also deal with verbs, such as "total the amounts of all invoices for a given customer". Yet a DAO implementation may use an O/R mapping approach. DAO interfaces will use domain objects (such as Customer or Invoice) as necessary as method arguments and return values, to allow database-agnostic invocation from business objects.

• It's a lightweight approach, based on good OO design principles. It uses ordinary Java interfaces, rather than special infrastructure such as that associated with entity beans.
• It does not aim to handle transactions or security, but leaves this to business logic components.
• It works with any underlying persistence technology.

With the DAO pattern the business logic determines the data access interfaces. With O/R mapping there is a risk that the data layer will dictate the working of the business logic layer. This is one of the reasons I'm skeptical about object-driven modeling. I have often seen situations where the modeling of one entity bean per RDBMS table dictates the nature of session bean code and results in excessive complexity. This is the tail wagging the dog: the point of an app is to express business rules, not work with a predetermined and possibly artificial data structure. The following two diagrams illustrate how the DAO pattern can be used to conceal very different data access strategies from a business object Both illustrate the use of a DAO implementing a MyDAO interface. The left hand diagram (Scenario 1) illustrates use of an implementation of this interface that uses JDBC. The right hand diagram (Scenario 2) illustrates use of an implementation that uses a layer of entity beans to abstract access to the RDBMS. Although the resulting architectures look very different, because the business object accesses the DAO through a fixed interface there is no need for changes in business logic to accommodate these two data access strategies.

DAOs, like business objects, are part of an app's middle tier. In , we'll look at how to implement the DAO pattern to cleanly decouple business logic from persistence logic. We'll also use this pattern in our sample app.

Previous    Next