Working with ADO.NET Entity Objects and Soap-based Web Services

Question

Hello All, I'm building a traditional ASP.NET Web Service -- the style built using asmx. It's a pretty simple service. I started using the new Ado.NET Entity Framework for my persistence layer, and I'm running into some problems:

1) I don't like the WSDL that gets automatically generated -- the complex types were getting defined as so:

   <s:complexType name="TestObject">
      <s:complexContent mixed="false">
         <s:extension base="tns:EntityObject"> ...

So, I built my own WSDL and used the wsdl.exe tool to create a service definition, which includes a new type definition, so now the WSDL looks like, which I feel is a more cross-platform design:

<xsd:complexType name="TestObject">
  <xsd:sequence>
    <xsd:element minOccurs="0" name="created" type="xsd:dateTime"/> ...

I now have the ASPX generating a nice WSDL file. But now I'm not sure where I should take this. I have two types of basically the same type for TestObject: 1) that's used for entity persistence with the ADO.NET Entity Framework 2) and one that's used for defining data across the wire.

I'd like to figure out how to combine them into one. I'm a little nervous about modifying the .cs file that was automatically generated by the Ado.NEt Entity framework, as it seems like it might get over-written.

Anyone with much experience with the Ado.Net entity experience think it's worth using? While I like the idea of how quickly I was able to build persistence to my data layer, I need to define in a very custom manner how the entity object is transfered across the wire, so I'd need to modify the attributes associated with it's properties. Also, in my service implementation, I don't really want to by converting from EntityFramework.TestObject to WSDLDefenition.TestObject.

Thanks for any input.

Answer 1

You're facing the kind of wall many of us have faced when trying to use the Entity Framework in an SOA style architecture.

Version 1.0 of the Entity Framework doesn't work very well in the scenario you've described, as you end up in a world of hurt trying to manage object contexts (and likely having to cache them).

I'd recommend a thorough read-through of the following (1) article posted by the EF team about the future of the Entity Framework. It also has the effect of capturing and discussing some of the current shortfalls.

In short, I'm not sure that the Entity Framework is quite the solution you want right now as there is no "clean" solution in handling EF entities across the wire (or outside service boundaries) at this stage.

Others may beg to differ...

P.S You're right about being wary of hand editing the generated code - any updates to the data model will overwrite any modifications (although you can extend it as they are within a partial class). Not helpful if you want to add attributes to properties though.

(a) http://blogs.msdn.com/efdesign/archive/2008/11/20/n-tier-improvements-for-entity-framework.aspx

Answer 2

Thanks. This is what I was suspecting, but didn't want to spend a whole day researching. What I'm going to do for the time being is to keep my objects separate, this way I can keep the clean WSDL, and then in a data access layer, I'll convert between objects on the wire and the ADO.NET entity framework.

Probably not the most sound approach, but this will get me by for the demo.

Thanks for the link to the article, I think the key concept I was missing was Persistent Ignorance. I've worked on Java web services where you can define POJO (Plain old Java objects) and transfer them over the wire easily, as well as persist to the data source...

...and I see now why you're suggesting WCF, because of hte support for Persistent Ignorance.