How to design a DAO class? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the que开发者_C百科stion so it can be answered with facts and citations by editing this post.

Closed 4 years ago.

Improve this question

What should be the best way to design a DAO class ?

Approach#1: Design DAO class as an object.

class Customer {
//customer class
}

class CustomerDAO {
  public void saveCustomer(Customer customer) {
  //code
  }

  public Customer getCustomer(int id) {
  //code
  }
}

//Client code
class client {
  public static void main(String[] args) {

   CustomerDAO customerDAO = new CustomerDAO();
   Customer customer = new Customer();
   customerDAO.saveCustomer(customer);
  }
}

Approach#2: Design DAO class with static methods (aka static class)

class Customer {
//customer class
}

class CustomerDAO {
  public static void saveCustomer(Customer customer) {
  //code
  }

  public static Customer getCustomer(int id) {
  //code
  }
}

//Client code
class client {
  public static void main(String[] args) {

   Customer customer = new Customer();
   CustomerDAO.saveCustomer(customer);
  }
}

In approach#1, I have to create an object of DAO class in all the client code (other option is to pass the reference of DAO all around). while in approach#2, I do not have to create the object and the static methods can be designed with no state tracking.

So which approach is the best in design of DAO classes ?

---

I would recommend approach #1, but would use Spring for dependency injection rather than instantiating DAOs directly.

This way, for unit testing the client code, you can substitue mock DAOs, and verify that the correct DAOs are invoked with the appropriate arguments. (Mockito is useful here.)

If you use static methods, then unit testing is much more difficult, since static methods cannot be overridden.

---

To have more abstraction :

interface IDAO<T> {

  public save(T t);
  public T getById(int id);
  //...etc

}

then

public CustomerDao implements IDAO<Customer>{
   public save(Customer c){
        //Code here
    }
   public Customer getById(int id){
      //Code here
    }
}

and DAO tO another domain

public UniversityDao implements IDAO<University>{

     public save(University u){
       //Code here
      }
     public University getById(int id){
        //Code here
     }
}

Now the presentation layer or the main Class will contain the code like this :

IDAO  dao;
dao=new CustomerDao();
//...
dao=new UniversityDao();

---

I would go for option 1 as well but I would also recommend you to program to interfaces. Create an interface that sets which functions the DAO has to provide and then you can implement those with different classes depending on your needs.

public interface CustomerDao {
    public void saveCustomer(Customer customer);

    public Customer getCustomer(int id);
}

Then you can have class SimpleCustomerDao implements CustomerDAO {/*code here*/}.

In your main (and everywhere else you need it) you'll have:

//Note that you have an interface variable and a real class object 
CustomerDao customerDao = new SimpleCustomerDao();

You can figure out the benefits of doing this!

And yes, if you use Spring or Guice then do use Dependency Injection!

---

Refer to article how to write a generic DAO (using Spring AOP): Don't repeat the DAO!

You can find examples of generic DAO implementations for your technology stack (just google "Don't repeat the DAO my_technology").

---

I would Prefer the Layered Approach, and What This approach simply tell us is:

1. You are having your model class Customer

2. You are having a contract with client through Interface CustomerDAO

   public interface CustomerDAO{
   
       public void saveCustomer(Customer customer);
       public Customer getCustomer(int id);
   }
   

3. You are having a concrete Implementation like CustomerDAOImpl

   public class CustomerDAOImpl extends CustomerDAO{
   
       public void saveCustomer(Customer customer){
         saveCustomer(customer);
       }
   
       public Customer getCustomer(int id){
         return fetchCustomer(id);
       }
   }
   

Then Write a Manager to Manage these or Encapsulating some other DAOs like:

public class ManagerImpl extends Manager{
    CustomerDAO customerDAOObj;

    // maybe you need to collect
    // all the customer related activities here in manger
    // because Client must not bother about those things.

    UserBillingDAO userBillingDAOObj; 

    public void saveCustomer(Customer customer){
      customerDAOObj.saveCustomer(customer);
    }

    public Customer getCustomer(int id){
      return customerDAOObj.fetchCustomer(id);
    }

    // Note this extra method which is defined in 
    //UserBillingDAO which I have not shown, but you are exposing 
    //this method to your Client or the Presentation layer.

     public boolean doBillingOFCustomer(id) {
        return userBillingDAOObj.doBilling(id);
    }
}

Now the presentation layer or the main Class will contain the code like this:

public static void main(String... ar){
     Manager manager = new ManagerImpl();
     manager.saveCustomer();
    // or manager.doBillingOfCustomer(); // etc
}