Wir haben eine typische n-tier-Java-Anwendung, und mir ist aufgefallen, dass unsere Datenzugriffsebenen DAO's haben, die vom Typ FooDAO und FooDAOImpl sind. Ich wollte die Notwendigkeit für die beiden rechtfertigen und hier ist meine Analyse.
Mit diesen Punkten fühle ich nicht das wirkliche Bedürfnis nach einem separaten FooDAO und FooDAOImpl, wo ein einfaches FooDAO ausreichen sollte. Fühlen Sie sich frei, irgendwelche der Punkte zu korrigieren, die ich erwähnt habe.
Vielen Dank im Voraus!
Ich habe versucht, # 3 mit Mockito und es war in der Lage, POJO's ohne Schnittstellen gut zu verspotten. Mit den Argumenten gegen # 1 und # 2 bin ich geneigt, vorerst nicht mit separaten DAO und DAOImpl zu gehen. Fühlen Sie sich frei, andere Punkte des Vergleichs hinzuzufügen.
Ich sehe einen vierten Grund:
Abhängig vom Team, der voraussichtlichen Lebensdauer der Software oder der Menge der erwarteten Änderungen in der Zukunft lohnt es sich, so viel wie möglich zu verstecken, selbst wenn es nur eine Implementierung gibt.
Ich würde sagen, dass das Vorhandensein einer FooDAO -Schnittstelle mit einer einzigen Implementierung FooDAOImpl generell ein Anti-Pattern ist. Die einfachere Lösung (keine separaten Schnittstellen für DAOs) ist viel vorzuziehen, es sei denn, Sie haben sonst einen soliden Grund - was hier nicht der Fall zu sein scheint.
Ich persönlich würde sogar noch weiter gehen und sagen, dass DAOs überhaupt nicht die beste Wahl sind. Ich bevorzuge es, eine einzige Persistenz-Fassadenklasse auf einer ORM-API wie Hibernate oder JPA zu implementieren. Vielleicht ist iBATIS dafür zu niedrig.