Ersetzen Aspekte Repositorys?

Question

Ich habe vor kurzem mit Spring Roo experimentiert. Es macht eine sehr gute Arbeit, ein Domänenmodell mit integrierter Persistenz schnell zu erstellen. Als es Persistenz-Funktionalität in Aspekten hinzugefügt, begann ich über die folgende Frage nachzudenken:

Roo fügt Finder (Laden einer Instanz einer Klasse aus der Datenbank, die variable Kriterien erfüllt) in einem Aspekt der tatsächlichen Klasse/Entität. In DDD ist dies IMHO die Verantwortung von Repositories. Repositories sind explizite Klassen, die im Design erscheinen. Natürlich ist die Repository-Funktionalität als ein Aspekt in einer Entität versteckt und ziemlich unsichtbar.

Hier ist also die Frage: Ist ein Aspekt ein echter Ersatz für eine explizite Repository-Klasse? Gibt es irgendwelche Nachteile für den Roo AOP Ansatz?

Answer 1

Das Hinzufügen von Findern zu Ihren Domänenklassen fühlt sich für den Benutzer natürlicher an, aber es vermischt Ihre Ebenen. Grails verwendet den gleichen Ansatz, indem er statische Methoden finder *() save(), ... hinzufügt.

Abgesehen von der Ästhetik kann es praktische Nachteile haben, wenn nicht in Web-Anwendung Einstellung verwendet: Ihre Domain-Klassen sind jetzt an Ihre Datenbank gebunden. Wenn Sie diese Objekte über RMI oder HttpInvoker an Rich Clients übertragen, kann der Client die find * -Methoden nicht und oft nicht verwenden, da auf dem Client keine Sitzung/Datenbankverbindung verfügbar ist.

Ich bevorzuge es im Allgemeinen Domänenklassen zu erlauben, Service-Layer-Schnittstellen zu referenzieren, um ein anämisches Domänenmodell zu verhindern (http://martinfowler.com/bliki/AnemicDomainModel.html). Dies hat seine eigenen Nachteile, bietet aber zumindest eine klare Grenze. Auf dem Client kann die konkrete Implementierung hinter einer Service-Schnittstelle dann nur alle Methodenaufrufe an den Server übertragen (oder einfach einen synamic-Proxy mit Spring-Remoting oder ähnlichem verwenden). Um Ihre Frage zu beantworten: Es könnte ein Ersatz sein, aber Sie sollten sich der möglichen negativen Konsequenzen bewusst sein, die Ihre Domänenklassen (d. H. Ihre Kerngeschäftslogik) weniger zwischen Systemen transportieren lassen.

Answer 2

Dies hängt davon ab, wie kompliziert die Persistenzschicht Ihrer Anwendungen ist und wie viel Kontrolle Sie darüber haben. Wenn Ihre Anwendung einfach genug ist, um über JPA implementiert werden, dann könnte alles über Roo Aspekte behandelt werden. Wenn Sie jedoch Legacy-Tabellen zuordnen oder erweitertes DB-Material benötigen, befinden Sie sich möglicherweise in einer Situation, in der Spring-JDBC der einzige Ausweg ist und in diesen Fällen ein Repository/DAO-Modell noch nützlich sein kann.

Ich halte es für logisch inkonsistent (und einen Bruch der Schicht Verantwortung), zwei Persistenzmodelle zu mischen, und so wie die meisten meiner Anwendungen solche erweiterten DB-Konstrukte erfordern, halte ich streng mit einem Repository-Modell.

Answer 3

Ich denke, das Hinzufügen von Repository-Methoden zu Domänenobjekten ist schlechtes Design. Der richtige Ort wären statische Methoden in der Domänenklasse. Domänenobjekte und ihre Verwaltung sind jedoch zwei verschiedene Dinge, die getrennt werden sollten. Ich würde Domain-Objekte und Repositorys bevorzugen.

Ich denke, die Motivation war, etwas wie Rails/Grails mit Java zu erreichen.