What is the best practice for sending data to the client: POCO or DTO?

pdiddy picture pdiddy · Sep 23, 2010 · Viewed 12.9k times · Source

I'm starting a project using EF 4 and POCO.

What is the best practice for sending data to the client ? Should I send the POCO or I should have a DTO instead?

Are there any issue I should be aware of when sending the entity (that is disconnected from the context) to the client ?

Is it a recommended practice to send the POCO to the client layer?

Answer

kzfabi picture kzfabi · Jul 23, 2011

I believe that we are mixing 2 definitions here that don't have relation with each other.

DTO or Data Transfer Object is a design pattern, you can use it to transfer data between layers, and also they don't have behavior. Martin Fowler explains this very well at: http://www.martinfowler.com/eaaCatalog/dataTransferObject.html

In the other hand we have POCO or Plain Old CLR Object. But to talk about POCO, we have to know where it started, that is POJO, or Plain Old Java Object. Martin Fowler with two partners coined the term and he explains it here: http://www.martinfowler.com/bliki/POJO.html

So POCOs can have behavior and everything you want. They are the same common classes you write in your daily-basis, they just gave them that name to call them in a short and easy-remember way.

In anwser to your second question, I think the best approach and the one I always go for is sending DTOs from the Busines Layer to everything that uses it (e.g.: your services, web site, desktop app, mobile app, etc.). This is because they don't have behavior and not pretty much than only properties in most of the cases, so they are light-weight and ideally to use in services, and of course, they don't reveal sensitive data from your business.

That being said, if you are planning to use DTO, I can recommend you to download EntitiesToDTOs, an Entity Framework DTO Generator that I just recently published at CodePlex, it is free and open source. Go to http://entitiestodtos.codeplex.com