A Bad Idea, EF Entities over WCF

Do you want to see something very ugly ?. Try to send a complete EF entity directly as a data contract over the wire with WCF,

<Order xmlns:i="http://www.w3.org/2001/XMLSchema-instance" z:Id="i1" xmlns:z="http://schemas.microsoft.com/2003/10/Serialization/" xmlns="http://schemas.datacontract.org/2004/07/ClassLibrary2">
  <EntityKey xmlns:d2p1="http://schemas.datacontract.org/2004/07/System.Data" i:nil="true" xmlns="http://schemas.datacontract.org/2004/07/System.Data.Objects.DataClasses" />
  <Description>My new order</Description>
  <OrderId>1</OrderId>
  <OrderItem>
    <OrderItem z:Id="i2">
      <EntityKey xmlns:d4p1="http://schemas.datacontract.org/2004/07/System.Data" i:nil="true" xmlns="http://schemas.datacontract.org/2004/07/System.Data.Objects.DataClasses" />
      <Currency>USD</Currency>
      <Description>item 1</Description>
      <ItemId>1</ItemId>
      <Order z:Ref="i1" />
      <OrderReference xmlns:d4p1="http://schemas.datacontract.org/2004/07/System.Data.Objects.DataClasses">
        <d4p1:EntityKey xmlns:d5p1="http://schemas.datacontract.org/2004/07/System.Data" i:nil="true" />
      </OrderReference>
      <UnitPrice>10</UnitPrice>
    </OrderItem>
    <OrderItem z:Id="i3">
      <EntityKey xmlns:d4p1="http://schemas.datacontract.org/2004/07/System.Data" i:nil="true" xmlns="http://schemas.datacontract.org/2004/07/System.Data.Objects.DataClasses" />
      <Currency>USD</Currency>
      <Description>item 2</Description>
      <ItemId>2</ItemId>
      <Order z:Ref="i1" />
      <OrderReference xmlns:d4p1="http://schemas.datacontract.org/2004/07/System.Data.Objects.DataClasses">
        <d4p1:EntityKey xmlns:d5p1="http://schemas.datacontract.org/2004/07/System.Data" i:nil="true" />
      </OrderReference>
      <UnitPrice>145</UnitPrice>
    </OrderItem>
  </OrderItem>
</Order>

That is the result of serializing a complete object graph. I do not know what the folks in Microsoft were thinking when they decided to enable a feature like this. They made a good work teaching us about how evil Datasets were for interoperability with other platforms, and now they came up with a solution like this, no way.

I always like the idea of making boundaries explicit, that is the approach the WCF team took with the first version of the framework (Every data contract should be decorated with DataContract and DataMember attributes).  If you break that rule, you will end up with things like this.

I know this a solution for people that want to develop things quickly with no need to create DTOs, and do all the mapping stuff, but there are good tools and frameworks like AutoMapper to help with that. Or you can use ADO.NET Data Services today, which is also prepared to handle this kind of scenarios, all the transformations between layers are made by the framework itself, and still you get a very nice RESTful api. We still need some more features in ADO.NET DS to have a more complete framework, there is not good support today for injecting business logic, it can be done but it is complicated, it looks like the next version will address that aspect better.

5 Comments

  • Exactly why is this such a bad idea? Are you objecting to the fact that ids are included in the contract? It isn't clear.

  • Hi Pablo,

    Can you say what exactly bothers you about the XML above? And how you would fix it in clean way? Just wanted to get your opinion on that. I do agree that the XML is ugly, but it works... It is hard to complain when things do work as expected. I personally think that things like serialization, Validation etc are responsibilities of the applications that use these classes. I actually don't like marking up classes with 'DataContract' and 'DataMember' attributes because I think that the consuming application should dictate what the output should look like and these decorators only pollute the POCO. But they do save you a LOT of time though... So, you probably consider the XML ugly because you application is a RESTful app that wants its output to look a certain way...

    Would be interested in your thoughts...

  • @Vish. First of all, the xml exposes internal implementation details that a consumer application should not be worried about. The consumer application just want to consume the services, they do not want to deal with things like EntityKeys or References, something simpler should be exposed.
    Secondly, I do not think other platforms like java, ruby or any other will be able to generate proxy classes that represent the same exact model, as occurred in the past with Datasets. It is a interoperability issue.

    @Peter, it is a bad idea for interoperability as datasets are.

  • so if interoperability is not a concern, would this be a good idea? This might be the case for enterprise which is a completely .Net shop.

  • You might want to take a look at POCO support and particularly self-tracking entities with EF4 and the recently released feature CTP. These provide a much cleaner XML while still being easy to work with.

    - Danny

Comments have been disabled for this content.