Entity Framework POCO with WCF software design question

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.

Unrestrained

Answer 1

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.

Afrit

I agree, and I would add that you may want to use a tool like AutoMapper to handle the mapping of data between your entities and your data contracts. automapper.codeplex.com – Gromwell

Thanks @Justin Niessner. That was helpful. And thanks @John Bledsoe. I will check that. – Unrestrained

To elaborate on the "more flxible ... less tied", this approach allows you to refactor the shape of your POCOs while maintaining the same contract for your DTOs. This can help you think separately about the two different concerns - "What information do I need within the server to perform the business functions", and "What is the best way to communicate this information between server and client". – Bugs

Answer 2

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.

Ott

Thanks for your beneficial explaination @VinayC. – Unrestrained

I fully agree with @VinayC. The flexibility provided by having different POCO classes is really helpful. You might want to change the entity data types in one layer like Bool in the data access layer but Yes/No in the presentation layer and vice versa. Automapper is really helpful in such scenarios. Although the amount of code increases by using this approach I feel it provides benefits in the long run. It makes the design more decoupled and can also help in terms of scalability and maintainance. – Noxious

Answer 3

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.

Tsunami