How can I share Linq to Entities datacontracts between WCF and Silverlight

Question

0 vote down star 1

I want to be able to share my datacontracts (classes generated in the linq to entities designer are decorated with the [DataContract] attribute.

I'm trying to use the architecture as detailed here: http://www.netfxharmonics.com/2008/11/Understanding-WCF-Services-in-Silverlight-2 and trying to reference my interfaces in my silverlight project using the 'Add as link' method as detailed here: http://www.netfxharmonics.com/2008/12/Reusing-NET-Assemblies-in-Silverlight

The problem I'm having is referencing my service interface in my silverlight project.

My solution has the following projects:

ORM - contains a Linq to Entities edmx model (namespace: company.client.Service) - the classes in this are decorated with DataContract attribute etc.

ServiceInterface - contains the interfaces (namespace company.client.Service) and a reference to the ORM for the classes (Customer etc) being returned

Service - contains the implementation of the service interfaces (namespace company.client.Service) and references ServiceInterface and the ORM for the classes.

ServiceHost - contains just .svc files as recommended in http://www.netfxharmonics.com/2008/11/Understanding-WCF-Services-in-Silverlight-2

WebSLHost - the host for the silverlight app

Gui - the silverlight GUI.

I want all the of the projects to be standard .net assemblies except for the silverlight gui of course.

When I try to add a link to my service interface files (as shown in http://www.netfxharmonics.com/2008/12/Reusing-NET-Assemblies-in-Silverlight) it give a compile error stating that it can't find the ORM and can't identify my entity types.

I want to be able to share the datacontract generated by the linq to entities generator with my service and the silverlight client, so if anyone has any ideas I'd appreciate them.

Answer 1

I still think your best bet is to NOT try to pass your linq-to-entities classes from your WCF component to your client. Instead, create simple DataContract classes that just hold the data (properties only). Fill that up on the WCF side, send it across and then in your client use the data to reconstitute a proper object you can use with linq.

Make sense?

Answer 2

What you are trying will only work with "full" .NET to "full" .NET (or at least, matched); and even then, it breaks the rules of SOA...

The whole idea of a data-contract is that you share the shape of the data, but not the implementation. This means that it doesn't matter that Silverlight doesn't know about EDMX, or some of the more unusual flavors of DataContract attributes (like callbacks) - the data is still intact.

By consuming the mex-generated version of the classes, you will still have the same essential data behaviour - that is the intended use-case of WCF with Silverlight. So just use a service reference. Alternatively, you'll need to have a DTO class that sits between the EDMX and WCF; as long as the DTO only uses WCF attributes (but no EDMX) you should be OK, but obviously this has a huge maintenance cost. I personally doubt that it is worth it in most simple scenarios.

Answer 3

Unfortunately, LINQ to Entities classes expose some implementation features in their data contracts. They really would have done better to not make the classes be data contracts at all.

As has been said, simply create your own data contract (DTO) classes that match the shape of the data to be returned. Return individual instances of those classes, or List of them.

I recommend against using DataSet, DataTable or anything else platform-specific. The reason for this used to be that it did not interoperate with other platforms such as Java. However, I've seen situations where it doesn't interoperate properly within .NET - between different .NET versions, and I suspect between full .NET and Silverlight. Use a DTO, as above.