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

Question

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

Другой говорит, что такой код трудно поддерживать и что вся бизнес-логика должна быть внешней.

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

Answer 1

Необходимо позвонить в качестве телефона Transfer Objects или Data transfer objects (DTO).

Ранее эта же картина j2ee называлась «Значение объекта», но они изменили название, потому что он был смущен с этим

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

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

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

См. Open session in view.

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

Answer 2

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

Answer 3

Это зависит.

oops, я просто выкрикнул клише?

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

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

Answer 4

Что сказал Korros.

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

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

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

Answer 5

Идея объединения данных и бизнес-логики заключается в том, чтобы продвигать инкапсуляцию и подвергать как можно меньше внутреннего состояния другим объектам. Таким образом, клиенты могут полагаться на интерфейс, а не на реализацию.См. Принцип "Tell, Don't Ask" и код Law of Demeter. Инкапсуляция облегчает понимание состояния данных, которые могут быть в состоянии, проще читать код, легче отделять классы и, как правило, проще проводить единичный тест.

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

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

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

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

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

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

Answer 6

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

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

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