Следует ли размещать логику персистентности в компонентах модели домена или только в DAO?

Question

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

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

учитель - ученик (многие ко многим)

или

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

Мой вопрос в том, можем ли мы поместить метод getPatients () в bean-объект Doctor или getStudents () в bean-компонент Teacher, или это должны быть POJO, и все эти вещи должны быть помещены в слой DAO.

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

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

Answer 1

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

Answer 2

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

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