EF-管理DbContext的最佳方法？

Question

I know there are alot of articles regarding this topic, but wherever I looked, it was either too complicated or unclear to me.

My team develops web application that uses Entity framework code first. We also use Autofac for dependency injection.

Currently, the data access looks as follows:

The API supplied to projects that do not contain EF:

public class DataService
{
   private IDbContextFactory<MyContext> _factory;
   private IDataServiceExecutor _dataServiceExecutor;

   public DataService(IDbContextFactory<MyContext> factory, IDataServiceExecutor executor)
   {
       _factory = factory;
       _dataServiceExecutor = executor;
   }

   public void AddItem(Product prod)
   {
       using (var context = _factory.Create())
       {
           if (_dataServiceExecutor.AddItem(context, prod))
               context.SaveChanges();
       }
   }
}

My DataServiceExecutor:

public class DataServiceExecutor
{
    private IRepository<Product> _products;

    public DataService(IRepository<Product> products...more repositories)
    {
       _products = products;
    }

    public bool AddItem(DbContext context, Prouduct prod)
    {
        try
        {
            _products.AddItem(context, prod);

            return true;
        }
        catch(Exception ex)
        {
             Log(..)
             return false;
        }
    }
}

All my repositories inherit from this abstract repository:

public abstract class EFRepository<T> : IRepository<T>
{
    public void AddItem<T>(DbContext context, T item)
    {
        context.Set<T>().Add(item);
    }

    .
    .
    .
}

The good thing is that a context is used per transaction this way.

The bad thing is that both my service methods and my repositories methods take context directly. The application is not so big, so for now the method injection of the context is fine, but it will probably become bigger and so the context injection at it's current state is problematic in my opinion. And it looks bad.

Maybe there are more pros and cons which I'm not aware of..

Is there any way I'm not familiar with to make data access better?

Answer 1

Classes like DataServiceExecutor (essentially a verb) always spell design flaws. It's a method ( Execute... ) disguised as a class. Responsibilities of such classes aren't clear because their functions inevitably belong to other classes.

The problem with an in itself great pattern like Inversion of Control is that an IoC container can be used to inject any dependency. So they allow you to create a tangle of dependencies and scattered responsibilities and still do a decent job managing life cycles. They may obscure life cycle problems you'd have otherwise.

So let's ignore IoC for a moment and see what your code would look like with simple object creation if you call DataServiceExecutor.AddItem .

var product = new Product();
var factory = new DbContextFactory<MyContext>(); // Dependencies unknown
var productRepository = new Repository<Product>(context);
var executor = new DataServiceExecutor(productRepository);
var dataService = new DataService(factory, executor);

Inside dataServiceAddItem method you essentially have:

using (var context = _factory.Create())
{
    executor.AddItem(context, product);
    context.SaveChanges();
}

If DataService would receive the productRepository instead of the executor this would boil down to:

productRepository.AddItem(context, product);
context.SaveChanges();

The executor can be taken out easily. Its only role seems to be error logging. But that could be done by DataService just as well.

But we're not done yet. As you indicated yourself, these methods taking a context as parameter are a bit awkward. But now DataServiceExecutor is out of the picture, it's far more natural to do:

var product = new Product();
var factory = new DbContextFactory<MyContext>();
using (var context = _factory.Create())
{
    var productRepository = new Repository<Product>(context);
    productRepository.AddItem(product);

    // And for example
    var orderRepository = new Repository<Order>(context);
    orderRepository.AddItem(order);

    // One SaveChanges call!
    context.SaveChanges();
}

And the DataService is gone too.

Now EFRepository stores its context as a member variable, and AddItem looks like this:

public void AddItem<T>(T item)
{
    _context.Set<T>().Add(item);
}

And now back to IoC.

In the light of IoC, the main problem of your code is this inside DataService.AddItem :

using (var context = _factory.Create())

You create a context that is not managed by the IoC container. It's lifespan is scoped to the AddItem method. Therefore you have to pass it around all over the place to make sure everything within the business transaction uses this one instance. By bringing the repository's dependency (to a context) back to constructor injection, it's much easier to let the IoC container manage the context's lifespan.

By the way, you say that DataService is part of "the API supplied to projects that do not contain EF". But it does refer to MyContext in its generic parameter. Maybe MyContext is an abstraction too, I don't know. Anyhow, you could supply instances of this abstraction by IoC as well.

Answer 2

My opion is that the solution is not correctly layered. I guess the DataService is the top layer that is accessed from the outside world?

In that case i would change to the following:

• The service gets the repository (or datalayer) injected through the constructor (and then properly disposed). The service methods then only need relevant parameters.
• What is the datalayer used for? Can it be removed? I normally have a datalayer below the services that holds all repositories. In that case the datalayer could be responsible for disposing all repositories when the service disposes the data layer.
• The repository could be kept as is but should have the context injected through the constructor.