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.
<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 orderEnd Function
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.
Sign up for my newsletter so you don't miss my conference & Pluralsight course announcements!