26

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?

razlebe
  • 7,134
  • 6
  • 42
  • 57
pdiddy
  • 6,217
  • 10
  • 50
  • 111
  • 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. – Youp Bernoulli Jul 23 '11 at 16:41

4 Answers4

25

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

Ɖiamond ǤeezeƦ
  • 3,223
  • 3
  • 28
  • 40
kzfabi
  • 2,065
  • 1
  • 22
  • 26
12

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.

Scott Arrington
  • 12,325
  • 3
  • 42
  • 54
  • 3
    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? – pdiddy Sep 23 '10 at 15:25
  • 5
    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. – Scott Arrington Sep 23 '10 at 15:59
  • 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 Sep 23 '10 at 18:48
  • 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! – Scott Arrington Sep 23 '10 at 18:58
  • 1
    What about this post here : http://stackoverflow.com/questions/3760244/entity-framework-poco-with-wcf-software-design-question – pdiddy Sep 23 '10 at 19:26
  • They seem to say the opposite, hehe that it provides better flexibility over the long term etc ... – pdiddy Sep 23 '10 at 19:27
  • 4
    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. – Scott Arrington Sep 24 '10 at 13:33
  • 7
    I see. so in a WCF scenario, it's good to not expose the POCO to the client. – pdiddy Sep 24 '10 at 14:18
2

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.

Ray
  • 4,038
  • 8
  • 36
  • 48
-1

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.

bufferz
  • 3,400
  • 5
  • 24
  • 37
  • 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. – pdiddy Sep 23 '10 at 18:50