WCF, Entity Framework & Data Contracts

Question

Using VS 2008 & .NET 3.5 SP1:

I am using WCF to allow clients to connect to a service that reads and writes database entries using Entity Framework. By default

Answer 1

I basically see two things you can do:

1. Either you remove those items you don't want to expose from the DataContract by manually removing the [DataMember] attribute on those items; in that case, WCF will not serialize the properties out
2. You define your own WCF DataContract classes with just those members you want, and you come up with a logic to convert from your EF entities to your WCF DataContract, using e.g. something like AutoMapper to eliminate (or at least limit) the tedious assigment operations between EF and WCF entities.

Marc

Answer 2

Are you aware that your entities do not need to map one to one with the database? In particular, you can leave out columns, or even entire tables that are not relevant.

The entity model is meant to be a conceptual model. You can easily create a set of entities for exposure to one set of clients (web services, perhaps), and another set, mapping to the same database, that is meant for a different client (web application, perhaps).

On the other hand, I always recommend against ever exposing Entity Framework objects through a web service. Microsoft unfortunately exposes implementation-dependent properties by marking them with [DataMember]. I just now tried this with a simple service returning a SalesOrderHeader from AdventureWorks. My client received proxy versions of the following EF types:

• EntityKeyMember
• StructuralObject
• EntityObject
• EntityKey
• EntityReference
• RelatedEnd

These are not things your clients need to know about.

I prefer exposing Data Transfer Objects, and copying the properties from one to the other. Obviously, this is better done through reflection or code generation, than by hand. I've done it through code generation in the past (T4 templates).

An option I haven't tried is AutoMapper.

Answer 3

We use separate classes for the DataContract objects. We have an interface with one method, ToContract(), and all of our entities implement this interface in a partial class file. It's extra work, and it's boilerplate, but it seems the simplest way to get the separation and granularity of control we need.