Le code qui a déclenché cette question était un service dans la base de code de ma société qui contenait quatre DAO différents. Je ne pensais pas beaucoup à cela avant d'avoir vu que ce service était devenu confondu avec des méthodes appartenant à un service complètement différent. La raison de la création de ces méthodes injustifiées à l'intérieur de ce service était simplement parce que les membres de la DAO nécessaires étaient des membres privés de cette classe de services.
est cette faute professionnelle du développeur, ou est-elle fausse dans la plupart des cas d'avoir plus d'un DAO par classe de services?
Remarque: j'ai remarqué qu'il semble raisonnable d'avoir plus d'un DAO par classe de service tant qu'ils sont tous contenus dans la même base de données. Mais avoir DAO de plusieurs bases de données semble que cela puisse causer des problèmes.
4 Réponses :
Je ne vois rien de mal avoir plusieurs DAOS par classe de service. Quand j'ai commencé à faire un développement Web il y a de nombreuses années, j'ai eu un service un DAO parce que cela semblait être l'approche la plus logique et la plus simple. Ensuite, j'ai commencé à voir des problèmes où il y a des API similaires chez DAOS servant différents services. Donc, ma solution "immature" était de promouvoir ces API communes à certains parents dao à hériter par ces DAOS. Lorsque le projet grandit, il est venu à un point où l'héritage n'a aucun sens, car j'ai des situations où 80% des enfants daos ont besoin de l'API mais 20% ne le font pas encore, mais ils héritent encore du même parent Dao parce qu'ils partagent d'autres API similaires. Vous voyez le problème ici? Je veux dire, en Java, vous ne pouvez hériter d'un parent que d'un parent, alors j'ai fini par faire des API qui "pourrait" être utilisées par "majorité" des DAOS dans le parent DAO, qui enfreint complètement le principe de l'héritage en premier lieu.
À l'heure actuelle, toutes mes classes de DAO ont des responsabilités / tâches spécifiques. C'est bon pour un DAO d'appeler un autre DAO (par exemple, LoggingDao est utilisé par la plupart DAO pour enregistrer les actions des utilisateurs). De cette façon, au lieu d'avoir un DAO qui sert un service spécifique, le DAO fournit une liste d'opérations pouvant bénéficier au service. Le service «utilisera» tout le DAOS qui pourra accomplir la tâche.
J'espère que cette explication aide.
Cela fait. Dans mon cas, je pense que je traitais avec une faute professionnelle des développeurs où les gens poussaient des choses dans un service sur la base de ses domaines DAO au lieu de l'intention du service.
Ahh, les problèmes d'héritage et de polymorphisme de sous-type ... tout cela de côté, belle anecdote ;-)
À mon avis, un service fournit un ensemble de services spécifique pour gérer certaines actions de l'utilisateur. Ces services peuvent utiliser ou non un dao (s) pour faire le travail. A DAO, d'autre part, fournit la communication entre le service et une base de données, mais il ne devrait pas savoir quoi que ce soit sur la demande de l'utilisateur. Si le développeur se mélange tous les deux ensemble, je ne vois pas de point d'avoir des services et des DAOS car vous pouvez simplement les combiner ensemble, ce qui est terriblement mauvais, car vous ne pouvez pas réutiliser beaucoup de code. :)
@pst: héritage était la chose la plus kewlest pour moi, jusqu'à ce que les choses soient incontrôlées. La morale de l'histoire est optimale pour la composition au lieu d'héritage dans la mesure du possible, il rend également des tests unitaires aussi plus facilement. :)
L'opinion d'un homme sur Internet: l'interface EntityManager lui-même est une abstraction parfaitement adéquate pour traiter la couche de persistance. La grande majorité des «Daos» qui sont redondants avec les EM déjà abstraite obstrèrent de nombreuses applications pour rien d'autre qu'une "notre application a une bonne architecture à plusieurs niveaux comme le livre" Fuzzy chaud :)
Un à plusieurs est bien tant qu'il est logique de rompre les DAOS.
Quelques raisons pour lesquelles je peux penser où il est logique de diviser un DAO:
Lors d'une entreprise, j'ai travaillé à la fois, ils avaient un beau design où le service appelé contrôleur et le contrôleur pouvait appeler une autre couche, que je ne me souvienne pas, mais cela appellerait ensuite le DAO.
Donc, ils avaient un niveau d'accès qui pourrait appeler plusieurs DAOS, afin de faire une fonction de commande supérieure, donc si vous souhaitez effectuer une commande, cela peut nécessiter appeler plusieurs tables, et peut-être plusieurs systèmes, de sorte que plusieurs systèmes. contrôleur appellerait la méthode didderder .
Ceci est un concept agréable car il conserve une bonne sensation de séparation et de simplifier le test de l'unité, comme vous pouvez tester chaque couche.
Si votre service est capable d'appeler plusieurs DAOS, les tests unitaires peuvent être plus difficiles, car vous rendez la couche de service plus compliquée.
Ainsi, lorsque vous concevez vos couches, consultez s'il est logique de créer de nouvelles couches pour simplifier les conceptions, ce qui peut découvrir des bogues ou prévenir les bugs.
La couche manquante était la coordinatrice et les règles étaient que chaque coordinateur traitait d'un DAO et pourrait faire des transformations nécessaires, mais la logique commerciale était dans le contrôleur. Ainsi, un coordinateur pourrait parler à tout autre coordinateur pour obtenir des informations et ces coordinateurs iraient à la DAO.
Toutefois, si vous avez créé une classe de déléguée pour appeler plusieurs DAOS, vous avez essentiellement modifié le fardeau de ce délégué. Si vous testez un service avec plusieurs appels DAO est difficile, cela ne serait-il pas uniformément difficile à tester la classe de déléguée?
@LIMC - J'ai réalisé le reste des règles et le nom, qui plus simple. Le printemps a été utilisé, vous pouvez donc échanger dans des couches simulées, de sorte que si vous vouliez tester le contrôleur, vous vous moquiez du coordinateur.
http://java.sun.com/blueprints/corej2epatterns/patterns/ DataAccessObject.html
Le montant sur DAO dépend simplement des sources sous-jacentes!