Is using data transfer objects in ejb3 considered best practice

Question

Although obviously not all scenarios can be covered by a single design, is it generally felt now that ORM classes should be passed to and fro between the presentation and busine

Answer 1

I agree with the last "speaker" why to use a wrapper when in ejb3?? We build a quite complex system without DTO but using Entities (JPA) it worked find. It was clear...

Answer 2

This is very interesting question and one I have been investigating and experimenting with over the pass two years.

I think there really is no right or wrong answer here. I don't think you can simply say I want one over the other because typically you may want a hybrid depending on what your clients are (webpage,ws,machine and/or local,remote).

The important thing to remember here is what the pros and cons are to each offering and applying this based on your requirements.

For Example:

• If you were using SEAM, then you would want to avoid a heavily layered architecture because you have access to an extended persistence context. Other web technologies without this support tend to work better with a DTO which prepared the state upfront.
• If you are sending a remote message the import thing is to keep it thin and lightweight, a DTO would typically work better here than a rich domain object. Here you can suppress transparently any ORM issues/behavior.
• DTO pattern has the benefit of protecting your clients from domain changes. This is particularly important if your app is a web service, having a domain (entity) object which defines your contract might leave you unstuck at some point.

By wrapping your system in layers and carefully exposing and securing them, you can produce various APIs for many clients of different types.

Answer 3

Tight coupling? Please explain.

As for me DTO is an Anti-Pattern. EJB3 allows us to omit using them. You can just force your lazy initialization before sending Entity to the client.

Of course if you need only two of 30 fields to send to a client you just send them. But if is the whole copies all the time as in my current project -- try to get rid of that DTO. I don't see any reason to use them. You send a business object to the client as a client asked. Why to use wrapper?

Answer 4

I think DTOs existence is related to JPA/Hibernate flaws. If you could always do transparently lazy initialization you will never use them. So using DTOs is a contract where my domain/workspace always lose (duplication everywhere). Summing up, you can use them but you have to hate them :)

Answer 5

I have several issues against using entities at presentation layer:

• Lock-in: This eventually creates tight lock-in between your presentation and model. It becomes expensive to change either, in large projects, even impossible. Modern tools are not quite there yet.

• Security: With model objects you easily transfer various database id information to your web pages. This is a clear security issue. Using dto:s you may hide these at the server with very simple session maps.

• Difference of needs: GUI views are rarely direct lists of model objects. More often they are something more, combined beasts, guish. The needs of the GUI tend to creep-in to your model obscuring it.

• Speed: With entities, every field is processed every time you read/write them. Since you are passing them directly to presentation layer you have a hard time trying to optimize your JPA -queries - almost impossible. I'm definitely going back to direct JDBC -access - like myBatis in future projects. Thus eliminating ORM.

I have a issues against DTO:s too:

• Extra DAO code.

Things considered, I'll vote for using dto:s for all projects, eliminating JPA too. So, my stack becomes something like:

• myBatis for database access
• POJO as DTO:s
• Stateless EJB for my DAO services.
• StatefulEJB for GUI backend.
• JSF for presentation.

Answer 6

working only with entities would be fine if the GUI controller sends object propertires to the forms and not entity objects. On the other hand, if entities are used and these entities have many-to-one relationships, then one should expect to see some nasty exceptions, if the entities are not eagerly fetched by the entity manager.

Such situations can be observed when attempting to populate tags of Spring MVC for example, or similar constructs of other GUI components.

Furthermore, DTOs are a very good place for placing extra annotations such as validation annotations or JAXB, etc