Data Access Object

Data Access Object Design Pattern

The Data Access Object (DAO) layer is an essential part of good application architecture. Business applications almost always need access to data from relational or
object databases and the Java platform offers many techniques for accessing
this data. The oldest and most mature technique is to use the Java Database Connectivity (JDBC)
API, which provides the capability to execute SQL queries against a database
and then fetch the results, one column at a time. Although this API provides
everything a developer needs to access data and to persist application state,
it is a cumbersome API to develop against – which makes a code generator particularly useful.

Java 2 Enterprise Edition (J2EE) offers a newer persistence framework in the
form of Entity Beans, a subset of the Enterprise JavaBean (EJB) framework.
Although there have been many
improvements in the more recent EJB 2.0 specification, many developers are now
looking to alternative persistence frameworks for their Data Access Objects, such as Spring DAO and Hibernate DAO.

The Benefits of Data Access Objects

The Data Access Object design pattern provides a technique for separating
object persistence and data access logic from any particular persistence
mechanism or API. There are clear benefits to this approach from an
architectural perspective. The Data Access Object approach provides flexibility to change an
application’s persistence mechanism over time without the need to re-engineer
application logic that interacts with the Data Access Object tier. For example, there may be
performance benefits in changing an application’s performance mechanism from
using Entity Beans to using direct JDBC calls from a session bean, or even a
move to an alternative persistence framework, such as the Spring Framework. Without a Data Access Object tier
in place, this sort of transition would require extensive re-engineering of
existing code.

The Data Access Object design pattern also provides a simple, consistent API for data access
that does not require knowledge of JDBC, EJB, Hibernate, or Spring interfaces. A typical Data Access Object
interface is shown below.

It is important to note that Data Access Object does not just apply to simple mappings of one object to one relational table,
but also allows complex queries to be performed and allows for stored procedures and database views to be mapped
into Java data structures.

Minimizing the Impact of Moving to Data Access Objects

CodeFutures’ objective is to minimize the importance of the main argument
against using Data Access Objects: the fact that it requires a significant amount of
repetitive source code to be produced for no immediate advantage over using
JDBC, Spring, or Hibernate directly. For many developers, this disadvantage is good
enough reason to ignore the long-term benefits of using a framework-neutral
API, especially where there are strict project deadlines. Without the code
generation advantages of FireStorm/DAO, it is not easy to justify to a project
manager or project sponsor the time and cost of manually writing DAO code,
regardless of any future benefits they may see.

Data Access Object Code Generation

CodeFutures’ solution to the manual coding problem is to automate the
production of a Data Access Object tier, as well as automating the actual implementation logic
for whichever persistence framework is deemed appropriate for an application.
This approach is easy to adopt because almost all databases use a standard
language for defining their structure (SQL).