Jump to content


How To Use Dao Design Pattern

  • Please log in to reply
1 reply to this topic

#1 askkhanna


    New Member

  • Members
  • Pip
  • 1 posts

Posted 03 January 2011 - 10:08 AM


Recently I came across the DAO design pattern and I'm a bit confused how to properly use it.

I have read somewhere that there should be one DAO per table and it should perform CRUD operation on that table only. DAO should be dumb object that just maps object properties with database fields and business layer uses different DAOs to complete the objects. A DAO should not call another DAO. Is this correct? I have an example where this doesn't work.

Suppose I have a three entities in my general store application: Product, Customer, and Bill.

In database I have three tables:
product(id, name, price),
customer(id, name, address),
bill(id, product_id, customer_id, date)

If I create DAOs that can access only one table and perform only CRUD operations on it, it will be simple to create ProductDAO and CustomerDAO but I can not think of how BillDAO will work. Will it only return me the productId and customerId and from business layer I again call ProductDAO to get the details of each product and the customer's name. Lets take another example, say i want to get the details of all the products bought in a particular month and name of customers who bought them. This requires join of all the tables. Which DAO should answer this query, should there be another DAO for it?

Please help me in understanding the best practices for using a DAO pattern and how to use it in multi tier architecture. What goes into business layer and what goes into DAO. Any book or tutorial suggestion will also be helpful.

Amit Khanna

#2 Sayan Mukherjee

Sayan Mukherjee

    New Member

  • Members
  • Pip
  • 2 posts

Posted 21 June 2011 - 10:00 AM

Hi Amit,

If the only job of a DAO class is to allow CRUD on the underlying data store (i.e. RDBMS table or the like), then you need to have a BillDAO to precisely do that job on Bill table.

To solve your query you should use the Association class approach.

There will be a class Customer with customer's details (name, address etc) and relevant getter methods. Also there will be a class Product with Product details (name, price etc) and the relevant getter methods.

Now you should add the association class Bill with:
  • an attribute which is an object of the Customer class
  • an attribute which is an object of the Product class
  • an attribute for the Bill ID
  • an attribute for the Bill date

Java code for this is given below:
class Bill {
    private Customer m_cust;
    private Product m_prod;
    private Integer m_nBillID;
    private String strBillDate; 
    public Integer getBillID() {
        return m_nBillID;
    public Customer getCust() {
        return m_cust;

So for any variable m_bill which is an object of the Bill class, you can get the bill id using:
and customer address using:

When you create the bill details, you will naturally have the necessary objects of Product and Customer classes in context. The idea is to just add these Customer and Product objects with the correct bill ID in the Bill class (=> association class).

This way you use the DAO classes for the CRUD actions only and the ordinary classes (Customer, Product and Bill) for your processing logic.

I guess in J2EE patterns these ordinary classes are called Transfer Object classes - but I am not sure.



0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users