I've been looking at a lot of WCF examples using EntityFramework and most of them seem to return some kind of POCO or DTO class to the client.
I was wondering why this was since the default EntityObject includes the [DataContract] attributes and implements INotifyPropertyChanged. Is returning a DTO or POCO class better than an EntityObject (or vise versa)? And is there specific instances where it is better to use one return value over another?
As a best practice, you should definitely have it return a DTO/POCO class that is explicitly designed as a data contract and has no persistence logic.
The reason is, if you pass an EntityObject, you are making an assumption that the consumer of the service will have a reference to the same data context, and this violates the SOA tenet of explicit boundaries. It reduces the reusability of your service.
It is probable that Microsoft implemented DataContract on the EntityObject to support some of their WCF-based database access tools like RIA. The INotifyPropertyChanged is for WPF binding support, and is not related to WCF or data contracts.
It is worth to return the POCO in some cases where you don't aware of persistence logic. I mean the same POCO can plugged to other ORM or for other purpose. Ok this is advantage of POCO over ORM but it also gives you performance boost over EntityObject which does add proxy/notifiers run time.
Returning POCO - You have to manually update the state of entity when received from WCF.
Returning EntityObject - You receive the entity with maintained state.
来源：https://stackoverflow.com/questions/4824058/should-a-wcf-service-return-an-entityobject-or-a-poco-dto-class