Previous
The DAO Pattern
With this pattern, you write a class for each type of object you need to persist. For example, if your application needs to persist three types of transfer objects—ProductTO, CustomerTO, and OrderTO—you need three DAO classes, each of which takes care of an object type. Therefore, you would have the following classes: ProductDAO, CustomerDAO, and OrderDAO. The DAO suffix at the end of the class name indicates that the class is a DAO class. It is a convention that you should follow unless you have compelling reasons for not doing so.
A typical DAO class takes care of the addition, deletion, modification, and retrieval of an object, and the searching for those objects. For example, a ProductDAO class may support the following methods:
void addProduct(ProductTO product) void updateProduct(ProductTO product) void deleteProduct(int productId) ProductTO getProduct(int productId) List findProducts(SearchCriteria searchCriteria)
There are many variants of the DAO pattern. You will learn the three most common variants: from the most basic to the most flexible.
The Simplest Implementation of the DAO Pattern
In this implementation, a client instantiates the DAO class directly and call its methods. Figure 15.2 shows the ProductDAO class in this variant of the DAO pattern.
Figure 15.2: The simplest implementation of the DAO pattern
When a Struts action object wants to access product information, it instantiates the ProductDAO class and calls its methods.
The DAO Pattern with the DAO Interface
A typical Struts application has more than one DAO class. The instances of the DAO classes need a uniform way of getting a connection object to access the data source. It is therefore convenient to have a DAO interface that provides the getConnection method and a DAOBase class that provides the implementation of the method. All the DAO classes then extend the DAOBase class, as depicted in Figure 15.3.
Figure 15.3: The DAO pattern with a DAO interface
The getConnection method implementation in the DAOBase class creates a javax.sql.DataSource object and gets the data source name from a Config object (discussed in Chapter 14). You will see the getConnection method in the section, “Implementing the DAO Pattern” later in this chapter. In Chapter 16 you will see how you can cache the DataSource object.
The DAO Pattern with the Abstract Factory Pattern
Each method in the DAO class accesses the database by using an SQL statement. Unfortunately, the SQL statement varies depending on the type of database server. For example, to insert a record into a table, Oracle databases support the notion of sequences to generate sequential numbers for new records. Therefore, in Oracle, you would perform two operations: generate a sequential number and insert a new record. MySQL, by contrast, supports auto numbers that get generated when new records are inserted. In this case, the insert method will vary depending on the database that persists the data. To allow your application to support multiple databases, you can modify your DAO pattern implementation to employ the Abstract Factory pattern. Figure 15.4 shows the CustomerDAO interface that defines the methods that need to exist in a CustomerDAO object. A CustomerDAO implementation will be tied to a database type. In Figure 15.4 two implementation classes are available, CustomerDAOMySQLImpl and CustomerDAOOracleImpl, which supports persisting objects to the MySQL database and the Oracle database, respectively.
Figure 15.4: The DAO pattern with the Abstract Factory pattern