Question

We’re working on a new system that uses hibernate for persistence. As the schema changes we’re using NetBeans to regenerate the entity classes.

As the system is evolving we are finding a lot of functionality that is crying out to be added as business methods in the entities, but because we are regenerating these classes from time-to-time we are reluctant to do so.

Is there an elegant way of being able to regenerate entity classes and still add business logic, such as in a subclass that Hibernate would use?

Many thanks,

Ian.

Answer 1

Not that I’m aware of. However, I have a solution for you.

The business logic code has to go somewhere – the question is, where to put it. You could put it on the @Entity, marking business getters with @Transient, but good design says to use a separate class DAO class.

Separating business from persistence code follows the “high cohesion” design principle, giving you:

• Your entity class remains clean – ie it has code solely related to persistence. Furthermore, because you haven’t added anything to it, it can safely be regenerated at any time.
• Your “business logic” class (often named the same as the entity class, but with "Dao" added to the name, eg CustomerDao) has methods to deal with (usually course-grained) behaviour. Also, unit testing is usually easier, because you don’t want to test the entity methods (you can assume they work – it ain’t your code) and can more easily design your code to allow easy mocking of an entity (that isn’t a real entity)

You may be able to leverage some reuse by creating a typed abstract DAO class for behaviour common to entities (where/if it makes sense).