As described above I'm implementing a multi-tier architecture to work with WCF and Entity Framework 4 (with poco). Since I'm already have persistence ignorance with POCO I do need implement DTO or I can use WCF in its pure way?
The main quote is - I do need DTO to pass a lightweight object on the network or I can use my POCO entities.
What you guys recommend?
Its hard to answer unless you define what the "pure way" is. Are we talking SOA pure or WCF pure?
WCF proxies already are DTOs in a way because they do not bring along any business logic across your service contract. Creating another layer of DTOs on top of the proxy classes generated by WCF seems redundant.
The biggest question you want to answer is "how SOA is this solution?". You cannot share your POCO entities across service boundaries if you want to be SOA compliant. SOA is all about disparate contracts.
If you go all SOA based than you lose a lot of functionality because the classes your web tier will be working with most of the time will be stupid proxies. You'll have to repeat a lot of logic and you lost a lot of the "meta data, convention over configuration" functionality that MVC 2 provides.
If you throw the SOA buzzword into the shredder, which you should do ( http://soafacts.com/ ), then you'll have a much easier time sharing business logic and meta data information across tiers. If the only consumer of your web service is yourself than this method is probably your best choice.
This is where you could use DTOs to send across the wire instead of your POCO entities. The only downside is again, repeating logic, and lots of boiler plate ceremonial code that does nothing. Really depends on the size of your project. If its small, forget about DTOs, but if you have 20 developers working with 200,000 LoC than DTOs are probably worth creating.
As jfar said it depends on whether you are going to the be only one consuming the service, or whether the presentation tier is going to be you only.
If you are doing the later and it's only going to be you using your service then you can serialise you POCOs across the wcf service boundaries. This is something I have done recently and wrote this blog post about getting it to work. This will allow you to use the same entities in the app tier as well as the presentation tier.
Hope it helps.
The strongest reason to recommend a DTO when using WCF with EF is that EF database-first classes drag implementation-dependencies into your proxy classes. If you are using code-first with POCO classes, then there should be no implementation dependencies.
Try returning just your POCO classes, but then take a close look at the generated proxy classes. Make sure that there is nothing in those classes that is part of the EF infrastructure. If the proxy classes are clean, then you should be all set.
来源：https://stackoverflow.com/questions/2006142/using-a-wcf-service-with-entity-framework-4-and-dto