Is DTO pattern deprecated or not?

Question

In a complete Java EE application that's clustered is the DTO pattern still a valid option? The application in question uses EJBs Hibernate and Struts with Spring etc. Is there anything wrong with transferring domain objects in such a scenario?

EDIT: Just to clarify my question, with modern day resources and improvements in Java EE is there a reason not to just use domain objects? If there is not then isn't DTO pattern sort of fading out and shouldn't be used in new applications?

Acetamide

Answer 1

Is not deprecated. It depends on the application architecture if the DTO pattern should be used or not. For example, when you develop Web Services (using JAX-WS or JAX-RS), you should send DTO's over your web methods so a C# or Python client application may consume it, and your web method should not return an object which class has Hibernate annotations, remember than in other languages the Entity won´t be created with those annotations or other business logic inside.

---

EDIT (Based in your comment): That depends on the software architecture. For example, I'm working on a SOA project and we use DTO's for the Services Layer and the Presentation Layer. More deeper inside, we even use DTO's to handle database communication inside the services, we use only SP's to communicate with DB, so no Hibernate or any other ORM tools can work there, we could use Spring DAO and that framework uses DTO's too. You can find lots of DTO pattern in many applications nowadays.

More info that would be great for this question:

• Difference between DTO, VO, POJO, JavaBeans? (where basically, any DTO is a POJO).
• Core J2EE Patterns - Transfer Object

EDIT 2: Another source of information that will explain the main reason for using DTO's design, explained by Martin Fowler

• LocalDTO

Conclusion: DTO's are not an anti pattern. DTO's are meant to be used only when you need to pass data from one subsystem to another and they don't have a default or standar way to communicate.

Tavares

Yes in such a scenario I understand the use of DTO's. You are sending results in a DTO. But for internal application use DTO's aren't much of a use right? – Acetamide

According to your first like it's an anti pattern used to get around the fact that entity beans were not serializable. With an ORM that primary problem doesn't exist. – Acetamide

@Acetamide you're getting it wrong. From the formal definition for the EJB, it would be considered an anti pattern now. From the last lines in the first link: "for many people, DTOs and VOs are the same thing... Most of time, they follow the JavaBeans conventions and are thus JavaBeans too. And all are POJOs". – Tavares

No I got that part. But the thing that's bugging me is, for subsystems or modules of the same software it's no necessary to use DTO's for data transferring. The objects wiht JPA or Hibernate annotations won't pose a problem. And with a framework like Struts there is no need to use DTO's to transfer data to the view since domain model (hibernate objects) will do fine. – Acetamide

@Acetamide as the links state there, there is no need to use the DTO pattern in the case you're providing because the Hibernate objects will handle the data for you. If you have a scenario when the data in one subsystem (like presentation layer) is very different from the data in another subsystem (like your domain model), and this "new object" is not part of your domain model, then the DTO pattern is there to help you. Note that the DTO not neccesarily must implement the Serializable interface, that's just a J2EE solution to the problem they have encountered. – Tavares

Actually you can map the view to a domain object quite easily with the modern MVC frameworks. But I hear you. – Acetamide

@Acetamide yes, you can map it with MVC easily, but take note that maybe the system you're working on at the moment doesn't need the DTO. As my example states, we need the DTO pattern to communicate 3 distributed subsystems (2 in Java, 1 in C# .Net). The basis to use or not to use a software design pattern depends if and only if the problem is present (from your comments that's not your case, but mine is). – Tavares

Answer 2

A pattern is pure design. There is no "deprecation" of pattern, but less usage over time (or over-usage).
Personally, I don't see why not to use DTOs.
For example - at oVirt open source project we have entities representing business logic entities in the domain of Virtualization.
These entities should be either annotated by Hibernate annotations (actually, they are today, as we started working on hibernate POCs) and serve as the DTOs , and then have clean from annotations objects that will mapped to them (let's say, using dozer framework) and used by client
(I don't like have at client side code with unnecessary annotations), or the entities should serve as the client objects (value objects) passed to the client and we should have other classes serve as the DTO entities

The minus in the above approach is that you might have 2 parallel class diagrams - one for DTOs and one for value objects (that are used by clients) - but , in many cases in design , there is a trade-off.
You must understand the advantages and disadvantages and pick what is best for you (In our case, since the client side is GWT, it will be easier for us to go for separation to two class hierarchies, one that is DTO/server side and can be also annotated with more server side only annotations, and the other sent to the GWT client code).

Templet

Front end is not GWT where have I implied that? It's JSP's with a lot of javascript and jQuery. Yes zaske what I'm asking is whether there's a point in using them since modern day object models are whats holding the data. – Acetamide

Answer 3

It is a very useful pattern in Java EE.

I use a DTO to transfer related entity objects from EJB beans to the UI layer. The entity objects are fetched from DB in one transaction (see TransactionAttributeType.REQUIRED) and stored in the DTO object. The DTO is consumed in the UI layer.

Hypaesthesia