Julie Lerman Blog - Knocking off Danny Simmons Entity Framework Beta 2 List: #3 & #4: EntityKey Serialization and new Entity interfaces

Saturday, September 01, 2007

Knocking off Danny Simmons Entity Framework Beta 2 List: #3 & #4: EntityKey Serialization and new Entity interfaces

The next things in the list of what's new in EF Beta 2 that I have been experimenting with are:

Entity key serialization In previous CTPs EntityKey objects were not serializable, now they are.
Increased persistence ignorance in entity data classes We are continuing down the path toward true POCO and persistence ignorance. To that end we have split the original IPOCO interface (IEntity) into two separate, more specific interfaces (IEntityWithKey and IEntityWithChangeTracker), we made IEntityWithKey optional (not implementing it has performance implications, but the scenario is supported), and many of the ObjectServices signatures have been modified to take instances of Object rather than IEntity which sets the stage for further progress here in future releases.

I've actually been playing with this for days but having a hard time with it. It turns out that while EntityKey objects, which are on their own are serializable, they are not being serialized as a property of an Entity. This is a bug (confirmed by Danny via email) and not the intended effect. It will definitely get fixed. My first foray was to just see what happened when returning an entity from a web service method.

<WebMethod()> _
Public Function GetSalesOrder(ByVal orderNumber As String) As AWModel.SalesOrderHeader
   Dim aw As New AWModel.AWEntities
   Dim order = (From so In aw.SalesOrderHeader Where so.SalesOrderNumber = orderNumber).First
   Return order

End Function

The payload for this does not have an EntityKey in it:

But I still wanted to see about serializing the key, since I was told that I should be able to do that with the independent key. So digging back into the code, I went looking for the EntityKey. I can see it in debug ,

but I couldn't get at it in code.

This is where I got a look at the IEntitywithKey interface. This interface ONLY exposes the EntityKey.

So now I can get at the EntityKey and can even pull the two together:

However, even if I modified the method so that it returns an EntityKey, there's a problem problem generating the WSDL and the proxy. Again, not the planned effect, but hopefully a bug.

So I will set this aside for now. (Darn)

There's still much to look at here including the BinarySerialization.

My biggest interest in serializing entities if for writing multi-tiered applications where entities need to cross machine boundaries and will likely have update conflicts to contend with. I'm personally most interested in Web Services & WCF as this is how I write my smart client applications.

Since we can attach externally created entities to an ObjectContext, this leads to using services to capture entities coming in from a client app and the doing DML operations (update, insert, delete). Attach requires an Entity that implements IEntitywithKey, but AttachTo does not. Nevertheless, when it comes to Updates, the biggest conundrum will be dealing with concurrency and persisting original values somewhere. This is where the EntityKey will be a benefit. We won't have to go looking for the matching entity, the object service should do that for us.

LINQ to SQL has an override for Attach that allows passing in the original entity and the existing entity, so that it's own SaveChanges method will be able to determine the modified state of each property. Entity Framework does not have this yet, so finding the most efficient way to handle this is yet to come.

But hey, it's a holiday weekend and I'll just have to leave this for another time.= because the sun just came out.

Data Access

Saturday, September 01, 2007 10:11:21 AM (Eastern Standard Time, UTC-05:00)