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

Question

Один наставник, которого я уважаю, предполагает, что простой компонент — это пустая трата времени, что объекты значений «ДОЛЖНЫ» содержать некоторую бизнес-логику, чтобы быть полезными.

Другой говорит, что такой код сложно поддерживать и что всю бизнес-логику необходимо экспортировать.

Я понимаю, что этот вопрос субъективен.Все равно спрашиваю – хочу узнать ответы с более широкой точки зрения.

Answer 1

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

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

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

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

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

См. Открытая сессия на виду.

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

Answer 2

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

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

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

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

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

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

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

Answer 3

Это зависит.

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

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

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

Answer 4

Мое личное предпочтение — поместить всю бизнес-логику в саму модель предметной области, то есть в «настоящие» объекты предметной области.Поэтому, когда создаются объекты передачи данных, они в основном представляют собой (неизменяемое) представление состояния объектов предметной области и, следовательно, не содержат бизнес-логики.Хотя они могут содержать методы для клонирования и сравнения, но основная часть кода бизнес-логики остается в объектах предметной области.

Answer 5

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

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

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

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

Answer 6

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

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

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