One recurrent question when it comes to real world usage of Domain Models is how to integrate the Presentation and the Business Layers. As we saw here before Layers is a disciplined approach to manage dependencies among objects. The question raised is about how to integrate the two topmost Layers in the diagram below.
I have to admit that I’m not sure why people have doubts about the relationship between these two Layers but not about the other interactions. For me it’s exactly the same: the bottom Layer has an API and the top Layer uses that API to perform its task. The objects received and returned by the API are common objects that abstract implementation details about themselves and their Layer. The API will often be implemented as a Façade and the objects returned from it will be proper objects, with state and behavior.
But that is not what everyone thinks. A common technique is to use a Data Transfer Object as the communication medium between those Layers.
I think that this technique is not only overkill but it may create a terrible architecture for an application.
DTO Quick Intro
Before getting to what may guide people to think that the Data Transfer Object is a good solution let’s revisit what the patter is all about.
Suppose you have two nodes (e.g. Virtual Machines, processes, servers, web services… ‘node’ here means something that has its own address space) and want them to share objects between them.
A common pattern is to send a proxy or copy of the object to the client. The problem is that if your object follows proper Object-Orientation guidelines it will rely on other objects to perform its tasks. Those objects may not have been copied to the new server therefore operations performed by the local proxy/copy may incur in expensive RPC (or IPC) communication.
The Data Transfer Object as catalogued by Martin Fowler is a Distribution Pattern in which you wouldn’t send only a proxy/copy of the object to the client but a coarser grained object that contains pretty much everything that the client will need.
The coarser grained object is optimized for distribution. I like to refer to it as a “zipped” version of the object. This technique has some undesirable effects: suddenly you have to maintain two different hierarchies of objects, with heavy coupling between those.
People use DTOs -even if they don’t know that the technique is catalogued as a Pattern- only because that’s one of the few ways we know to make distributed computing work. Without this Pattern most distributed systems would be extremely slow and inefficient. DTOs are useful for distributed computing but it is very unlikely that they are needed for local communication, such as interaction among Layers.
I’ve faced some arguments for internal DTOs before. We’ll address those in the next sections.
“Because MVC Requires that”
There is a huge confusion about the MVC Pattern in our industry, specially about what is the so-called Model in it. Let’s revisit the MVC Pattern to see if we can find something that guides to uncertainty about what to do.
The original MVC paper describes Model as:
A Model is an active representation of an abstraction in the form of data in a computing system
When cataloguing the MVC Pattern, Martin Fowler says:
In its most pure OO form the model is an object within a Domain Model. You might also think of a Transaction Script as the model providing that it contains no UI machinery.
In Refactoring, Fowler says:
The gold at the heart of MVC is the separation between the user interface code (the view, these days often called the presentation) and the domain logic (the model). The presentation classes contain only the logic needed to deal with the user interface. Domain objects contain no visual code but all the business logic. This separates two complicated parts of the program into pieces that are easier to modify. It also allows multiple presentations of the same business logic. Those experienced in working with objects use this separation instinctively, and it has proved its worth.
So far there’s no relation between MVC and Layers. This is due the fact that the Pattern arose before Layers became a catalogued design Pattern. There’s no direct relation between Layering and MVC, you can use one without the other.
Using MVC within a Layered architecture is useful though. Craig Larman explains how MVC can be used to bind those components together:
This is a key principle in the Pattern Model-View-Controller (MVC). MVC was originally a small-scale Smalltalk-80 pattern, and related data objects (models), GUI widgets (views), and mouse and keyboard event handlers (controllers). More recently, the term “MVC” has been co-opted by the distributed design community to also apply on a large-scale architectural level. The Model is the Domain Layer, the View is the UI Layer, and the Controllers are the workflow objects in the Application layer.
So it is possible to use the MVC to organize Layers. Based on the previous paragraphs it is probably possible to draw a picture like this:
So Layers and MVC are not really related and we know our Domain Model plus the whole infrastructure that supports it is our MVC Model. Let’s see how the original MVC related Model and View and see if they have any funny way of talking to each other.
VIEW
DEFINITION
To any given Model there is attached one or more Views, each View being capable of
showing one or more pictorial representations of the Model on the screen and on hardcopy. A
View is also able to perform such operations upon the Model that is reasonabely associated
with that View.
[…]
VIEWS
A view is a (visual) representation of its model. It would ordinarily highlight certain attributes of the model and suppress others. It is thus acting as a presentation filter.
A view is attached to its model (or model part) and gets the data necessary for the presentation from the model by asking questions. It may also update the model by sending appropriate messages. All these questions and messages have to be in the terminology of the model, the view will therefore have to know the semantics of the attributes of the model it represents. (It may, for example, ask for the model’s identifier and expect an instance of Text, it may not assume that the model is of class Text.)
So the View not only is tied to the Model but it also will filter its data and display only what is relevant. That is very interesting because some people use Data Transfer Objects to create different viewpoints.
But according to the MVC documentation that is actually the View’s role. That makes the DTO in the previous model useless.
Therefore there’s nothing in the MVC Pattern per se that would require you to use internal DTOs. The View is responsible for accessing the Model and extracting what should be displayed in it.
Using it to Forbid Calls to Dangerous Methods
Another common reason given to justify the internal DTO approach is to forbid UI code (i.e. MVC’s View and Control) to call “business methods”. After some time I figured out that by “dangerous” people usually mean business methods that cause side-effects.
Using a DTO you can hide those methods and, theoretically, people developing UI won’t be able to call them
At first this sounds reasonable. When using Layers people should really not call those methods in the Presentation. But my solution for this is: Just don’t call them!. In a responsible team there’s no need for that, developers are not children.
Even if you can’t trust them there’s always a way to call those methods if they want to, it does not matter how many layers of DTOs you use to hide your business objects a developer can always find a way.
Even if you really really want to do such a thing there are other means. The simplest solution that I can think of is to define checkstyle (or equivalent) rules that forbid those calls and break the build. If you really want to go all fancy just define an interface that doesn’t have the “dangerous” methods and use something like Macker to avoid calls to the implementation.
Not only there’s no need for DTOs in this case but they will not achieve the desired goal.
Loose Coupling
Dependency from the Presentation Layer to the Business Layer may require the UI code to be changed whenever there’s a change in the Business Objects. Some people think that this is a huge problem and suggest that DTOs between those two Layers could help. I think that a DTO here makes matters worse instead of helping.
Without the DTO we would have two components, business and view, and whenever we change business it is possible that we need to change the view.
But adding a DTO the problem gets worse. We now have three components: view, DTO and business. When business changes it is very likely that DTO has to be changed and this will potentially require a change in the view.
So it doesn’t solve the coupling problem, only adds another coupled component to it. Instead of synchronizing two components you have to do that with three.
The first thing to know is that you can’t avoid coupling, regardless of how much indirection you use. Remember what David Wheeler said: “Any problem in computer science can be solved with another layer of indirection. But that usually will create another problem”.
The key to reduce coupling between Presentation and Business is to define a good API. Do not let much detail about how the Business Layer is implemented leak to the Presentation Layer. If your Presentation Layer has to be extremely decoupled from the Domain Model think about a Presentation Model.
Concluding
As I said before I am not sure why the Data Transfer Object Pattern was choose to integrate Presentation and Business Layers. I think that there are two main drivers:
- Data Transfer objects are often misused as records. Even after decades doing Object-Oriented programming and using OO tools and languages some people still run unconsciously to the Procedural style where a problem is solved by dumb data structures plus smart functions, not by objects. There’s nothing wrong going Procedural if you know you are doing that but in lots of cases people can’t tell the difference between Procedural and OO code.
- Sun evangelized the use of what they call Transfer Objects (previously called Value Objects) in its EJB 2.x architecture. Those are internal or remote DTOs used to solve some problems introduced by Entity Beans and J2EE technology in general. In newer versions of the EJB spec and in applications that don’t use that technology –e.g. using Hibernate instead- the Pattern is not only not required but also introduces new problems.
The cases presented here are those I hear about more often. I’m sure there are many others but I guess they share the same problem of trying to use the wrong Pattern to solve a problem that may not even exist. And of course that there are cases where internal Data Transfer Objects are valuable. I can’t think f any but I can’t deny they exist.
Nice post Shoes.
Is common to see people “applying” patterns in a wrong way, they use without asking why is it for.
It was very enlightening.
Cheers!
One case I think is missing is when you use DTOs to avoid mismatch between the lifecycles of the two layers.
For example, most UI frameworks require you to expose public getters/setters, thus, breaking your beautiful encapsulation. Or, some UI frameworks always serialize objects to persist them between requests, and this could break some assumptions you may have for your domain objects (persistence sessions, JDBC connections, and other non-serializable stuff). Some try to work around the issue, by detaching/reattaching things between requests, but you end up coding your domain layer to work around side-effects caused by the workarounds of the UI framework, which is not an optimal solution either…
Another problem (but this is a real problem) is that some UI frameworks expose too much to ‘the world’. For example, in Struts2, all properties navigable from the Action are accessible (and modifiable) by HTTP parameters. For example, you are coding a ShoppingCart, and an action expose the ShoppingCart object with a getter getShoppingCart(), so the ’shoppingCart.totalCost’ property can be rendered. But, ShoppingCart exposes not only the totalCost property, but ‘items’, a collection of ‘Item’, which exposes ’stockItem’, which exposes ’supplier’, which exposes ‘name’. So, one could add a parameter ’shoppingCart.items[0].stockItem.supplier.name=…’, and change the supplier’s name (say, Microsoft) to anything. Since Hibernate (and any JPA-compatible lib, AFAIK) saves everything that’s changed in the current session (not only what you explicitly save), it could be a serious security issue. DTOs and explicit copying of properties is one (legitimate) way to solve this problem. Not really transporting anything, but it’s the same thing, the stupid object with getters and setters for everything which exists only to hold temporary state.
One other problem (which probably is not in the scope of your article) comes around some limitations, not necessarily technical. A sad reality is that most programmers don’t yet understand OO well, and the procedural paradigm reigns in average-skilled teams. If one is in charge of a team of junior/unskilled/coming-from-codefusion programmers, DTOs, procedures, and plain-old-Struts-like-MVC probably are the most viable options. But well, I don’t think these guys read your blog anyway.
Hi Tetsuo,
I still can’t see the need for DTOs in this case. It looks to me that what you *may* need is a Presentation Model.
Another case for Presentation Model, I’d say. Using DTO in this situation would incur in the same mistake Sun did when using VO/TO/DTO to cover for EJB failed spec.
This is a true fact but my suggestion would be: if your developers can’t get Object-Orientation do not pretend they can. Assuming you have to work with them and they won’t improve (time constraints, whatever) create an interface in which they can be productive with. Do not call this a DTO because it’s not, it’s just good old procedural programming.
cheers
Nice
(quick’n'dirty translation)
I’ve seem DTOs used in situations where you have a method with a signature like this:
public bool CreateUser(string login, string pass, string name, date birthday, string address, string phone, string petName, string colorCar, string mothersName, …)
So it becomes:
public bool CreateUser(UserDTO userInformation)
But now I think that it would be better to have User as a Model and allow the presentation to do something like this:
User user = new User(…);
if(user.Save()) showSucess();
else showError();
——-
desculpa postar em português, mas sinto-me mais a vontade
o caso em que eu vi usarem DTO foi o seguinte:
para fazer um cadastro de usuário
havia 20 campos que poderiam ser preenchidos
e o método no businnes:
public bool CreateUser(string login, string pass, string name, date birthday, string address, string phone, string petName, string colorCar, string mothersName, …)
então, ao invés de ter esse método gigante, criaram um dto: UserDTO
o método mudou para:
public bool CreateUser(UserDTO userInformation)
porém, fique pensando um pouco e percebi que isso era feito pq a classe User era colocada numa camada chamada “Entidades”, composta de classes “burras”, soh para mapeamento Hibernate
e então criamos essa camada de Bussines com várias classes do tipo: “???Manager”, por exemplo: UserManager (a classe que possuía o método com vários parametros)
mas, pensando agora, talvez a melhor abordagem fosse considerar a classe User como business, assim, na própria camada Presentation a gente poderia fazer algo como:
User user = new User(…);
if(user.Save()) showSucess();
else showError();
e a camada de Infrastructure seria o modo pelo qual a classe user teria acesso ao banco de dados…
isso tb resolveria o segundo problema que eu via na arquitetura: a gente não podia usar a classe User diretamente na Presentation (pq estavam separadas pela camada de Business no meio)
se você puder validar esse pensamento… agradeço
abraços e bom post
Nice post Shoes.
Would it be a problem to have my presentation model implemented with some framework’s “stuff”?
I’m working on a project using GWT + Ext-GWT + PHP.
The PHP side is modelled using principles and ideas from Domain Driven Design and comunication is done in a kind of RESTful Service.
The client side (GWT + Ext-GWT) has a presentation model that has classes inheriting from Ext-GWT base model classes to make it work with their components.
The data comes from PHP formatted as JSON and is translated to the presentation model by Ext-GWT library. When submitting, we use pure HTTP POST / GET.
Do you think I can have any problem in the future with this approach?
Thanks for your time,
Fábio Rehm
I agree with what Tetsuo said about different requirements for UI vs Business layers. A domain model should not have public getters for its fields, so how do you extract the data? I agree a presentation model is a better name for this, but often that’s just a conceptual difference… You still end up with an object with a lot of public properties or fields and not a lot of behavior.
I always put an @ instead of a . in blog address for some reason… I thought I would correct that.
Thanks!
@Ruppel
I completely forgot that case but it’s definitely a common use of Internal DTOs. In your case I’d say that what you miss is an abstraction, a proper object. In Object-Orientation it is very odd to have a bunch of parameters in some method’s signature, probably those should be grouped in abstractions.
I suggest that you create an User object in your Presentation Layer but let saving and any other Model logic to be performed in the right Layer.
@Fábio Rehm
What you described looks OK for me but it’s hard to say without context.
@Robin Clowers
Presentation Model is not just a different name for Internal DTO. A Data Transfer Object is an object specially crafted to help in distributed computation. A Presentation Model is a model (just like a Domain Model) that expresses the state and behaviour of the UI Layer in a system.
The Presentation Model should not be composed of dumb objects, it should be a proper object oriented piece of code. A DTO doesn’t have to be dumb although sometimes it is pointless to have logic in these “payload objects”.
Cheers all
With EJB3 and Hibernate having DTO is sometimes recommended to avoid the detached use of Entities.
In some situations DTOs are also used as they are created with persistente/serialization frameworks like Jax-B or even simple serialization (requiring stable/compatible format).
(those are just keywords not arguing pro or con your approach of avoiding DTOs.)
Greetings
Bernd
Very usefull and enlightening post. People use DTOs all the time and I confess that I took a time to understand the mistake. Congrats!
Great post. I really liked the “MVC vs Layers” comparison, which seems to be totally ignored here in the comments.
I agree that MVC and Layers are orthogonal. Just different ways of seeing the same thing; different representations.
Great post, Shoes.
Happy new year.
Very enlightening post Shoes. Some years ago I worked on a project in which DTO’s were used to solve problems you mentioned at EJB 2.x architecture. BTW, instead of DTO’s I prefer to define interfaces which abstracts the details and methods that cause side-effects.
A use we have for DTOs is to separate the objects/data that are passed in to a set of Service Methods (web services) from what is necessary to be passed down in to the underlying business and persistence layers. That way we separate any changes in the underlying framework from the API/Service Interface used by clients.
I do concur with everything else that has been said.