Dans un scénario de mappage de base de données de type "un vers plusieurs", disons qu'un département peut avoir plusieurs employés, quelle est la meilleure pratique pour concevoir la couche DAO ?
Devrais-je avoir une classe DAO générique pour obtenir/régler l'objet département et obtenir/régler l'objet employé ou deux classes DAO distinctes DepartmentDAO et EmployeeDAO pour obtenir/régler l'objet département et l'objet employé respectivement ?
Je le séparerais avec un dao pour le département et un autre pour l'employé. Je pense que le drapeau rouge est : comment appelleriez-vous le dao combiné ?
Si un nom clair et intuitif ne vous vient pas immédiatement à l'esprit, il s'agit d'une odeur de code potentielle. Et si le nom ne vous saute pas aux yeux, il confondra sûrement les autres programmeurs qui regardent votre code. Pourquoi coller ensemble deux choses qui sont tout à fait distinctes ?
Quelques lignes directrices :
S'il s'agissait d'Employé et d'Entrepreneur, par exemple, je pourrais accorder un peu plus de crédit à leur combinaison en un générique, mais même dans ce cas, il est assez probable que je les garderais séparés, à moins d'avoir une forte raison de ne pas les séparer.
Si votre projet commence à devenir énorme avec 15 ou 20 DAO, vous pourriez finir par décider d'aller vers une seule DAO, mais c'est une décision que vous pouvez prendre en aval. Vous pourriez alors créer un DAO Ressources Humaines ou quelque chose comme ça. C'est principalement pour éviter un câblage surabondant.
Il y a très peu d'inconvénients à séparer Département et Employé, et potentiellement un gain assez significatif en clarté et en facilité de maintenance de votre code. Et il n'est pas très difficile de les combiner à l'avenir si vous avez une bonne raison de le faire.
C'est mon avis.
En fait, il me semble que vous auriez besoin d'au moins 3 DAO différents :
DepartmentDAOEmployeeDAOEmployeeCollectionDAOLe fait est que la cartographie d'une seule entité et la cartographie d'un groupe d'entités présentent des différences significatives. Par conséquent, ils doivent être traités par des structures différentes, sinon vous risquez d'enfreindre les règles de l'UE. SRP .
En outre, le Department devrait être une interaction avec une collection de Employee et non avec chaque instance séparément.
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.
