Czy repozytoriów zastępczych aspektów?

Question

Zacząłem ostatnio eksperymentować z Spring Roo. Wykonuje bardzo dobrą robotę, pomagając raczej szybko zbudować model domeny z wbudowaną utrwalaniem. Ponieważ dodaje aspekt trwałości w aspektach, zacząłem myśleć o następującym pytaniu:

Roo dodaje wyszukiwarkę (ładuje instancję klasy z bazy danych, która spełnia kryteria zmiennych) w aspekcie do faktycznej klasy/encji. W DDD odpowiedzialność za repozytoria ponosi IMHO. Repozytoria są jawnymi klasami, które pojawiają się w projekcie. Oczywiście jako aspekt funkcja repozytorium jest ukryta w jednostce i jest prawie niewidoczna.

Oto pytanie: czy aspekt jest prawdziwym zamiennikiem wyraźnej klasy repozytoriów? Czy są jakieś wady w podejściu Roo AOP?

Answer 1

Dodawanie osób poszukujących do klas Twojej domeny wydaje się bardziej naturalne z punktu widzenia użytkownika, ale łączy się z warstwami. Grails używa tego samego podejścia, dodając metodę statycznego findera *() save(), ....

Oprócz estetyki może to mieć praktyczne wady, gdy nie jest używane w ustawieniach aplikacji internetowej: Twoje klasy domen są teraz powiązane z twoją bazą danych. Jeśli przeniesiesz te obiekty do bogatych klientów za pośrednictwem RMI lub HttpInvoker, klient nie może i często nie może używać metod find *, ponieważ nie ma połączenia sesja/baza danych dostępnego na kliencie.

Generalnie wolę zezwolić klasom domen na odwołanie się do interfejsów warstwy usług, aby zapobiec anemicznym modelom domen (http://martinfowler.com/bliki/AnemicDomainModel.html). Ma to swoje własne wady, ale przynajmniej zapewnia wyraźną granicę. Na kliencie konkretna implementacja za interfejsem serwisowym może po prostu pełnić rolę proxy wszystkich wywołań metod na serwerze (lub po prostu używać proxy synchronicznego z remotingiem sprężynowym lub sth podobnym).

Aby odpowiedzieć na Twoje pytanie: Może to być substytut, ale powinieneś zdawać sobie sprawę z możliwych negatywnych konsekwencji, które sprawiają, że twoje klasy domen (tj. Twoja podstawowa logika biznesowa) są mniej przenośne między systemami.

Answer 2

To zależy od tego, jak skomplikowana jest warstwa trwałości aplikacji i jaka jest nad nią kontrola. Jeśli twoja aplikacja jest łatwa do wdrożenia przez JPA, to wszystko może być obsługiwane za pośrednictwem aspektów Roo. Jednak, jeśli mapujesz starsze tabele lub potrzebujesz zaawansowanych danych DB, możesz znaleźć się w sytuacji, w której Spring-JDBC jest jedynym wyjściem, w takim przypadku model repozytorium/dao może być nadal przydatny.

Uważam, że logiczne niespójne (i podział odpowiedzialności warstwy) jest mieszanie dwóch modeli trwałości i tak jak większość moich aplikacji wymaga takich zaawansowanych konstrukcji DB trzymam ściśle z modelem repozytorium.

Answer 3

Myślę, że dodanie metod repozytorium do obiektów domeny jest złe. Właściwe miejsce byłoby metodami statycznymi w klasie domeny. Ale obiekty domenowe i ich zarządzanie to dwie różne rzeczy, które powinny zostać rozdzielone. Wolałbym obiekty domeny i repozytoria.

Podejrzewam, że motywacją było osiągnięcie czegoś, co Rails/Grails robi z Javą.