What is IUpdatable? Why should I care?

Over the past few weeks I have posted a couple of samples of implementing IUpdateable for non-EF DALs so those can be used as data sources for ADO.NET Data Services.  A handful of people have asked me why this is interesting, so I now realize I should have given more background up front.

Out of the box, the only DAL that gets read/ write behavior for free in ADO.NET Data Services is Entity Framework.  This is because internally in the ADO.NET Data Services bits, there is an implementation of an interface we call IUpdatable:

 namespace System.Data.Services
{
    public interface IUpdatable
    {
        void AddReferenceToCollection(object targetResource, string propertyName, object resourceToBeAdded);
        void ClearChanges();
        object CreateResource(string containerName, string fullTypeName);
        void DeleteResource(object targetResource);
        object GetResource(IQueryable query, string fullTypeName);
        object GetValue(object targetResource, string propertyName);
        void RemoveReferenceFromCollection(object targetResource, string propertyName, object resourceToBeRemoved);
        object ResetResource(object resource);
        object ResolveResource(object resource);
        void SaveChanges();
        void SetReference(object targetResource, string propertyName, object propertyValue);
        void SetValue(object targetResource, string propertyName, object propertyValue);
    }
}

The reason behind this interface is that when we were designing V1 of ADO.NET Data Services we wanted to the user to have the ability to plug in LINQ data sources(.e. Linq to Sql, Entity Framework, nHibernate, etc).  For read only access, this is really straight forward and general uniform across LINQ DALs.  All the data source has to expose is a type with public IQueryable<T> entry points for each of their EntitySets.  For write operations, it was a completely different story since there is no common API for updating LINQ based DALs.  So we invented IUpdateable.

So any data source for Astoria that wants to support PUT, POST, and DELETE they must have an implementation of IUpdateable for their specific DAL. Hence why I started projects on Code Gallery to provide reference implementations of implementing IUpdatable for SubSonic and Linq to Sql.

There actually are a few more smaller interfaces to implement to become a full fledge ADO.NET Data Service provider.  At some point in the near future, I will try to get a post up describing that stuff plus some preview of the refactoring we are doing in V2 of ADO.NET Data Services to make a nicer provider plugin model.

Comments

• Anonymous
  December 15, 2008
  Thanks for the samples.I'd love these to be added to the T4 code generation samples for LINQ to SQL from Damien Guard.
• Anonymous
  December 16, 2008
  @AndySteele Price (http://blog.steeleprice.net/Default.aspx) mentioned he was working on this.  Although I like the template stuff, I would prefer to put this code in a seperate assembly that lives externally to ones LtoS DAL.  Unfortunately in V1 of Astoria, that is not easy.
• Anonymous
  January 18, 2009
  There's lots of interesting stuff going on in the ASP.NET team, and you can usually learn/glean/figure
• Anonymous
  September 23, 2009
  You noted "There actually are a few more smaller interfaces to implement to become a full fledge ADO.NET Data Service provider." -- what are the other interfaces?  Reason being, I have a custom data source (BLL/DAL) that I am trying to consume via Astoria v1.Thanks and great article!