UnitOfWork and Entity Framework Contexts

Question

So the problem I am trying to solve is this; We are using Entity Framework to access our Oracle database that has 1200-1500 tables. Now mind you we are not accessing them all, but possibly could have 800+ to access. We are using the UnitOfWork --> Repository --> Service pattern and that works great, but we are trying to figure out if we should have one big DbContext, or multiple little contexts that are specific to the task at hand.

Our UnitOfWork is setup using an EFUnitOfWorkBase like so:

public abstract class EFUnitOfWorkBase : IUnitOfWork
{
    private bool isDisposed = false;

    public DbContextBase Context { get; set; }

    protected EFUnitOfWorkBase(DbContextBase context)
    {
        Context = context;
    }

    public int Commit()
    {
        return Context.SaveChanges();
    }

    public void Dispose()
    {
        if (!isDisposed)
            Dispose(true);
        GC.SuppressFinalize(this);
    }

    private void Dispose(bool disposing)
    {
        isDisposed = true;
        if (disposing)
        {
            if (this.Context != null)
                this.Context.Dispose();
        }
    }

    public IRepository<TEntity> GetRepository<TEntity>() where TEntity : Common.EntityBase<TEntity>
    {
        return new Repository<TEntity>(this);
    }
}

Any unit of work we create extends that base one and provides the context like so:

public class EmployeeDirectoryUnitOfWork : EFUnitOfWorkBase
{
    public EmployeeDirectoryUnitOfWork(string connectionString)
        : base(new EmployeeDirectoryContext(connectionString))
    {
    }
}

The DbContext is passed a connection string through the unit of work.

The Repository looks like this:

public abstract class RepositoryBase<TEntity> : IRepository<TEntity> where TEntity : class
{
    protected DbContextBase Context;
    protected DbSet<TEntity> EntitySet;

    public RepositoryBase(EFUnitOfWorkBase unitOfWork)
    {
        Enforce.ArgumentNotNull(unitOfWork, "unitOfWork");

        Context = unitOfWork.Context;
        EntitySet = Context.Set<TEntity>();
    }

    public TEntity Add(TEntity entity)
    {
        Enforce.ArgumentNotNull(entity, "entity");

        return EntitySet.Add(entity);
    }

    public TEntity Attach(TEntity entity)
    {
        Enforce.ArgumentNotNull(entity, "entity");

        return EntitySet.Attach(entity);
    }

    public TEntity Delete(TEntity entity)
    {
        Enforce.ArgumentNotNull(entity, "entity");

        return EntitySet.Remove(entity);
    }

    public System.Linq.IQueryable<TEntity> Query()
    {
        return EntitySet.AsQueryable();
    }

    public TEntity Save(TEntity entity)
    {
        Enforce.ArgumentNotNull(entity, "entity");

        Attach(entity);
        Context.MarkModified(entity);

        return entity;
    }
}

Any suggestions on how to best handle this situation?

Corey Adler Corey Adler · Accepted Answer · 2013-02-08T20:31:14

In such a case when you have a large application like this, I think you should probably go for a more Domain Driven Design approach and split the contexts into some separate, bounded contexts. This way when later developers are adding features to the program they will be confined to only being able to access certain tables depending on which context they will be using there.

For better information, Julie Lerman recently came out with a course on Pluralsight about Entity Framework in the Enterprise that's really good. She posted a small clip of it (actually about bounded contexts) on this site. It's a very good course, and I highly recommend it, especially for what you appear to be doing.

UnitOfWork and Entity Framework Contexts

1 Answers