Сколько бизнес-логики должны содержать объекты Value?

Лично я предпочитаю поместить всю бизнес-логику в саму модель предметной области, то есть в "истинные" объекты предметной области. Таким образом, когда создаются объекты передачи данных, они в основном представляют собой (неизменяемое) представление состояния объектов домена и, следовательно, не содержат бизнес-логики. Они могут содержать методы для клонирования и сравнения, но основа кода бизнес-логики остается в объектах предметной области.

По-разному.

упс, я только что ляпнул клише?

Основной вопрос, который следует задать при проектировании объекта: будет ли логика, управляющая данными объекта, разные или тоже самое, когда они используются / потребляются другими объектами?

Если разные области использования требуют разной логики, сделайте это во внешнем виде. Если объект остается неизменным независимо от того, куда направляется объект, поместите его вместе с классом.

Лучше называть их Перенести объекты или Объекты передачи данных (DTO).

Раньше этот же шаблон j2ee назывался «Объект значения», но они изменили имя, потому что его путали с этим.

http://dddcommunity.org/discussion/messageboardarchive/ValueObjects.html

Чтобы ответить на ваш вопрос, я бы добавил в свои DTO только минимальную логику, логику, которая требуется для отображения.

Еще лучше, если мы говорим о веб-приложении на основе базы данных, я бы вышел за рамки основных шаблонов j2ee и использовал бы Спящий режим или Java Persistence API для создания модели предметной области, которая поддерживает ленивую загрузку отношений, и использовать ее в представлении.

См. Открытая сессия в поле зрения.

Таким образом, вам не нужно программировать набор DTO, и у вас есть вся бизнес-логика, доступная для использования в ваших представлениях / контроллерах и т. д.

Что сказал Коррос.

Объект значения: = Небольшой простой объект, например деньги или диапазон дат, равенство которого не основано на идентичности.

DTO: = объект, который переносит данные между процессами, чтобы уменьшить количество вызовов методов.

Это определения, предложенные Мартином Фаулером, и я хотел бы популяризировать их.

Идея объединения данных и бизнес-логики состоит в том, чтобы способствовать инкапсуляции и предоставлять как можно меньше внутреннего состояния другим объектам. Таким образом, клиенты могут полагаться на интерфейс, а не на реализацию. См. Принцип "Скажи, а не спрашивай" и Закон Деметры. Инкапсуляция упрощает понимание состояний, в которых могут находиться данные, легче читать код, легче разделять классы и, как правило, проще проводить модульное тестирование.

Экстернализация бизнес-логики (обычно в классы «Сервис» или «Менеджер») вызывает вопросы типа «где используются эти данные?» и "В каких состояниях он может быть?" гораздо сложнее ответить. Это также процедурный способ мышления, заключенный в объект. Это может привести к модель анемической области.

Внешнее поведение не всегда плохо. Например, уровень обслуживания может управлять объектами домена, но не берет на себя их обязанности по управлению состоянием. Или, когда вы в основном выполняете чтение / запись в БД, которая хорошо отображается на формы ввода, возможно, вам вообще не нужна модель предметной области - или болезненные накладные расходы на объектное / реляционное сопоставление, которые она влечет за собой - вообще.

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

Это может быть полезно, например, при подготовке информации для представления: просто дайте представлению информацию, которая ему нужна, и ничего больше, чтобы оно могло сконцентрироваться на как для отображения информации, а не на информации какие для отображения. Например, TO может представлять собой совокупность нескольких источников данных.

Одно из преимуществ состоит в том, что ваши представления и объекты домена не связаны. Использование ваших доменных объектов в JSP может затруднить рефакторинг вашего домена и способствовать неизбирательному использованию геттеров и сеттеров (следовательно, нарушение инкапсуляции).

Однако есть также накладные расходы, связанные с наличием большого количества объектов передачи и часто с большим количеством дублирования. Некоторые проекты, в которых я работал, заканчиваются ТО, которые в основном отражают другие объекты домена (что я считаю анти-шаблоном).

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

Тем не менее, это сложно сделать, потому что вам нужно будет сделать так, чтобы ваш HttpSession совпал с единицей работы вашего уровня сохраняемости. Затем вам нужно будет убедиться, что все модификации базы данных (т.е. создание, обновление и удаление) являются преднамеренными. Другими словами, вы не хотите, чтобы уровень представления имел объект домена, поле было изменено, и изменение сохранялось без намеренного сохранения изменений в коде приложения. Еще одна проблема, которую важно решить, - убедиться, что ваша транзакционная семантика удовлетворительна. Обычно выборка и изменение одного объекта домена происходит в одном транзакционном контексте, и нетрудно заставить ваш уровень ORM потребовать новую транзакцию. Сложность является - это вложенная транзакция, в которой вы хотите включить второй транзакционный контекст в первый открытый.

Если вы не против исследовать, как не-Java API решает эти проблемы, стоит взглянуть на Rails Active Record, который позволяет страницам сервера Ruby работать непосредственно с моделью предметной области и пересекать ее ассоциации.