В нашем унаследованном приложении Java EE есть множество классов объектов-значений (VO), которые обычно содержат только методы получения и установки, возможно,equals() а такжеhashCode(), Это (обычно) объекты, которые должны быть сохранены в постоянном хранилище. (Кстати, наше приложение не имеет EJB-компонентов, хотя этоможет быть изменения в будущем - и мы используем Hibernate для сохранения наших сущностей.) Вся бизнес-логика для манипулирования данными в VO находится в отдельных классах (не EJB, а только POJO). Мое мышление ОО ненавидит это, так как я верю, что операции над данным классом должны находиться в том же классе. Поэтому у меня есть желание изменить рефакторинг, чтобы переместить логику в соответствующие ВО.

Я только что поговорил с коллегой, который гораздо более опытен в Java EE, чем я, и он подтвердил, что глупые сущности, по крайней мере, были рекомендованным способом. Тем не менее, он также недавно прочитал мнения, которые ставят под сомнение обоснованность этой позиции.

Я понимаю, что есть проблемы, которые по крайней мере ограничивают то, что может быть помещено в класс сущности:

он не должен иметь прямой зависимости от уровня данных (например, код запроса должен входить в отдельные DAO)если он напрямую связан с верхними уровнями или клиентом (например, через SOAP), его интерфейс может быть ограничен

Есть ли еще веские причиныне переместить логику в мои сущности? Или любые другие проблемы, чтобы принять во внимание?