Managing the Entity Framework ObjectContext instance lifetime in WCF and sharing it among repositories

As I pointed out in a previous post about using the Repository pattern in EF and WCF, it’s a bad practice when service operations manage the ObjectContext instance lifetime and have dependencies on it.

In this post I’m going to show you how to share the same ObjectContext among repositories as long as the service is activated (either PerCall or PerSession) and have the service totally agnostic of it.

First lets introduce two concepts:

public interface IDbContext : IDisposable
{
    object Context { get; }
}

public interface IDbContextManager
{
    IDbContext GetDbContext();
}

The IDbContext interface can be used as a wrapper for the ObjectContext or even NHibernate’s ISession. The IDbContextManager will be used by the repositories to get an IDbContext instance.

To simplify things we can extend our existing ObjectContext class using a partial class that implements the IDbContext interface. In this case, since I’m using the same example as the previous post it should look like this:

public partial class MFEntitiesContainer : IDbContext
{
    public object Context
    {
        get { return this; }
    }
}

Lets see how the refactored EntityRepository class looks like:

public class EntityRepository<TEntity> : IRepository<TEntity>
    where TEntity : EntityObject, new()
{
    public EntityRepository(IDbContextManager manager)
    {
        this.SetContext(manager.GetDbContext());
    }

    private void SetContext(IDbContext ctx)
    {
        this.ObjectContext = ctx.Context as ObjectContext;
        this.FetchEntitySetName();
    }

    //.. same implementation as the previous post
}

So now we can use our repositories without having to worry how to give them an ObjectContext anymore. We simply have to supply an implementation of IDbContextManager. In this case, I’m going to implement a DbContextManager that will return the same IDbContext instance while the wcf service is activated in order to reuse it among repositories.

The idea here is to leverage the extensible object pattern implemented in wcf by providing our own extension object to the service’s InstanceContext. If you don’t know what this is I recommend reading this blog post for some background.

The first thing to do is to create the extension class. It will be used to “attach” an IDbContext instance to a wcf service’s InstanceContext.

public sealed class DbContextInstanceExtension : IExtension<InstanceContext>
{
    public DbContextInstanceExtension() { }
    public void Attach(InstanceContext owner){ }
    public void Detach(InstanceContext owner){ }

    public IDbContext Context { get; set; }
}

To add a DbContextInstanceExtension to a WCF service we need to provide an IInstanceContextInitializer object that will participate in the initialization of the service.

public sealed class DbContextInitializer : IInstanceContextInitializer
{
    public void Initialize(InstanceContext instanceContext, Message message)
    {
        instanceContext.Extensions.Add(new DbContextInstanceExtension());
    }
}

To apply this IInstanceContextInitializer to the service we need a behavior. In this case, we want to use an IServiceBehavior. I’m calling it DbContextBehavior and I will also expose it as an attribute to simplify its usage.

public sealed class DbContextBehavior : Attribute, IServiceBehavior
{
    public void ApplyDispatchBehavior(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase)
    {
        foreach (var channelDispatcherBase in serviceHostBase.ChannelDispatchers)
        {
            var channelDispatcher = channelDispatcherBase as ChannelDispatcher;
            if (channelDispatcher != null)
            {
                foreach (var endpointDispatcher in channelDispatcher.Endpoints)
                {
                    endpointDispatcher.DispatchRuntime
                                      .InstanceContextInitializers.Add(new DbContextInitializer());
                }
            }
        }
    }
    public void AddBindingParameters(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase, System.Collections.ObjectModel.Collection<ServiceEndpoint> endpoints, System.ServiceModel.Channels.BindingParameterCollection bindingParameters)
    {

    }
    public void Validate(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase)
    {

    }
}

Having this I can now implement a proper IDbContextManager object that will create and store an IDbContext instance in the DbContextInstanceExtension.

public sealed class WcfDbContextManager<TContext> : IDbContextManager
    where TContext : IDbContext, new()
{
    public IDbContext GetDbContext()
    {
        return this.GetOrCreateDbContext();
    }

    private IDbContext GetOrCreateDbContext()
    {
        var ctxInstanceExtension = OperationContext.Current
                                                   .InstanceContext
                                                   .Extensions
                                                   .Find<DbContextInstanceExtension>();
        if (ctxInstanceExtension == null)
        {
            //the service has no DbContextInstanceExtensions, so a new TContext is returned
            return new TContext();
        }

        if (ctxInstanceExtension.Context == null)
            ctxInstanceExtension.Context = new TContext();

        return ctxInstanceExtension.Context;
    }
}

This implementation works fine with EntityFramework because the generic TContext type represents an ObjectContext class and you can instantiate it with the new operator. For NHibernate we would have to tweak this class or even create a different one..I might write another post on how we can support both ORM’s here and still make it transparent to our service.

Now we can refactor the OrderService to leverage the DbContextBehavior we just created. Note that we don’t have any reference to the ObjectContext anymore. We simply care about using the repositories and if we had a CustomerRepository for example we could share the same ObjectContext among the repositories.

[DbContextBehavior]
public class OrderService : IOrderService
{
    private readonly IOrderRepository orderRepository;

    public OrderService()
    {
        this.orderRepository = IoC.Current.Container.Resolve<IOrderRepository>();
    }

    //** will be addressed in a different post **
    //public OrderService(IOrderRepository repository)
    //{
    //    this.orderRepository = repository;
    //}

    public IEnumerable<Order> ListOrders()
    {
        return orderRepository.Query();
    }
    public IEnumerable<Order> ListOrdersByCustomer(int customerId)
    {
        return orderRepository.QueryByCustomer(customerId);
    }
}

The IoC class is a singleton class I use that exposes an Inversion of Control container like Unity for example. Note that the commented constructor would be a recommended approach if we could have our service be resolved by the IoC container instead of the default way.

The following code is the what we need to wire up all the types that the IoC container needs to resolve:

var container = IoC.Current.Container;
container.RegisterType(typeof(IRepository<>), typeof(EntityRepository<>)); //generic repository
container.RegisterType<IOrderRepository, OrderRepository>(); //specific repository
container.RegisterType<IDbContextManager, WcfDbContextManager<MFEntitiesContainer>>();

I hope this post helps someone out there trying to figure out how easily we can refactor a wcf service and take benefits from a decoupled architecture.

In my next post I will show how we can use the IoC container to resolve our services.