Добавление бизнес-методов к автоматически сгенерированным спящим объектам

Question

Мы работаем над новой системой, которая использует спящий режим для сохранения. При изменении схемы мы используем NetBeans для регенерации классов сущностей.

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

Существует ли элегантный способ создания классов сущностей и добавления бизнес-логики, например, в подклассе, который будет использовать Hibernate?

Большое спасибо,

Ян.

Answer 1

Не то, чтобы я знал.Однако у меня есть решение для вас.

Код бизнес-логики должен куда-то идти - вопрос в том, где его поставить.Вы могли бы поставить его на @Entity, пометив бизнес-получателей @Transient, но хороший дизайн говорит, что нужно использовать отдельный класс DAO класс.

Отделение бизнесаиз кода персистентности следует принципу «высокая сплоченность» , который дает вам:

• Ваш класс сущности остается чистым - т. е. он имеет код исключительно , относящийся к персистентности,Кроме того, поскольку вы ничего не добавили к нему, его можно безопасно восстановить в любое время.
• Ваш класс "бизнес-логики" (часто называемый тем же, что и класс сущностей, но с добавлением "Dao" кимя, например, CustomerDao) имеет методы для работы с (как правило, детализированным) поведением.Кроме того, модульное тестирование обычно проще, потому что вы не хотите тестировать методы сущностей (вы можете предположить, что они работают - это не ваш код), и вы можете с большей легкостью спроектировать свой код, чтобы обеспечить легкую имитациюсущности (которая не является реальной сущностью)

Вы можете использовать повторное использование, создав типизированный абстрактный класс DAO для поведения, общего для сущностей (где /если это имеет смысл).

Answer 2

Существует разница между бизнес-моделью и бизнес-логикой. Логика действует над моделью для предоставления услуги. Обычно организации должны отражать модель, в то время как DAO и службы должны отражать бизнес-логику. Для меня странно иметь бизнес-логику внутри сущностей.