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

Question

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?

Solution 1

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.

Solution 2

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

Solution 3

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.

Comments

[pdiddy]

So exposing business model to client is not a bad practice? For some, it's a bad practice to expose the business model to the external world ... what do you think about this?

[Scott Arrington]

To me, the POCO should be very... well.. "plain" so to speak. And if that's the case, what's the harm in sending it to a client? What are your DTO's going to look like? Are they going to mirror the POCO almost exactly? Then why put yourself through the headache? DTO's are nice when you want to eliminate a lot of cruft, but I don't really see the harm in sending your POCO's to the world if they don't contain sensitive information that you don't want exposed.

[pdiddy]

Thanks, I guess I will send the POCO object. I just had the impression that it was a bad practice in general. But In my case, we are not really exposing them to the external world. We are exposing to our own client application.

[pdiddy]

I'm opting to not use the EF entities, but the POCO since EF has a good support for PI. But thanks for your answer.

[Scott Arrington]

If you were doing traditional EF4 with an EDMX file full of heavy-lifting entities, then I would use DTO's all the way. But since you're using EF4 with POCO's, it isn't necessary (especially internally). Cheers!

[pdiddy]

What about this post here : stackoverflow.com/questions/3760244/…

[pdiddy]

They seem to say the opposite, hehe that it provides better flexibility over the long term etc ...

[Scott Arrington]

That post is specific to WCF. The idea is that you gain flexibility by separating your POCO entities from WCF data contracts. I can't say that I disagree, but I didn't see any mention of WCF in your original post. I often use "view models" as the data contract object on top of EF entities when working with WCF services.

[pdiddy]

I see. so in a WCF scenario, it's good to not expose the POCO to the client.