DTO is a pattern and it is implementation (POJO/POCO) independent. DTO says, since each call to any remote interface is expensive, response to each call should bring as much data as possible. So, if multiple requests are required to bring data for a particular task, data to be brought can be combined in a DTO so that only one request can bring all the required data. Catalog of Patterns of Enterprise Application Architecture has more details.

DTO’s are a fundamental concept, not outdated.

DTO as a concept (objects whose purpose is to collect data to be returned to the client by the server) is certainly not outdated.

What is somewhat outdated is the notion of having DTOs that contain no logic at all, are used only for transmitting data and “mapped” from domain objects before transmission to the client, and there mapped to view models before passing them to the display layer. In simple applications, the domain objects can often be directly reused as DTOs and passed through directly to the display layer, so that there is only one unified data model. For more complex applications you don’t want to expose the entire domain model to the client, so a mapping from domain models to DTOs is necessary. Having a separate view model that duplicates the data from the DTOs almost never makes sense.

However, the reason why this notion is outdated rather than just plain wrong is that some (mainly older) frameworks/technologies require it, as their domain and view models are not POJOS and instead tied directly to the framework.

Most notably, Entity Beans in J2EE prior to the EJB 3 standard were not POJOs and instead were proxy objects constructed by the app server – it was simply not possible to send them to the client, so you had no choice about haing a separate DTO layer – it was mandatory.

Although DTO is not an outdated pattern, it is often applied needlessly, which might make it appear outdated.

From Java guru Adam Bien:

The most misused pattern in the Java Enterprise community is the DTO.
DTO was clearly defined as a solution for a distribution problem. DTO
was meant to be a coarse-grained data container which efficiently
transports data between processes (tiers). ~ Adam Bien

From Martin Fowler:

DTOs are called Data Transfer Objects because their whole purpose is
to shift data in expensive remote calls. They are part of implementing
a coarse grained interface which a remote interface needs for
performance. Not just do you not need them in a local context, they
are actually harmful both because a coarse-grained API is more
difficult to use and because you have to do all the work moving data
from your domain or data source layer into the DTOs. ~ Martin
Fowler

Here is a Java EE specific example of a common but incorrect use of the DTO pattern. If you’re unfamiliar with Java EE, you just need to know the MVC pattern: a “JSF ManagedBean” is a class used by the View, and a “JPA Entity” is the Model in the MVC pattern.

So, for example, say you have a JSF ManagedBean. A common question is whether the bean should hold a reference to a JPA Entity directly, or should it maintain a reference to some intermediary object which is later converted to an Entity. I have heard this intermediary object referred to as a DTO, but if your ManagedBeans and Entities are operating within the same JVM, then there is little benefit to using the DTO pattern.

Futhermore, consider Bean Validation annotations (again, if you’re unfamiliar with Java EE, know that Bean Validation is an API for validating data). Your JPA Entities are likely annotated with @NotNull and @Size validations. If you’re using a DTO, you’ll want to repeat these validations in your DTO so that clients using your remote interface don’t need to send a message to find out they’ve failed basic validation. Imagine all that extra work of copying Bean Validation annotations between your DTO and Entity, but if your View and Entities are operating within the same JVM, there is no need to take on this extra work: just use the Entities.

IAmTheDude’s link to Catalog of Patterns of Enterprise Application Architecture provides a concise explanation of DTOs, and here are more references I found illuminating:

• HOW TO DEAL WITH J2EE AND DESIGN PATTERNS
• How to use DTO in JSF + Spring + Hibernate
• Pros and Cons of Data Transfer Objects
• Martin Fowler’s description of DTO
• Martin Fowler explains the problem with DTOs — apparently they were being misused as early as 2004

Absolutely not! Just recently I learned lessons about better using DTOs rather than your business object you use (possibly bound to your ORM mapper).

However, just use them when they’re appropriate to use and not just for the sake of using them because they’re mentioned in some good pattern book.
A typical example which just comes to my mind is when you expose some kind of interface to 3rd parties. In such scenario you’d like to keep the exchanged objects quite stable which you can usually achieve nicely with DTOs.

One place I’ve found DTOs to be especially useful is in containing logic for API responses. With this pattern it’s easy to manage different types of responses from objects to various formats in a testable manner. Using this pattern at my current role we were able to start testing the response formats for our APIs which has been valuable since our stack is becoming more isomorphic with various clients (http/mobile). Definitely not outdated.

DTO is really powerful.
One use is to compose data from multiple objects to be transported.
The second use is to hide your data object details away from the rest of the application and this can give you the ability to change the data objects. For example if you were using mysql database then you changed to mongodb your data object can change as result. to avoid the change in the rest of your application you can use DTO and then just change the mapper using dependency injection to avoid such change.