Comment concevoir une classe DAO?

Question

Ce qui devrait être le meilleur moyen de concevoir une classe DAO ?

Approche n ° 1: Conception DAO classe comme un objet.

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);
  }
}

Approche n ° 2: la Conception DAO classe avec des méthodes statiques (aka statique de la classe)

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);
  }
}

En approche#1, je dois créer un objet de la classe DAO dans tout le code du client (autre option est de passer la référence de DAO tout autour). alors que dans l'approche n ° 2, je n'ai pas à créer l'objet et les méthodes statiques peuvent être conçus avec pas de suivi de l'état.

Donc l'approche qui est le meilleur dans la conception des classes DAO ?

Answer 1

Je recommanderais l'approche n ° 1, mais utiliserais Spring pour l'injection de dépendance plutôt que d'instancier directement les DAO.

Ainsi, pour tester le code client par unité, vous pouvez substituer des DAO factices et vérifier que les DAO correctes sont appelées avec les arguments appropriés. (Mockito est utile ici.)

Si vous utilisez des méthodes statiques, le test unitaire est beaucoup plus difficile, car les méthodes statiques ne peuvent pas être remplacées.

Answer 2

Pour avoir plus d'abstraction:

 interface IDAO<T> {

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

}
 

puis

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

et DAO vers un autre domaine

 public UniversityDao implements IDAO<University>{

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

Maintenant, la couche de présentation ou la classe principale contiendra le code suivant:

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

Answer 3

Je voudrais aller pour l'option 1, mais je ne vous recommandons également de programmer des interfaces. Créer une interface qui définit les fonctions de la DAO a à offrir et ensuite vous pouvez mettre en œuvre ces différentes classes en fonction de vos besoins.

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

    public Customer getCustomer(int id);
}

Ensuite, vous pouvez avoir class SimpleCustomerDao implements CustomerDAO {/*code here*/}.

Dans votre main (et partout où vous en avez besoin), vous aurez:

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

Vous pouvez comprendre les avantages de le faire!

Et oui, si vous utilisez le Printemps ou Guice faire utiliser l'Injection de Dépendance!

Answer 4

Reportez-vous à l'article sur la façon d'écrire un DAO générique (à l'aide de Spring AOP): Ne répétez pas les opérations DAO!

Vous pouvez trouver des exemples d’implémentations DAO génériques pour votre pile technologique (par exemple, Google "Ne répétez pas DAO ma_technologie").

Answer 5

Je Préfère l'Approche en Couches, et Que Cette démarche consiste à nous dire, c'est:

1. Vous avez votre modèle à la Clientèle de classe

2. Vous avez un contrat avec le client par le biais de l'Interface CustomerDAO

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

3. Vous avez de la mise en Œuvre concrète comme CustomerDAOImpl

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

Ensuite, Écrivez un Gestionnaire pour Gérer ces ou de l'Encapsulation de certains autres DAOs comme:

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);
    }
}

Maintenant, la couche de présentation ou de la Classe principale contiendra le code comme ceci:

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