Should you use Entity Beans for Domain Model

given the deprecation of loads of design patterns because of the new improvements in the Java EE world, DTO's are largely frowned upon.

However, I dont want the relational structure of database to dictate how the client(web app) uses the services in my EJB. Because of the way technology evolves, I see work being done in about 5 years time in trying to overhaul the UI as fibre optic technologies and other unthinkables becoming a reality. So i want the business logic to be completely encapsulated to allow easily changing the UI whenever we want.

With this thinking in mind, i am developin开发者_高级运维g a pure api to represent the business model and services so the client can use that instead.

However, I'm having to write converters all the time to convert the entity beans to this API. Is this the right thing to do or am over engineering.

Your feedback and opinion largely welcomed.

NB. This project uses the full Java EE 6 platform

---

There are conflicting "religions" about the best way to proceed. 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'd recommend using your typical tooling, e.g. Hibernate or Spring, to populate entities in your persistence layer. Then, use brokers to move state between the DB and the domain layer classes/objects.

HTH, Mark