Должна ли существовать логика сохранения в фасонных модулях домена или только в DAO?

Question

Может ли кто-нибудь объяснить, что за плюсы и минусы этого? Я имею в виду, не используя спецификации ORM framework/JPA.

Это касается отношений «многие-ко-многим» и «многие-к-одному» между сущностями. Представьте Entity Relationship

преподаватель - студент (многие-ко-многим)

или

врач - пациент (один-ко-многим)

Мой вопрос заключается в том, можем ли мы использовать метод getPatients() в компоненте «Доктор» или getStudents() в компоненте «Учитель», или должны ли они быть POJO, и все эти вещи должны быть помещены в DAO э.

Я часто вижу первый подход, который будет использоваться в случаях, когда объекты объектной модели либо расширяют классы, которые предоставляют им доступ к сервису/персистентности Фасады, либо вводятся весной вместе с ними и т. Д. Преимущество состоит в том, что можно вызвать doctor.getPatients(); практически везде в приложении вместо получения результатов от DAO.

Существуют ли ситуации, когда первый подход удобен? Потому что я вижу много случаев, когда это делается именно так, и мне интересно, имеет ли это цель или это дилетантство или старый стиль.

Answer 1

Следуйте принципу KISS. DAO отлично подходят для абстрагирования механики упорства от логики домена. Объекты домена просто переносят состояние от одного уровня к другому, как правило, с очень маленькой бизнес-логикой внутри них. Это означает, что объекты домена (например, DTO) могут иметь множество аннотаций JPA, чтобы указать настойчивость с какой-то структурой ORM, а также аннотации JAXB, чтобы позволить DTO легко сортировать XML для передачи веб-службой.

Моя общая тенденция состоит в том, чтобы иметь единый бизнес-объект, предназначенный для работы на одном DTO, чтобы каким-либо образом изменить его состояние, управляемое бизнес-правилами. Служба (которая является границей транзакций JTA) управляет набором бизнес-объектов и, по существу, формирует транзакцию приложения. Это следует за общим принципом ОДО много мелкозернистых объектов с очень четкой целью.

Answer 2

Вы можете делать все, что хотите, но вездесущий шаблон - это шаблон DAO. Дело в том, чтобы separate your concerns. Если у вас есть объект домена, скорее всего, у вас есть бизнес-логика. Вы действительно хотите поставить логику устойчивости на бизнес-логику? Ваше приложение станет менее ремонтопригодным, менее (легко) проверяемым и будет иметь больше ошибок. И как только вы сделаете одно сомнительное дизайнерское решение, больше обязательно последуют ...