Previous
Complex Data Structure
The app15a application works with one transfer object and one DAO class. In more complex applications, you may have more than one transfer objects (such as CustomerTO, OrderTO, etc) and hence more DAO classes (CustomerDAO, OrderDAO, etc). Each DAO class is used to manipulate a type of object. In other words, the CustomerDAO class is for creating, deleting, updating, getting, and searching CustomerTO objects. In fact, the SQL statements in the CustomerDAO class only access one table, the Customers table. By the same token, the OrderDAO class would only access the Orders table.
This is an ideal situation, in which each DAO class only accesses one class. In many more complex applications, there are situations that dictate the use of a different approach. For example, suppose a requirement says that you need to display a customer details plus all their orders. How do you retrieve the data?
One simple approach is to first retrieve the customers, by using the getCustomer method of the CustomerDAO class, followed by a call to the getOrders(int customerId) method of the OrderDAO class. However, this means two database hits.
For scalability, you may want to minimize the number of database hits. It means your CustomerDAO class will need another method, getCustomerWithOrders, and the CustomerTO class will need a property of type List called orders. Whether this growth in complexity is welcome is a subject of discussion. Here are the cons of modifying the CustomerDAO and CustomerTO classes.
- The class of your transfer object will now change.
- You have a more complex SQL statement and more method in your DAO classes.
The pros are.
- You get more scalability.
- The clients use simpler code to get the added functionality. If you are to use two database hits, the client code will be more complex because you need to obtain two DAO objects, call two methods, etc.
In most cases, the performance gain justifies the slight increase in complexity of the design.