Один наставник, которого я уважаю, предполагает, что простой bean является пустой тратой времени, - что объекты ценности "ДОЛЖНЫ" содержат некоторую бизнес-логику, чтобы быть полезной.
Другой говорит, что такой код трудно поддерживать и что вся бизнес-логика должна быть внешней.
Я понимаю, что этот вопрос субъективен. В любом случае, спрашивайте, хотите ли вы получить ответы на более широкие перспективы.
Вам лучше называть их Transfer Objects или Объекты передачи данных (DTO).
Раньше этот же шаблон j2ee назывался "Value object", но они меняли имя, потому что оно было путано с этим
http://dddcommunity.org/discussion/messageboardarchive/ValueObjects.html
Чтобы ответить на ваш вопрос, я бы поставил минимальную логику для своих DTO, логику, требуемую для демонстрации.
Еще лучше, если мы говорим о веб-приложении на базе базы данных, я бы вышел за рамки основных шаблонов j2ee и использовал Hibernate или Java Persistence API для создания модели домена, которая поддерживает ленивую загрузку отношений и использует это в представлении.
См. Открыть сеанс в виде.
Таким образом, вам не нужно программировать набор DTO, и у вас есть вся бизнес-логика, доступная для использования в ваших представлениях/контроллерах и т.д.
Идея объединения данных и бизнес-логики заключается в том, чтобы продвигать инкапсуляцию и выставлять как можно меньше внутреннего состояния другим объектам. Таким образом, клиенты могут полагаться на интерфейс, а не на реализацию. См. "Tell, Do not Ask" и Закон Деметры. Инкапсуляция облегчает понимание состояния данных, которые могут быть в состоянии, легче читать код, проще отделять классы и, как правило, легче unit test.
Внешняя бизнес-логика (обычно в классы "Сервис" или "Менеджер" ) задает такие вопросы, как "где используются эти данные?". и "В каких штатах оно может быть?" гораздо труднее ответить. Это также процедурный способ мышления, завернутый в объект. Это может привести к уровень сервиса может организовывать объекты домена, но не перехватывая ответственность за управление ими. Или, когда вы в основном делаете чтение/запись в БД, которые хорошо отображают входные формы, возможно, вам не нужна модель домена - или накладные объектные/реляционные сопоставления, которые она влечет за собой - вообще.
Объекты передачи часто служат для отграничения архитектурных слоев друг от друга (или от внешней системы) путем предоставления минимальной информации о состоянии, которой требует вызывающий уровень, без раскрытия какой-либо бизнес-логики.
Это может быть полезно, например, при подготовке информации для представления: просто дайте представление необходимой ему информации и ничего больше, чтобы он мог сосредоточиться на том, как отображать информацию, а не какую информацию отображать. Например, TO может быть агрегированием нескольких источников данных.
Одно из преимуществ заключается в том, что ваши представления и объекты домена разделены. Использование ваших доменных объектов в JSP может сделать ваш домен сложнее для рефакторинга и способствует неизбирательному использованию геттеров и сеттеров (отсюда и разрушение инкапсуляции).
Однако есть также накладные расходы, связанные с наличием большого количества объектов переноса и часто много дублирования. Некоторые проекты, с которыми я столкнулся, заканчиваются ТО, которые в основном отражают другие объекты домена (которые я считаю анти-шаблоном).
Это зависит.
Упс, я просто выкрикнул клише?
Основной вопрос, который необходимо задать для проектирования объекта: будет ли логика, управляющая данными объекта, другой или одинаковой при использовании/потреблении другими объектами?
Если разные области использования вызывают разную логику, внесите ее извне. Если это то же самое, независимо от того, куда движется объект, поместите его вместе с классом.
Мое личное предпочтение - поставить всю бизнес-логику в самой модели домена, то есть в "истинные" объекты домена. Поэтому, когда объекты передачи данных создаются, они в основном представляют собой просто (неизменяемое) представление состояний объектов домена и, следовательно, не содержат бизнес-логики. Они могут содержать методы клонирования и сравнения, но мясо кода бизнес-логики остается в объектах домена.
Что сказал Коррос.
Объект Value: = Небольшой простой объект, например деньги или диапазон дат, чье равенство не основано на идентичности.
DTO: = объект, который переносит данные между процессами, чтобы уменьшить количество вызовов методов.
Это предложения, предложенные Мартином Фаулером, и я хотел бы популяризировать их.
Я согласен с Panagiotis: шаблон открытого сеанса гораздо лучше, чем использование DTO. В противном случае я обнаружил, что приложение намного проще, если вы трафик в своих объектах домена (или какой-либо их составной части) со своего уровня обзора до конца.
Тем не менее, это сложно сделать, потому что вам нужно сделать свой HttpSession совпадающим с вашей единицей уровня упорства. Затем вам нужно будет убедиться, что все изменения базы данных (т.е. Создаются, обновляются и удаляются) являются преднамеренными. Другими словами, вы не хотите, чтобы на уровне представления был объект домена, поле было изменено, и модификация сохраняется без кода приложения, преднамеренно сохраняющего изменение. Еще одна проблема, которая важна для решения, - обеспечить, чтобы ваша транзакционная семантика была удовлетворительной. Обычно выборка и изменение одного объекта домена происходит в одном транзакционном контексте, и нетрудно сделать, чтобы ваш слой ORM потребовал новую транзакцию. Это сложная задача - это вложенная транзакция, в которой вы хотите включить второй транзакционный контекст в первый открытый.
Если вы не возражаете против того, как не-Java API обрабатывает эти проблемы, стоит взглянуть на активную запись Rails, которая позволяет страницам сервера Ruby работать непосредственно с моделью домена и перемещаться по ее ассоциациям.