哪种方法更好：为DbContext自己包装或在Controller中使用DbContext

在我的项目中，我使用实体框架7和asp.net mvc 6 \ asp.net 5。我想为自己的模型创建CRUD

我该如何做得更好：

从控制器使用dbcontext。在下面的链接中，作者解释说这种方法更好，但是对于控制器来说是否合适？

做自己的包装。一些最佳实践中写到什么是最好的自己的存储库。

我不会在其他地方更改ef，所以即使在通过特定实现访问数据的功能强大的连接中，也不要介意，而且我知道在ef7 dbcontext中立即实现了工作单元和存储库模式。

您问题的答案主要基于意见。在回答许多其他问题之前，没有人可以明确地说“一种方法比另一种方法更好”。您的项目规模/范围/预算是多少？有多少开发人员将从事此工作？它将仅具有（基于视图的）MVC控制器，还是具有（基于数据的）API控制器？如果是后者，则MVC和API动作方法（如果有）之间会有多少重叠？它会有非Web客户端吗，例如WPF？您打算如何测试该应用程序？

实体框架是数据访问层（DAL）工具。控制器是HTTP客户端请求和响应处理工具。除非您的应用程序是纯CRUD（令人怀疑的），否则在通过HTTP接收Web请求与使用EF将请求的数据保存到数据库之间之间，可能需要进行某种业务逻辑处理。字段X是必填字段，如果您提供字段Y的数据，则还必须提供字段Z的数据，依此类推。因此，如果您直接在控制器中使用EF代码，这意味着您的业务处理逻辑几乎肯定会与它一起出现在控制器中。

我们中那些在.NET上开发非平凡应用程序具有丰富经验的人往往会提出这样的观点，即由于实施此类设计时会出现某些困难，因此控制器中既不应出现业务逻辑，也不应出现数据访问逻辑。例如，当您将Web / http请求和响应逻辑以及业务逻辑和数据访问逻辑放入控制器中时，最终必须从控制器动作本身测试所有这些应用程序方面（这明显违反了Single责任原则（如果您关注SOLID设计）。也可以说，您开发了一个带有返回视图的控制器的传统MVC应用程序，然后决定要将该应用程序扩展到其他客户端，例如iOS / android / WPF /或其他一些不了解您的MVC视图的客户端。

尽管如此，与替代设计相比，这并没有决定使控制器中的所有业务和数据访问逻辑本质上“更糟”。您在设计Web应用程序体系结构时所做的任何决定都会有优点和缺点。无论您选择哪种路线，总会有一些取舍。将所有应用程序代码保留在控制器中的优势包括较低的成本，复杂性以及上市时间。对非常简单的应用程序过度设计复杂的体系结构没有任何意义。不幸的是，我个人从来没有开发过一个简单的应用程序的乐趣，因此我“普遍认为”，将业务和数据访问代码保留在控制器中“可能”不是一个好的长期设计决策。

如果您真的对替代品感兴趣，我建议阅读这 两篇文章。它们很好地介绍了如何实现控制器可以使用的命令和查询（CQRS）模式。EF确实开箱即用地实现了存储库和工作单元模式，但这并不一定意味着您需要“包装”它才能将数据访问代码移出控制器。祝您在项目中做出这类决定时万事如意。

public async Task Index() {
    var user = await query.Execute(new UserById(1));
    return View(user);
}