Why Are Data Transfer Objects (Dtos) an Anti-Pattern

Why are data transfer objects (DTOs) an anti-pattern?

Some projects have all data twice. Once as domain objects, and once as data transfer objects.

This duplication has a huge cost, so the architecture needs to get a huge benefit from this separation to be worth it.

Is DTO pattern deprecated or not?

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.

Which java pattern to implement with similar Data Transfer Objects

Here you must reason whether using inheritance/composition makes sense or not. With the names of class ONE and TWO it is hard to say, so let me take another example. Say, we have a Vehicle and a Phone class like so,

class Vehicle {
    String model;
    String color;
    String type;
}

class Phone{
    String model;
    String color;
    String type;
    String brand;
    Integer core;
    Integer ramInGB;
}

Here Vehicle and Phone class have some fields in common. But you cannot change Phone like so

class Phone{
    Vehicle v;
    String brand;
    Integer core;
    Integer ramInGB;
}

or

class Phone extends Vehicle{
    String brand;
    Integer core;
    Integer ramInGB;
}

Before using any design pattern anywhere, you must reason whether using it in that scenario is justified. Don't use design patterns just for the sake of using it.

Coming back to the example, if ONE and TWO are not related in any sense you should leave them be. But if they are you can use either inheritance or composition. Here is a link, you might wanna go through before making that choice.

What is a Data Transfer Object (DTO)?

A Data Transfer Object is an object that is used to encapsulate data, and send it from one subsystem of an application to another.

DTOs are most commonly used by the Services layer in an N-Tier application to transfer data between itself and the UI layer. The main benefit here is that it reduces the amount of data that needs to be sent across the wire in distributed applications. They also make great models in the MVC pattern.

Another use for DTOs can be to encapsulate parameters for method calls. This can be useful if a method takes more than four or five parameters.

When using the DTO pattern, you would also make use of DTO assemblers. The assemblers are used to create DTOs from Domain Objects, and vice versa.

The conversion from Domain Object to DTO and back again can be a costly process. If you're not creating a distributed application, you probably won't see any great benefits from the pattern, as Martin Fowler explains here.

Where Should Data Transfer Objects (DTOs) be declared in a layered application using DDD

As DTOs are used for transferring data from your application to e.g. client applications, they should be declared in the layer that handles the service calls to your application (the outermost layer). Whether you call it application layer or something else (at my company we call it 'service layer') is up to you.

---

Related Topics