This is an AMP version of the article, its original content can be found here.

Data Transfer Object Is a Shame

DTO, as far as I understand it, is a cornerstone of the ORM design pattern, which I simply "adore." But let's skip to the point: DTO is just a shame, and the man who invented it is just wrong. There is no excuse for what he has done.

By the way, his name, to my knowledge, was Martin Fowler. Maybe he was not the sole inventor of DTO, but he made it legal and recommended its use. With all due respect, he was just wrong.

The key idea of object-oriented programming is to hide data behind objects. This idea has a name: encapsulation. In OOP, data must not be visible. Objects must only have access to the data they encapsulate and never to the data encapsulated by other objects. There can be no arguing about this principle—it is what OOP is all about.

However, DTO runs completely against that principle.

Let's see a practical example. Say that this is a service that fetches a JSON document from some RESTful API and returns a DTO, which we can then store in the database:

I guess this is what will happen inside the loadBookById() method:

Am I right? I bet I am. It already looks disgusting to me. Anyway, let's continue. This is what will most likely happen in the saveNewBook() method (I'm using pure JDBC):

This Book is a classic example of a data transfer object design pattern. All it does is transfer data between two pieces of code, two procedures. The object book is pretty dumb. All it knows how to do is ... nothing. It doesn't do anything. It is actually not an object at all but rather a passive and anemic data structure.

What is the right design? There are a few. For example, this one looks good to me:

This is what happens in bookById():

This is what happens in

What happens if there are many more parameters of the book in JSON that won't fit nicely as parameters into a single createBook() method? How about this:

There are many other options. But the main point is that the data never escapes the object book. Once the object is instantiated, the data is not visible or accessible by anyone else. We may only ask our object to save itself or to print itself to some media, but we will never get any data from it.

The very idea of DTO is wrong because it turns object-oriented code into procedural code. We have procedures that manipulate data, and DTO is just a box for that data. Don't think that way, and don't do that.

PS. There are a few another names of DTO: business objects, domain objects (not in DDD), entity objects, JavaBeans.