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 business layer (either local or remote), replacing the need for data transfer objects? As far as I can see, using ORM classes presents problems of unnecessary eager loading, context management issues and tight coupling, but also saves a great deal of time and keeps things simple. Is there now a standard approach that generally favours one over the other (for the majority of situations)?

Answer 1

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 2

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 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 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...