Source control shootout

I like to think that I keep up with changes in the continuous integration space but somehow I missed an important shift in source control thats been taking place over the last year and a half. While I was busy promoting subversion and TFS as SourceSafe replacements, the community has abandoned centralised source control alltogether in favour of distibuted variants. Mercurial, like Git and Bazaar is a distributed version control system and needs no central server control. If a server wants revisions of a project it simply clones or pulls revisions from clients it is interested in.

Large open source projects have used the model for many years with notable successes like the linux kernel but a recent shift by Mozilla to Mercurial as well as Google Code's adoption of Mercurial was what caught my attention. Having now caught up on my research of the subject, I feel like I've arrived late to the party. I'm not going to say too much about what I've learned but the long and short of it is this:

If you're still using centralised source control, stop it. At the time of writing, you have two options: Git or Mercurial. I leave it as an exercise for the reader to understand why if you don't already know...

Using expression trees for more elegant code

Caching WCF responses without making a mess in the code base is often problematic due to connection pooling limitations and the requirement to close connections after use.

Many implementations end up something like: attempt to retrieve entity from cache > if absent, instantiate client proxy > retrieve entity from service > close connection > add entity to cache.

Problems arise because it is possible that entities for a single solution may need to be supplied by numerous services and the service method signatures may differ for various entities or collections of entities. This makes it difficult to create a generic wrapper capable of populating any number of varying entity types let alone the associated CRUD calls for entity persistence, etc. Entity identifiers may differ in type between services or even within a service. When a client side caching mechanism is required, the code becomes cluttered with the numerous caching calls and connection instantiations and tear-downs.

Any one who has worked on large WCF driven apps knows that this kind of clutter is butt-ugly and a pain to maintain or add features to.

Expression Trees to the rescue:

public static class Services
{
  /// <summary>Gets the item.</summary>
  /// <typeparam name="TProxy">The type of the proxy.</typeparam>
  /// <typeparam name="TEntity">The type of the entity.</typeparam>
  /// <typeparam name="TIdentity">The type of the identity.</typeparam>
  /// <param name="expression">The expression.</param>
  /// <param name="proxy">The proxy.</param>
  /// <param name="id">The id.</param>
  /// <returns></returns>
  /// <remarks>Method first checks the cache for an entity with a matching id, if found, it is returned.
  /// If the cache does not contain the entity, the wcf service method in the supplied expression tree
  /// is used to obtain the entity which is then added to the cache.</remarks>
  /// <example>Product p = GetItem((client, identifier) => client.GetProduct(identifier), new CatalogServiceClient(), 123);</example>
  private static TEntity GetItem<TProxy, TEntity, TIdentity>(Expression<Func<TProxy, TIdentity, TEntity>> expression, TProxy proxy, TIdentity id)
    where TEntity : class
    where TProxy : ICommunicationObject
  {
    TEntity item = Cache.GetItem<TEntity, TIdentity>(id);
    if (item == null)
    {
      try
      {
        var originalDelegate = expression.Compile();
        item = originalDelegate.Invoke(proxy, id);
      }
      finally { proxy.Close(); }
      Cache.AddItem<TEntity, TIdentity>(item);
    }
    return item;
  }
}