Implementing IUpdatable (Part 3)

UPDATE: I know the title is wrong and it should be IUpdateable but I didn’t want to break any links for any RSS feeds that already had it.

If you haven’t read Part 1 or Part 2 first, you should start there.

In this final part of the IUpdateable implementation, we will discuss the rest of the methods which includes ClearChanges, ResolveResource, ReplaceResource, SetReference, AddReferenceToCollection, RemoveReferenceFromCollection and SaveChanges.

ClearChanges is a simple method that simple undo’s any changes that have accumulated.  In my implementation, I simply clear the UpdateCache that we discussed in Part 2 as well as clear the NHibernate Session to undo any changed that were previously saved (but not persisted to the database).

ResolveResource is a funny little method. In the implementation documentation for the IUpdateable interface, they specify that in most cases you can return a token or anything you want that uniquely identifies an item instead of an actual object reference. For example, when you implement CreateResource the return value can be the actual resource or can be some token that you know how to resolve to the resource.  This method is the one that will turn that token into an object reference if you’ve used that functionality. In our case we’re actually returning object references so this becomes a non-issue and we just return the object that is passed in.

Next up is ReplaceResource. Not surprising, this method is used to complete replace a resource with another copy (who may have the correct values already set). The first parameter is a query who must return a single object.  For my implementation, I first retrieve the single instance from the query and then walk through the properties to set the new values. Simple really.

The next couple of methods have to do with relationships between objects. The SetReference method takes three parameters: the target resource, the property name and the property value.  The property value is an object who needs to be assigned to a property of the target.  The property name to be assigned in the 2nd parameter.  The implementation is pretty simple: I used the existing SetValue implementation to set the correct property with the correct value.

The AddReferenceToCollection and RemoveReferenceFromCollection are related methods.  One adds an object to a collection and one removes it from the collection. Both of these methods take the same signature that SetReference uses (target, property name, property value). The difference here is instead of setting the reference, you need to add or remove it from a property (which is the collection). For my AddReferenceToCollection implementation, I use reflection to find an “Add” method and invoke it with the new reference. For the RemoveReferenceFromCollection, I do the same but I am looking for a “Remove” method to invoke. Using reflection in this way does not require that the collections follow any specific pattern but do require an Add and Remove method. I chose this implementation because I was copying ADO.NET Data Services’ implementation that they use for the Entity Framework. I could have expected IList since that is the standard way that NHibernate usually implements collections, but I decided to use this implementation first and if I had to refactor it I would.

The last method to implement is SaveChanges. This method is pretty straightforward as all pending changes that the IUpdateable interface has applied should be applied during this call.  IUpdateable expects that SaveChanges will be atomic (e.g. pass/fail, no partial updates).  To enforce that requirement, I used the NHibernate Session object’s BeginTransaction method to start a transaction so that I could rollback any changes that failed. Because I had kept a cache of updates so I could clear them if necessary, I walked through them once the transaction had began and applied them to the Session object.  Finally I flushed the session to force the persistence to happen and ended the transaction. I did this all in a try…catch block so I could rollback the changes if any exceptions were thrown. SaveChanges does not have a return value so if it fails you are expected to return a DataServiceException. So in my catch block, after rolling back the transaction, I throw a DataServiceException and pass along the caught exception as the inner exception.

Overall the implementation was pretty simple. I hope that these articles will help anyone who is trying to implement this for their own data that they want to use in ADO.NET Data Services.