Объекты Java Should Enterprise быть немым?
В нашем JAVA EE-приложении прежней версии существуют загрузки классов объекта значения (VO), которые обычно содержат только методы считывания и методы set, возможно equals() и hashCode(). Это (обычно) объекты, которые будут сохранены в устройстве хранения данных персистентности. (Для записи наше приложение не имеет никакого EJBs - хотя это могло бы измениться в будущем - и мы используем, в спящем режиме для сохранения наших объектов.) Вся бизнес-логика для управления данными в VOs находится в отдельных классах (не EJBs, просто POJOs). Мое мышление OO ненавидит это, поскольку я действительно полагаю, что операции на данном классе должны находиться в том же самом классе. Таким образом, у меня есть желание осуществить рефакторинг для перемещения логики в связанный VOs.
У меня просто было обсуждение с коллегой, который намного более опытен в Java EE, чем я, и он подтвердил, что немые объекты, по крайней мере, раньше были рекомендуемым способом пойти. Однако он также недавно считал мнения, которые подвергают сомнению законность этой позиции.
Я понимаю, что существуют проблемы, которые, по крайней мере, ограничивают то, что может быть помещено в классе объекта:
- это не должно иметь прямой зависимости к слою данных (например, код запроса должен скорее войти в отдельные ДАО),
- если это непосредственно подвергнуто более высоким слоям или клиенту (например, через SOAP), его интерфейс, возможно, должен быть ограничен
Есть ли еще допустимые причины не переместить логику в мои объекты? Или какие-либо другие проблемы для принятия во внимание?
6 ответов
Предполагается, что DTO и VO используются для передачи данных и не встраивают логику. С другой стороны, бизнес-объекты должны включать некоторую логику. Я говорю немного , потому что всегда нужно найти баланс между тем, что вы помещаете в сервисы, которые координируют логику, включающую несколько бизнес-объектов, и тем, что вы помещаете в сами бизнес-объекты. Типичной логикой в бизнес-объектах может быть проверка, вычисление полей или другая операция, которая одновременно влияет только на один бизнес-объект.
Обратите внимание, что я пока не упоминал термин сущность . Постоянные сущности были популяризированы с помощью ORM, и в настоящее время мы пытаемся использовать постоянные сущности как бизнес-объекты DTO и одновременно. То есть сами сущности перемещаются между уровнями и уровнями и содержат некоторую логику.
Есть ли еще какие-либо веские причины не переносить логику в мои объекты? Или какие-либо другие проблемы, которые следует принять во внимание?
Как вы отметили, все зависит от зависимостей и того, что вы раскрываете. Пока сущности глупы (близки к DTO), их можно легко изолировать в выделенном jar-файле, который служит API уровня . Чем больше логики вы вкладываете в сущности, тем труднее это делать. Обратите внимание на то, что вы открываете и от чего зависите (загрузите класс, у клиента также должен быть класс зависимости). Это касается исключений, иерархии наследования и т. Д.
Чтобы привести пример, у меня был проект, в котором сущности имели метод toXml (...) , используемый на бизнес-уровне. Как следствие, клиентская часть сущностей зависела от XML.
Но если вас не слишком заботят слои и строгое разделение между API и реализацией, я думаю, что неплохо переместить некоторую логику в сущности.
РЕДАКТИРОВАТЬ
Этот вопрос обсуждался много раз и, вероятно, будет продолжать обсуждаться, поскольку на него нет окончательного ответа. Несколько интересных ссылок:
Основная проблема с добавлением логики к этим классам заключается в том, что им потребуется больше атрибутов для отслеживания состояния объекта, и эти дополнительные атрибуты обычно не нужно сериализовать. Это означает, что требуется дополнительная работа в механизме сериализации этих классов.
Учитывая, что во многих проектах есть смесь jr. программисты и ст. программисты, и большая часть работы выполняется младшими, которые не понимают (или не заботятся) об оптимальной сериализации, гораздо проще иметь эти простые старые java-объекты в качестве «объектов значений», которые в значительной степени просто передают и получают данные и поместите логику в другое место.
Если вам удастся создать архитектуру, в которой логика помещена в бизнес-объект (то есть VO + Logic), я думаю, что это тоже будет лучше. Просто имейте в виду, что вся команда находится на одной странице, и они не дублируют код и логику (что никогда не происходит, верно?)
Краткий ответ: нет, они не должны всегда быть тупыми, но их гораздо проще иметь им так.
Помимо упомянутой ранее статьи Фаулера, есть полный трактат о богатых и анемичных моделях домена в книге Эрика Эванса Domain Driven Design (2004).
Также посмотрите http://dddcommunity.org/
Я думаю, ваша точка зрения действует.
Подробнее см. Здесь - http://martinfowler.com/bliki/AnemicDomainModel.html
В JPA Сущности - это легкие объекты. Так что я не думаю, что в них есть проблема с логикой.
В случае использования с SOAP / веб-службами я бы добавил отдельный слой фасада.
Итак, вот резюме отзывов, которые я получил от моего тренера по Java EE.
С практической точки зрения, достижение компромисса между анемичным и богатым доменом путем перемещения логики не должно быть проблемой до тех пор, пока методы работают с атрибутами сущности. Когда речь идет о богатом домене, необходимо где-то провести черту, и, очевидно, Фаулер и Кинг высказывались в этом направлении.
Например, рассмотрим метод calculateInterestRate() внутри BankAccount, который получает информацию из других объектов домена, например, проверяет, как долго кто-то был клиентом. Чтобы избежать зависимости, можно разделить метод по объектам, но такой подход означает, что код может быть разбросан по нескольким классам. На этом этапе можно было бы создать класс InterestCalculator.
Еще одна вещь, которую следует принять во внимание, - это безопасность потоков. Синглтонные DAO и сервисы, обрабатываемые Spring, должны быть потокобезопасными, в то время как все, что находится в доменной модели, будет подвержено проблемам параллелизма.
Наконец, существует проблема сопровождения. Уверены ли вы, что через пару лет вы будете поддерживать приложение? Выбор, который вы делаете, может показаться оправданным, но уверены ли вы, что следующий разработчик будет обладать необходимым опытом, чтобы легко понять ваш код?
.Соглашение, о котором вы говорите, состоит в том, чтобы принять анемичную модель предметной области, в отличие от модели расширенной предметной области, где Сущности - это простые объекты POJO, аннотированные как beans ( @Entity) с минимальным количеством геттеров и сеттеров. Таким образом, класс с методом toXML () будет рассматриваться как расширенный домен. Я предполагаю, что это помогает иметь четкое представление о том, что отображается в реляционной базе данных, даже если степень детализации отличается.
Преимущество состоит в том, что существует четкое разделение между логикой и данными (именно здесь философия объектно-ориентированного программирования нарушается). Подход состоит в том, чтобы сгруппировать их в классы бизнес-логики или службы. Это соответствует многоуровневой архитектуре с соответствующими уровнями: домен, службы, DAO и пользовательский интерфейс.
Это теория.
Изменить: просто для пояснения, когда я говорю, что существует четкое разделение между логикой и данными, я имею в виду, что один объект ориентирован на данные, а другой - на метод, который можно рассматривать как возврат к процедурному.