Заменяют ли аспекты репозитории?

Question

Я начал экспериментировать с Spring Roo совсем недавно. Он очень хорошо помогает быстро построить модель предметной области с интегрированным постоянством. Поскольку он добавляет функциональность персистентности в аспектах, я начал думать о следующем вопросе:

Roo добавляет искатели (загружают экземпляр класса из базы данных, который соответствует переменным критериям) в аспекте к фактическому классу / сущности. В DDD это ИМХО ответственность за хранилища. Хранилища - это явные классы, которые отображаются в дизайне. Конечно, в качестве аспекта функции хранилища скрыты в сущности и в значительной степени невидимы.

Итак, вот вопрос: является ли аспект реальной заменой явного класса репозитория? Есть ли минусы в подходе Roo AOP?

Answer 1

Добавление искателей в классы вашего домена кажется более естественным с точки зрения пользователя, но смешивает ваши слои. Grails использует тот же подход, добавляя методы static finder * () save (), ....

Помимо эстетики, она может иметь практические недостатки, если не используется в настройках веб-приложения: Классы вашего домена теперь привязаны к вашей базе данных. Если вы передаете эти объекты в расширенные клиенты через RMI или HttpInvoker, клиент не может и часто может не использовать методы find *, поскольку на клиенте нет подключения к сеансу / базе данных.

Обычно я предпочитаю разрешать классам доменов ссылаться на интерфейсы уровня обслуживания для предотвращения анемичной модели домена (http://martinfowler.com/bliki/AnemicDomainModel.html).. У этого есть свой собственный набор недостатков, но, по крайней мере, он дает четкую границу. На клиенте конкретная реализация, стоящая за Сервисный интерфейс может затем просто проксировать все вызовы методов на сервере (или просто использовать синамический прокси с пружинным удаленным взаимодействием или чем-то подобным).

Итак, чтобы ответить на ваш вопрос: это может быть заменой, но вы должны знать о возможных негативных последствиях, которые делают ваши доменные классы (т.е. вашу основную бизнес-логику) менее переносимыми между системами.

Answer 2

Я думаю, что добавление методов репозитория к объектам домена - плохой дизайн. Правильное место - статические методы в доменном классе. Но доменные объекты и управление ими - это две разные вещи, которые должны быть разделены. Я бы предпочел доменные объекты и репозитории.

Я думаю, что мотивация заключалась в том, чтобы достичь чего-то вроде Rails / Grails, как в Java.

Answer 3

Это зависит от того, насколько сложен уровень персистентности ваших приложений и насколько вы контролируете его. Если ваше приложение достаточно просто для реализации через JPA , то все это может быть обработано через аспекты Roo. Однако, если вы отображаете устаревшие таблицы или вам нужны расширенные базы данных, вы можете оказаться в ситуации, когда Spring-JDBC является единственным выходом, и в этих случаях модель хранилища / дао все еще может быть полезной.

Я считаю логичным непоследовательным (и разрывом уровня ответственности) смешивать две модели постоянства, и, поскольку большинство моих приложений требуют таких расширенных конструкций БД, я строго придерживаюсь модели репозитория.