实体框架 6 代码优先 - 存储库实现是一个好的实现吗？

我即将使用存储库和工作单元实现 Entity Framework 6 设计。

周围有很多文章，我不确定最好的建议是什么：例如，我真的很喜欢这里实现的模式：出于文章中建议的原因here http://codefizzle.wordpress.com/2012/07/26/correct-use-of-repository-and-unit-of-work-patterns-in-asp-net-mvc/

然而，Tom Dykstra (Senior Programming Writer on Microsoft's Web Platform & Tools Content Team)建议应该在另一篇文章中完成：here http://www.asp.net/mvc/tutorials/getting-started-with-ef-5-using-mvc-4/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application

我订阅Pluralsight，而且几乎每次在课程中使用它时，它的实现方式都略有不同，因此选择设计很困难。

有些人似乎建议工作单元已经由DbContext就像在这个post http://social.msdn.microsoft.com/Forums/en-US/435bf3a3-a358-41cf-a1b0-9f4387dcf5f2/is-unit-of-work-functionality-already-available-inside-the-dbcontext-in-ef-5?forum=adodotnetentityframework，所以我们根本不需要实现它。

我意识到以前曾有人问过此类问题，这可能是主观的，但我的问题是直接的：

我喜欢第一篇（代码失败）文章中的方法，并想知道它是否比其他方法更易于维护、更容易测试，并且可以安全地继续使用？

任何其他意见都非常受欢迎。

@Chris Hardie 是正确的，EF 开箱即用地实现了 UoW。然而，许多人忽视了这样一个事实：EF 也实现了开箱即用的通用存储库模式：

var repos1 = _dbContext.Set<Widget1>();
var repos2 = _dbContext.Set<Widget2>();
var reposN = _dbContext.Set<WidgetN>();

...这是一个非常好的通用存储库实现，内置于工具本身中。

当 DbContext 为您提供所需的一切时，为什么要费力创建大量其他接口和属性呢？如果您想要抽象应用程序级接口后面的 DbContext，并且想要应用命令查询隔离，您可以执行如下简单操作：

public interface IReadEntities
{
    IQueryable<TEntity> Query<TEntity>();
}

public interface IWriteEntities : IReadEntities, IUnitOfWork
{
    IQueryable<TEntity> Load<TEntity>();
    void Create<TEntity>(TEntity entity);
    void Update<TEntity>(TEntity entity);
    void Delete<TEntity>(TEntity entity);
}

public interface IUnitOfWork
{
    int SaveChanges();
}

您可以使用这 3 个接口进行所有实体访问，而不必担心将 3 个或更多不同的存储库注入到与 3 个或更多实体集一起使用的业务代码中。当然，您仍然可以使用 IoC 来确保每个 Web 请求只有 1 个 DbContext 实例，但所有 3 个接口都由同一个类实现，这使得它更容易。

public class MyDbContext : DbContext, IWriteEntities
{
    public IQueryable<TEntity> Query<TEntity>()
    {
        return Set<TEntity>().AsNoTracking(); // detach results from context
    }

    public IQueryable<TEntity> Load<TEntity>()
    {
        return Set<TEntity>();
    }

    public void Create<TEntity>(TEntity entity)
    {
        if (Entry(entity).State == EntityState.Detached)
            Set<TEntity>().Add(entity);
    }

    ...etc
}

现在，您只需将单个接口注入到您的依赖项中，无论它需要使用多少个不同的实体：

// NOTE: In reality I would never inject IWriteEntities into an MVC Controller.
// Instead I would inject my CQRS business layer, which consumes IWriteEntities.
// See @MikeSW's answer for more info as to why you shouldn't consume a
// generic repository like this directly by your web application layer.
// See http://www.cuttingedge.it/blogs/steven/pivot/entry.php?id=91 and
// http://www.cuttingedge.it/blogs/steven/pivot/entry.php?id=92 for more info
// on what a CQRS business layer that consumes IWriteEntities / IReadEntities
// (and is consumed by an MVC Controller) might look like.
public class RecipeController : Controller
{
    private readonly IWriteEntities _entities;

    //Using Dependency Injection 
    public RecipeController(IWriteEntities entities)
    {
        _entities = entities;
    }

    [HttpPost]
    public ActionResult Create(CreateEditRecipeViewModel model)
    {
        Mapper.CreateMap<CreateEditRecipeViewModel, Recipe>()
            .ForMember(r => r.IngredientAmounts, opt => opt.Ignore());

        Recipe recipe = Mapper.Map<CreateEditRecipeViewModel, Recipe>(model);
        _entities.Create(recipe);
        foreach(Tag t in model.Tags) {
            _entities.Create(tag);
        }
        _entities.SaveChanges();
        return RedirectToAction("CreateRecipeSuccess");
    }
}

关于这个设计我最喜欢的事情之一是最大限度地减少实体存储对consumer