The past month or two I've been struggling with an architectural issue and haven't been able to find a good answer. The fact of the matter is, Silverlight, WCF, and the Entity Framework don't play nice together. Here's why...

You start out by adding your Entity Model to your WCF app or an assembly that WCF references. You expose your EF business objects from your WCF methods and consume them from your Silverlight app. The problem is that this will generate the EF business objects under each service proxy namespace rather than in one central namespace. Here's an example of this case:

Service Proxy Namespace Hell:

Let's say you have 2 ADO.NET Data Services - UserService and GeographicService.

There's an Add User form that has a combobox with all of the states. You call GeographicServiceProxy.GetStates(), which returns List<GeographicServiceProxy.State>. You bind the combobox to this list.

When Save is pressed, you construct a UserServiceProxy.User object which you'll then send to UserServiceProxy.Add(user). The problem is that you now can't set the UserServiceProxy.User.State property, as your dropdown contains GeographicServiceProxy.State objects. You'll get a build error if you try to assign directly between them and you end up having to manually set each property from one to the other, which doesn't work when we're talking about an entire application. Basically, all of your business objects are duplicated in the namespace of each service proxy and you can't directly assign between them due to the different namespaces, aka Service Proxy Namespace Hell.

The solution in a normal client environment (not Silverlight) would be to reference the project containing the business objects, then when adding the Service References, so long as you have "Reuse types in all referenced assemblies" selected, it won't generate the methods and will correctly have the business object types be of your referenced assembly types, such as MyNamespace.BusinessObjects.MyBusinessObject, rather than within the individual service proxy namespaces, such as MyNameSpace.Silverlight.Service1Proxy.MyBusinessObject.

Silverlight half-baked referencing:

However since Silverlight doesn't let you reference a non-Silverlight assembly, this doesn't fly. Let's say you try to get around this by creating a Silverlight class library and adding a link to the Entity Model (edmx) file. The Silverlight class library won't build unless you manually edit the project file and add references to .NET assemblies such as System and System.Data. Now you reference this Silverlight class library within your Silverlight app and you end up with build errors because you now have clashing Silverlight and non-Silverlight assemblies, such as .NET's "System" vs. Silverlight's "system". Dead end...

The alternative, and the method I'm currently using, is to create custom business objects that match the EF business objects. You can then expose these from your WCF service methods. Let's say you wanted to call a WCF Add(entity) method. You would pass in a custom business object, convert it property by property to an EF business object, then save it. If you wanted to call a WCF Get() method, you would use linq to get the EF business object, then property by property you'd convert it to a custom business object to return from the method. As you can see, this results in a lot of extra code being written and you now have opened up your WCF/EF code to having to deal with objects property by property, losing some of the beauty. Now that your WCF service methods are exposing custom business objects, you need your Silverlight application to reference the custom business objects. What you have to do is create a new Silverlight class library project, doing add existing items, selecting all of your business business object classes, and doing add as link (notice the down arrow next to the Add button.) Now you can reference this new Silverlight class library within your Silverlight application and add your service references, which will generate the proxy business objects within their correct namespace so long as you have set "Reuse types in all referenced assemblies".

Alternatives to WCF:

 So you say, why not try something else besides WCF to get around this issue? Certainly, you could. Let's say you put ADO.NET Data services within your WCF project. You'll still run into the same service proxy namespace issue. You could use RIA services, but then you're demoting your services code to running on an ASP.NET web app that is hosting the Silverlight app. Say goodbye to all remnants of SOA and supporting multiple UIs...

You can't have your cake and eat it too:

 So here's what I want...

1. To use the Entity Framework for data access and ONLY use its generated business objects, not having to write my own duplicate custom business objects.

2. To use WCF or ADO.NET Data Services so that I can support multiple UIs in the future and to be able to expose the Entity Framework entities from the services rather than having to convert between the EF entities and my custom business objects.

3. To use Silverlight for the UI without having my entities split up and duplicated in each generated service proxy namespace.

The key to resolving all of these issues is #3. If MSFT added support for referencing the WCF services project within the Silverlight app, then you could add your service references and they would generate the EF entities in their appropriate namespace. However, sadly, this isn't the case, and we're left with 3 technologies that are great on their own but don't end up playing nice together. I wish the teams for these different products worked closer together, because I can see the beauty in each of these technologies, yet together you end up having to make compromises...