Utilisation d'interfaces pour écrire des classes DAO

Je crée une nouvelle application Web qui utilisera un ensemble de classes DAO (Data Access Object) pour effectuer des opérations CRUD sur les données. Je sais que je devrais écrire des interfaces java quand j'ai des utilisateurs/applications externes utilisant mes classes DAO. Mais si ce besoin n'existe pas, pensez-vous que je devrais encore écrire les interfaces? Je vais injecter des classes DAO dans les classes Spring Controller (j'utilise Spring MVC) en utilisant le printemps.Utilisation d'interfaces pour écrire des classes DAO

Source

2010-12-21 Srini Kandula

REMARQUE: Vous devez toujours essayer de séparer l'interface de l'implémentation. Cela vous donnera plus de contrôle sur les autres couches, en utilisant cette couche DAO. Mais, comme vous le savez, une interface vous donne plus d'abstraction, et rend le code plus flexible et résilient aux changements, car vous pouvez utiliser différentes implémentations de la même interface sans changer de client. Cependant, si vous ne pensez pas que votre code va changer, ou (spécialement) si vous pensez que votre abstraction est assez bon, vous ne devez pas nécessairement utiliser des interfaces

En d'autres termes: les interfaces sont bonnes, mais avant de créer une interface pour chaque classe pense à cela

Source

2010-12-21 21:27:48

Si vous créez des interfaces pour les DAO/référentiels, comment traiteriez-vous les entités? Par exemple, si WidgetDaoImpl (qui implémente l'interface WidgetDao) effectue des opérations CRUD sur des objets Widget, les interfaces et entités résident dans des modules différents (par exemple "api" et "domaine", respectivement). Il ne serait pas logique pour le module API d'avoir une dépendance sur le domaine, alors comment voulez-vous concilier cela? Merci. – JPL

Je ne pense pas que vous devriez. Vous allez juste brûler votre temps. Créez-les seulement si c'est nécessaire.

Source

2010-12-21 21:23:47 Tebo

Je ne sais pas qui a voté mais sa suggestion est valide –

@Pangea: Que voulez-vous dire par valide? Si vous voulez dire "l'OP _ pourrait suivre cette suggestion", alors oui.Mais ce ne serait pas une bonne idée, en particulier avec les DAO, et cela serait en grande partie contraire à l'un des principaux avantages de l'utilisation de l'injection de dépendance. – ColinD

Vous avez également un point Couleur, mais tout ne doit pas être injecté. –

Oui, vous devriez. Vos classes qui les utilisent devraient compter uniquement sur les interfaces. Cela vous permet d'initialiser facilement les classes client avec de fausses implémentations de vos DAO afin de tester ces classes, entre autres choses. Si vous utilisez simplement une classe concrète, les clients de vos DAO dépendront directement de cette implémentation unique (accès à la base de données) et seront très difficiles à tester. La facilité de créer des classes dépend uniquement des interfaces pour les services dont elles dépendent, est l'un des principaux points forts de l'injection de dépendance et vous seriez en train de faire un mauvais service et de ne pas profiter de votre application.

Source

2010-12-21 21:27:40 ColinD

@ ClinD: Vous pouvez fournir une implémentation différente à des fins de test sans utiliser d'interfaces. La seule chose qui devrait être abstraite dans l'interface est: Les interactions importantes de la couche client des méthodes. –

@Vijay: Je ne suis pas vraiment sûr de ce que vous dites ici. Si une classe a une dépendance qui est une classe concrète, le mieux que l'on puisse faire pour fournir une implémentation différente est de créer une sous-classe de cette classe (si cela est possible) et de surcharger les méthodes (si cela vous permet). Vous pouvez toujours être étroitement lié à une partie de la mise en œuvre de cette classe. – ColinD

Oui, vous avez raison sur le couplage serré, Qui sera couplé étroitement. Mais, le couplage serré n'est pas une chose MAUVAISE du tout toujours. Le couplage réduit entre les classes vous permettra de changer les implémentations de dépendances à volonté. mais vous devez vous soucier du coût de la performance et de la maintenance. –

La plus grande raison pour laquelle vous devez écrire des interfaces pour vos DAO (Repositories?) est que vous pouvez facilement construire des simulacres (ou utiliser un cadre moqueur) pour tester tout ce qui a une dépendance sur le DAO.

Même si vous ne faites pas les tests unitaires, il est toujours une bonne pratique de la conception à suivre DIP

D'ailleurs, combien de temps faut-il vraiment « clic droit => Extraire une interface » à l'intérieur d'un IDE moderne ?

Source

2010-12-21 21:27:56 Brook

Je ne suis pas d'accord avec Color Blend. Fondamentalement mon opinion est: tout ce qui est injecté par le printemps devrait être soutenu (et référencé) par une interface.

Source

2010-12-21 21:28:04

Une approche commune lors de la conception de l'API pour les clients externes consiste à créer des interfaces, et non des classes.

De cette façon, le client ne connaîtra que le contrat d'API qui devrait être explicitement déclaré dans l'interface javadocs et il n'y aura aucune dépendance sur les détails d'implémentation que vous choisissez. De plus, vous pourrez tester les clients de votre API dans JUnit, en fournissant des implémentations simulées de votre API, ce qui serait plus difficile si vous n'utilisez pas d'interfaces.

Source

2010-12-21 21:29:53

Utilisation d'interfaces pour écrire des classes DAO

Répondre

Questions connexes