C# 在使用VS2013、Entity Framework 6和WebAPI 2时，是否使用了通用存储库和UoW Framework overkill？

我正在重新检查我对该计划的执行情况

我使用的是EF6和VS2013。因此，VS包含WebAPI控制器模板，这些模板使用以下实体框架代码自动生成带有操作的WebAPI 2 OData控制器：

// GET odata/UserProjects(5)/WebsiteRequiredKeywords
        [Queryable]
        public IQueryable<WebsiteRequiredKeyword> GetWebsiteRequiredKeywords([FromODataUri] int key)
        {
            return _db.Websites.Where(m => m.WebsiteId == key).SelectMany(m => m.WebsiteRequiredKeywords);
        }

        protected override void Dispose(bool disposing)
        {
            if (disposing)
            {
                _db.Dispose();
            }
            base.Dispose(disposing);
        }

        private bool WebsiteExists(int key)
        { . . .

public class ProjectEditorController : ODataController
{
    //private MyDatabaseNameContext db = new MyDatabaseNameContext();  // auto-generated code

    private DbContext _db;

    public ProjectEditorController(DbContext dbContext)
    {
        _db = dbContext;
    }
    . . .

这段代码的问题是，现在没有具体的上下文，执行以下操作：

return SingleResult.Create(_db.Websites.Where(website => website.WebsiteId == key));

…将不起作用，因为

db

和实体（即

网站

）之间没有具体的联系

在使用时，您仍然需要定义一个存储库。在这种情况下，如果我想注入dbContext，我需要使用泛型repo吗

---

简而言之，这是否准确：如果您想要有效地使用依赖项注入，那么您需要一个通用存储库。否则，您需要为所有EF实体定义一个存储库接口，除非您使用本文末尾建议的IDependency解析器。

Ayende将其总结得非常好。不要添加您不需要的抽象。

这些新模板是否共享相同的数据上下文？因为，共享数据上下文是UOW模式的关键部分，如果他们不这样做，那么这就不是一个等价的比较。或者是吗？有没有值得做这些重构的理由？如果没有，那就放松。过度设计是很容易的，如果有必要，您可以在以后重构。如果值得的话，那么安装并节省一些时间，如果你想继续这样做的话。@bigdady-我用一个新的构造函数更新了默认代码，在这里你可以定义上下文。请看更新的问题。在过去的几年中，当我们没有像EF这样的抽象时，存储库非常有意义。有了EF，我发现实现一个存储库可能需要很多额外的工作，但收获很少（或者没有）。所以我倾向于（除非有充分的理由这样做）创建IQuerable的扩展方法，并以这种方式组织我的代码。2p@ElHaix...It看起来你可以使用DI容器来注入你的上下文。在这个问题上有很多不同的观点。许多人也不同意。不幸的是，Ayende的反应是直接在控制器中使用上下文，这有其自身的一系列问题。如果你就此向他提问，他坚称这不是他的意思，但他拒绝提供一个像样的例子来说明他的意思。见鬼，他的一个例子使用了一个实际的单例来存储数据上下文。@ErikFunkenbusch-在这个问题上有很多不同的观点。那是肯定的！