CODEWITHSUNDEEP
wcfentity-frameworkpocodatacontract
Musa Hafalir
Musa Hafalir

Reputation: 1770

Entity Framework POCO with WCF software design question

I am going to use Entity Framework and WCF in my application. The suggested practice, as I saw, is using POCO with Entity Framework and also using POCO classes as DataContracts. That is actually what POCO and Attributes are used for, -if I am not wrong.

However I am asked to use seperate classses for Entity Framework POCO's and WCF DataContracts. And to use a mapper between POCO's and DataContracts. Like, Foo and FooContract with same properties.

I am on the first approachs side but I wonder if the second approach (seperate classes approach) provides flexibility to the application or is it just a waste of effort.

I will be grateful if you can share your thoughts and experiences about using seperate classes for POCO and DataContracts, pros and cons about that.

Upvotes: 4

Views: 2012

Answers (3)

David Clarke
David Clarke

Reputation: 13266

I agree with @JustinNiessner and the best guidance I have found for architecting .NET applications using SOLID principles is a series of posts by .Net Junkie and the associated codeplex project. Clearly stated and informative, well worth reading.

Upvotes: 1

Justin Niessner
Justin Niessner

Reputation: 245489

Having separate classes for your POCOs and your Contracts will allow you to create Message Oriented services rather than RPC Style services.

Having Message Oriented services will allow your services to be more flexible, do more work, and be less tied to the objects that each service uses.

Message Based services also fall more in line with the spirit of Service Oriented Architectures. You can read more about Message Oriented services at Wikipedia.

I would also suggest picking up Service-Oriented Architecture: Concepts, Technology & Design by Thomas Erl if you are interested in the principles behind good service design.

Upvotes: 7

VinayC
VinayC

Reputation: 49245

Having different data classes at persistence layer and contract level gives you the most flexibility. For example, you may not want to expose all your persistent fields over a contract or you may want to expose different hierarchy of data over a contract etc. It also allows to change both independently of each other.

It may seem at first that using different classes at both level is duplication - but over long term, efforts are not so much (compared to flexibility that you get). You may get tempted to use same classes and develop different one when need arises but issue with that approach is that within short time frame, your services get tightly coupled with data classes rather than information/data that services should be exposing/working with.

Upvotes: 3

Related Questions