If you are using Entity Beans for a domain model

Question

Given the outdated workloads of design patterns due to new improvements in the Java EE world, the DTO is largely disapproving.

However, I do not want the relational database structure to determine how the client (web application) uses the services in my EJB. Due to how the technology develops, I see that after 5 years, work is underway on the restructuring of the user interface, since fiber-optic technologies and other unthinkable become reality. So I want the business logic to be fully encapsulated to easily change the user interface whenever we want.

With this in mind, I am developing a clean api to represent the business model and services, so the client can use this instead.

However, I have to write converters all the time to convert the beans object to this API. Whether it’s right to do it or over engineering.

Your feedback and opinions were greatly appreciated.

NB. This project uses the full Java EE 6 platform.

Answer 1

There are conflicting “religions” about a better way to continue. I, like you, prefer more object-oriented solutions, which means that DB rows (entities) are not equal to business domain objects. So what to do?

I would recommend using your typical snap-in, for example. Hibernate or Spring to populate objects at your persistence level. Then use brokers to move state between the database and domain level classes / objects.

HTH, Mark