Working with ADO.NET Entities and Soap-Based Web Services
I am creating a traditional ASP.NET Web Service - style built using asmx. It's a pretty basic service. I started using the new Entity Framework Ado.NET for my persistence layer and I am having some problems:
1) I don't like that WSDL is automatically generated - complex types were defined like this:
<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 that includes a new type definition, so the WSDL now looks like, which I think is more cross-platform:
<xsd:complexType name="TestObject">
<xsd:sequence>
<xsd:element minOccurs="0" name="created" type="xsd:dateTime"/> ...
Now I have an ASPX generating a nice WSDL file. But now I'm not sure where I should get it. For TestObject, I have two types, basically the same type: 1) which is used to persist the entity of the object using ADO.NET Entity Framework 2) and one which is used to define data over the wire.
I would like to figure out how to combine them into one. I'm a bit nervous about modifying the .cs file that was automatically generated by the Ado.NEt Entity framework as it seems like it might be overwritten.
Does anyone with a lot of experience with the Ado.Net entity think this is worth using? While I love the idea of how quickly I was able to persistently persist my data layer, I need to be very precise about how the object is passed around the wire, so I will need to change its associated property attributes. Also, in my service implementation, I really don't want to go from EntityFramework.TestObject to WSDLDefenition.TestObject.
Thanks for any input.
source to share
You are facing the same wall that 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 perform well in the scenario you described, as you find yourself in a world of misery trying to manipulate (and probably cache) object contexts.
I would recommend carefully reading 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 shortcomings.
Long story short, I'm not sure Entity Framework is the solution you want right now, as there is no "clean" solution at this point for handling EF objects across the wire (or external service boundaries).
Others may ask for a distinction ...
PS You are right to be wary of editing the generated code - any updates to the data model will overwrite any changes (although you can extend them as they are in a partial class). Not useful if you want to add attributes to properties.
(a) http://blogs.msdn.com/efdesign/archive/2008/11/20/n-tier-improvements-for-entity-framework.aspx
source to share
Thank. This is what I suspected, but did not want to do a full day of research. What I am currently going to do is to keep separate objects so I can keep pure WSDL and then on the data access layer I will convert between objects to wire and ADO.NET framework object.
Probably not the soundest approach, but it will lead me to a demo.
Thanks for the link to the article, I think the key concept I missed was Persistent Notorance. I've been working on Java Web Services where you can define POJOs (Plain Old Java Objects) and easily wrap them around the wire and also persist to the datasource ...
... and now I can see why you are suggesting WCF because of persistence support.
source to share