c# - 什么方式比较好 : make own wrapper for DbContext or use DbContext in Controller

Question

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

我怎样才能做得更好:

1. 使用 Controller 中的 dbcontext。在下面link作者解释说这种方式更好，但它是否适合 Controller ？
2. 制作自己的 wrapper 。一些Best practices写下自己的存储库最好做什么。

我不会在其他方面更改 ef，所以请不要介意，即使存在强大的连接性以访问来自特定实现的数据我知道在 ef7 dbcontext 中立即实现了工作单元和存储库模式。

Answer 1

您问题的答案主要基于意见。在许多其他问题得到回答之前，没有人可以明确地说“一种方法比另一种方法更好”。您项目的规模/范围/预算是多少？有多少开发人员会参与其中？它只会有(基于 View 的)MVC Controller ，还是会有(基于数据的)API Controller ？如果是后者，MVC 和 API 操作方法之间会有多少重叠(如果有)？它会有任何非网络客户端，比如 WPF 吗？您打算如何测试该应用程序？

Entity Framework 是一种数据访问层 (DAL) 工具。 Controller 是 HTTP 客户端请求和响应处理工具。除非您的应用程序是纯 CRUD(这是值得怀疑的)，否则在您通过 HTTP 接收 Web 请求和使用 EF 将该请求的数据保存到数据库之间，您可能需要进行某种业务逻辑处理(字段 X 是必需的，如果您为字段 Y 提供数据，则还必须为字段 Z 提供数据，等等)。因此，如果您直接在 Controller 中使用 EF 代码，这意味着您的业务处理逻辑几乎肯定会与其一起出现在 Controller 中。

我们这些在使用 .NET 开发重要应用程序方面具有相当丰富经验的人倾向于形成这样的观点，即业务逻辑和数据访问逻辑都不应该出现在 Controller 中，因为在实现这种设计时会出现某些困难。例如，当您将 web/http 请求和响应逻辑以及业务逻辑和数据访问逻辑放入 Controller 中时，您最终不得不从 Controller 操作本身测试所有这些应用程序方面(这明显违反了 Single责任原则，如果你关心 SOLID 设计)。还假设您开发了一个带有返回 View 的 Controller 的传统 MVC 应用程序，然后决定将该应用程序扩展到其他客户端，如 iOS/android/WPF/或其他一些不理解您的 MVC View 的客户端。如果您决定实现第二组基于 WebAPI 数据的 Controller 操作，您将至少在两个地方复制业务和数据访问逻辑。

不过，这并不能决定将所有业务和数据访问逻辑保留在 Controller 中，本质上比替代设计“更差”。在设计 Web 应用程序的体系结构时做出的任何决定都有利有弊。无论您选择哪条路线，总会有取舍。将所有应用程序代码保存在 Controller 中的优势包括降低成本和复杂性，从而缩短上市时间。为非常简单的应用程序过度设计复杂的架构是没有意义的。不管多么不幸，我个人从未有过开发简单应用程序的乐趣，所以我“普遍认为”将业务和数据访问代码保留在 Controller 中“可能不是”一个好的长期设计决策。

如果您真的对替代品感兴趣，我会推荐 reading these two articles .它们很好地介绍了如何实现 Controller 可以使用的命令和查询 (CQRS) 模式。 EF 确实实现了开箱即用的存储库和工作单元模式，但这并不一定意味着您需要“包装”它以便将数据访问代码移出 Controller 。祝您在为项目做出此类决定时好运。

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