Overview

Data access objects read and write data in databases and convert that format to value objects usable by other layers in the application. For example, PurchaseOrderDAO, a DAO in a purchasing application, reads purchase order information from a database and converts it to value objects (e.g., PurchaseOrderVO) that the rest of the application can use. PurchaseOrderDAO also uses information in PurchaseOrderVO to update or insert data in the database. The following are some methods PurchaseOrderDAO might have:

public PurchaseOrderVO getPurchaseOrder(int orderNbr);
public void savePurchaseOrder(PurchaseOrderVO order);

public PurchaseOrderVO[] getCustomerPOs(String customerId);
public PurchaseOrderVO[] getUnshippedPOs();
public PurchaseOrderVO[] getBackOrderedPOs();

Figure 12.1 illustrates the role of DAOs in the software layer hierarchy.

Figure 12.1: Using Data Access Objects Within a Layered Architecture

All logic that interprets and processes that data is in the business logic layer, not in the data access object layer. The reason for segregating data access is to limit and consolidate your exposure to changes in the data source. For example, one of my clients migrated from using Sybase to Oracle. The migration was relatively easy in applications with segregated data access. Further, from a maintenance standpoint, it was easy to locate, modify, and enhance the data access object layer to handle minor changes, such as column additions.

As discussed in chapter 5, most developers use native JDBC as a persistence mechanism. The current chapter provides some guidelines for using JDBC effectively and constructing JDBC data access objects that you can easily use in a layered architecture. For readers using entity beans or object-relational mapping tools, I illustrate how these technologies work in a layered architecture.