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

java

best-practices

design-patterns

object-oriented-programming

byNikita Barsukov·Nov 28, 2024

DTOs are seen as an anti-pattern when they transform robust object-oriented models into anemic models—essentially, hollow shells where data is decoupled from its associated operations or behaviors. But this view doesn't capture the entire picture. DTOs can be effective in separating application layers, maintaining data integrity, and fortifying security. Here's a quick glimpse:

// Lean, mean DTO machine
public class UserDTO {
    private String username;
    private String email;
    // Accessors as accessorized as an Oscar night attendee.
}

// Serving up user data with a side of DTO
public UserDTO transferUserData(User user) {
    // Now you're cooking with DTO gas!
    return new UserDTO(user.getUsername(), user.getEmail());
}

This code transfers just the needed slices of user data, preventing data leakage and unnecessary system exposure. It's like the secret service for your data!

Weighing the pros and cons

The introduction of DTOs often leads to a twinning of data, which in turn inflates the architectural costs. A vital question to ask here is, do the benefits of using DTOs outweigh the duplication costs? The answer varies on a case-by-case basis. In scenarios where efficiency is prized, DTOs can drastically shrink the data payload size. But in a rich domain model, DTOs might be viewed as an extra, unwieldy layer.

On the technological front, DTOs are no longer the only game in town. Modern frameworks like Spring and techniques like serialization, LINQ, and anonymous types can be viable alternatives for data transfer.

DTOs vs. alternatives

Instead of DTOs, POJOs (Plain Old Java Objects) may handle data transfer without the necessity for a distinct DTO layer. When operating with .NET, dynamic DTO creation is a technique to streamline the efficiency of data transfer operations. With instant DTOs, you can benefit from DTOs' strengths only when required, bypassing unnecessary overhead.

Visualizing the complexity of DTOs

Balancing DTO explosion with domain models

DTOs separate from domain models, but this separation must offer tangible benefits to compensate for the added complexity of DTOs. Beware of DTO explosion i.e., ending up with too many DTOs cluttering your codebase, leading to a labyrinth of objects. This may also render your domain models anemic, intellectually and operationally malnourished beings devoid of behavior.

DTOs: saviors of the presentation layer?

For the presentation layer, DTOs can convert intricate domain models into more easily digestible data structures, ensuring that your user interface gets served just the right amount of information. Remember, no one likes a buffet of irrelevant information!

The architectural evolution

DTOs originally catered to three-tier architectures. However, as architectures evolve, DTOs may not be the ideal fit in modern patterns like microservices, which favor lightweight and decentralized approaches to data handling.

The DTO impact on domain integrity

The clash of OOP principles

When DTOs give birth to an anemic model, it is essentially at odds with the ideals of OOP, where encapsulation of behavior with data should ideally occur.

The DTO effect on the domain model's integrity

The integrity of your domain model must remain intact, irrespective of the use of DTOs. Attention must be paid to the granularity and cohesiveness of your domain entities in the shadow of DTOs.

The technology evolution vs. DTOs

The mandate for using DTOs should always be redefined in the context of evolving technology. Just because DTOs are widely used doesn't mean the path of innovation and discovery of alternative solutions should be barricaded.

DTOs as a design tool

DTOs are tools, not rules. Their deployment demands careful assessment and alignment with the right design principles and best practices to prevent the desertification of misuse or overuse.

explain-codes / Java / Why are data transfer objects (DTOs) an anti-pattern?

Linked

Dto and DAO concepts and MVC



Data access object (DAO) in Java



Difference between DTO, VO, POJO, JavaBeans?



What exactly is Spring Framework for?



Places where JavaBeans are used?

