46 votes

Java EE de l'Architecture Sont des DAO est toujours recommandé lors de l'utilisation d'un ORM comme JPA 2?

Si j'utilise un ORM comme JPA2 - où j'ai mes entités qui sont mappés à ma base de données, dois-je continuer à l'aide d'un DAO? Il semble que beaucoup plus de frais généraux.

Par exemple, j'aurais besoin de maintenir trois paquets supplémentaires:

  1. Celui qui spécifie mes objets du domaine (qui assez bien la carte de mes objets de l'Entité):

    public class Employee {
        private String firstName;
        private String lastName;
        ...
        // Getters and setters
    }
    
  2. Celui qui contient les interfaces que de spécifier mes méthodes DAO

    public interface EmployeeDAO {
        public void addEmployee(Employee employee);
        public Employee getEmployeeById(long id);
        ...
    }
    
  3. Celui qui contient des beans de session qui mettent en œuvre des mon de DAO

    public EmployeeJpaDAO implements EmployeeDAO {
        interface method implementations here
        ....
        private method that transform my Employee entity into my Employee domain object
    }
    

Maintenant que beaucoup de bagages supplémentaire à ajouter à chaque fois que j'ai besoin d'effectuer une nouvelle opération CRUD.

Cependant, les avantages que je vois à avoir un DAO est:

  1. Vous pouvez avoir une mémoire mise en œuvre de la DAO pour les tests unitaires votre couche de service. Cela signifie que vous n'avez pas besoin d'accéder à la base de données pour tester la logique métier, et vous pouvez être assuré que vos objets contiennent toujours les mêmes valeurs pour les propriétés

  2. Il sépare la logique métier de base de données logique d'accès aux

L'option qui n'implique pas la mise en œuvre d'un DAO est simplement d'utiliser des objets de l'entité et l'EntityManager dans la couche de service:

@Stateless
public class EmployeeEjb {
    @PersistenceContext(unitName = "employee")
    private EntityManager manager;

    public Employee getEmployeeById(long id) {
        return manager.createNamedQuery(Employee.GetEmployeeById).getResultList();
    }
    ...
}

Il n'y a pas de juste milieu ici? Quelqu'un a trouver une architecture ou mis en œuvre une architecture qui répond à certains des avantages d'une couche DAO (le plus important de l'unité de la testabilité de la logique métier) que je l'ai mentionné ci-dessus, mais n'implique pas de tous les coûts pour mettre en œuvre une couche DAO?

Merci pour toutes les recommandations et/ou suggestions! Je suis vraiment curieux de voir ce que certaines personnes ont eu à cet égard.

48voto

Pascal Thivent Points 295221

Si j'utilise un ORM comme JPA2 - où j'ai mes entités qui sont mappés à ma base de données, dois-je continuer à l'aide d'un DAO? Il semble que beaucoup plus de frais généraux.

Il est. Et clairement, Java EE n'est pas encourager l'utilisation de la DAO modèle lors de l'utilisation de JPA JPA (déjà fournit une méthode standardisée de la mise en œuvre du Domaine Magasin de modèle et il n'y a pas beaucoup de valeur à protéger derrière un DAO). Je trouve le DAO pour être anti-SÈCHE dans une telle situation.

Donc, pour le simple cas (en fait, la plupart des cas), j'ai été heureux de sauter le DAO et je n'ai aucun problème avec ça. Pour les plus complexes des cas (par exemple lors de l'utilisation des procédures stockées, des fichiers plats), j'aimerais l'utiliser. En d'autres termes, cela dépend, comme le résume A JPA Tué le DAO?. Voir aussi les questions liées ci-dessous:

Questions connexes

(...) Celui qui contient des beans de session qui mettent en œuvre des mon de DAO

Noooon, vous ne voulez certainement pas à mettre en œuvre un DAO comme un Bean de Session:

  • Vous ne voulez pas créer autant (pooled) Session Bean (tableaux de grand gaspillage de ressources)
  • Vous ne voulez pas de la chaîne des Beans de Session de partout, de ne pas reproduire les erreurs du passé, c'est un mauvaise pratique qui n'est pas à l'échelle.

Donc, si vous voulez vraiment aller de l'DAO chemin et veulent l'EM à être injecté, soit de mettre en œuvre votre DAOs, comme le Printemps des haricots (en Java EE 5) ou en CDI managed bean (Java EE 6).

Vous pouvez avoir une mémoire mise en œuvre de la DAO pour les tests unitaires votre couche de service.

Si vous voulez vraiment faire de l'unité de test, de se moquer de la DAO/EntityManager, il n'y a pas de différence. Et si vous voulez faire des tests d'intégration, vous pouvez configurer JPA pour utiliser une mémoire de base de données. Ainsi, à la fin, je ne l'achetez pas cet argument.

Il sépare la logique métier de base de données logique d'accès aux

Honnêtement, je ne vois pas une grande différence entre s'appuyant sur un DAO vs un gestionnaire d'entité, je ne vois pas comment un DAO choses distinctes "mieux". Encore une fois, je n'achète pas cet argument.

Et à mon expérience, la modification de la sous-jacentes de la persistance de la solution est très exceptionnels cas et je ne vais pas introduire DAOs pour quelque chose qui est très probablement ne va pas arriver (YAGNI, BAISER).

Il n'y a pas de juste milieu ici? Quelqu'un a trouver une architecture ou mis en œuvre une architecture qui répond à certains des avantages d'une couche DAO (le plus important de l'unité de la testabilité de la logique métier) que je l'ai mentionné ci-dessus, mais n'implique pas de tous les coûts pour mettre en œuvre une couche DAO?

Je ne vois pas beaucoup de moyen, et aussi fortement laissé entendre, je ne l'utilise pas DAOs si je ne ressens pas le besoin. Et comme je l'ai dit, se moquent de l' EntityManager si vous voulez vraiment faire de test de l'unité de la logique métier. Il fonctionne pour moi et je suis heureux d'écrire moins de code.

Plus de ressources

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X