Entity framework, POCO, DTO

views:

171

answers:

+4 Q:

Entity framework, POCO, DTO

Hi,

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?

+3 A:

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 Anderson 2010-09-23 14:48:29

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 2010-09-23 15:25:03

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 Anderson 2010-09-23 15:59:29

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 2010-09-23 18:48:52

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 Anderson 2010-09-23 18:58:31

What about this post here : http://stackoverflow.com/questions/3760244/entity-framework-poco-with-wcf-software-design-question

pdiddy 2010-09-23 19:26:48

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

pdiddy 2010-09-23 19:27:26

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 Anderson 2010-09-24 13:33:17

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

pdiddy 2010-09-24 14:18:37

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 2010-09-23 16:16:51

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 2010-09-23 18:50:01

ansaurus

tags:

views:

answers:

Entity framework, POCO, DTO

related questions