Should the WCF service return an EntityObject or POCO / DTO class?

I looked at a lot of WCF examples using EntityFramework, and most of them seem to return some POCO or DTO class to the client.

I was wondering why this happened, because by default EntityObject includes [DataContract] attributes and implements INotifyPropertyChanged . EntityObject DTO or POCO class return better than an EntityObject (or vice versa)? Are there specific cases where it is better to use one return value over another?

+7
source share
2 answers

As a best practice, you definitely need to return the DTO / POCO class, which is explicitly designed as a data contract and has no save logic.

The reason is that if you pass an EntityObject, you make the assumption that the service consumer will refer to the same data context, and this violates the SOA principle with explicit boundaries. This reduces the possibility of reusing your service.

Microsoft has probably implemented DataContract in EntityObject to support some of its WCF-based database access tools, such as RIA. INotifyPropertyChanged is designed to support WPF binding and is not associated with WCF contracts or data.

+8
source

It is worth returning POCO in some cases when you do not know the save logic. I mean that the same POCO can connect to other ORMs or for other purposes. Ok, this is the advantage of POCO over ORM, but it also gives you a performance boost over EntityObject, which adds proxy / notification time.

Return POCO - you need to manually update the state of the object when it is received from WCF.

Return EntityObject - You get an object with a saved state.

0
source

All Articles