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

25
votes

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?

4
c#.netentity-framework-4pocodto
And what about Self Tracking Entities? They can save you a lot of extra work for insert, update and delete operations server-side. Don't believe the poco's have this functionality. And I would advice you to read Julie Lerman's "Programming Entity Framework". She explores all kinds of options including: poco's, dto's and self tracking entities. – Bernoulli IT

4 Answers

24
votes

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

12
votes

For me, one of the main reasons to use EF4 with POCO is the fact that you don't need DTO's. I can understand using DTO's with traditional EDMX files where your entities are pretty bloated, but this isn't the case.

Your POCO obviously needs to be serializable, but there really shouldn't be any issues specific to sending POCO entities that don't also occur with DTO's.

2
votes

I have a bit different opinion from above opinions. I believe DTO or ViewModel is still needed for out side of the Server Layer. In real world application, there is a few view layer which only need one Domain Object, that is, almost every views need multiple Domain Objects. And all those Domain Objects are wrapped in one DTO or ViewModel Class. This is why I insist DTO or ViewModel is still needed even though they are POCO.

-1
votes

I would consider EF4 entities business models AND viewmodels rolled into one. They already implement PropertyChanged out of the box, for example. Partial classes can provide custom functionality if you need. Mirroring the entities with your own safety layer creates unnecessary work and maintenance, in my opinion.

I'm a believer in separation of business logic and everything else. However in the case of EF4 the work is already done for you. Go nuts.