什么方法更好：为 DbContext 制作自己的包装器或在 Controller 中使用 DbContext

Question

在我的项目中，我使用了entity framework7和asp.netmvc 6\asp.net5。我想为自己的模型创建 CRUD

我怎样才能做得更好：

使用控制器中的 dbcontext。下面link作者说明这种方式比较好，但是对于控制器来说是否合适呢？
制作自己的包装器。一些Best practices写什么最好自己做仓库。

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

Answer 1

这取决于您的应用程序的生命周期。

如果它将被使用、扩展和更改多年，那么我认为创建一个 wrapper 是一个不错的选择.

如果是小型应用程序并且如您所说，您不打算更改EntityFramework到另一个ORM，然后省去创建包装器的工作，并在控制器中直接使用它。

Answer 2

这个没有确定的答案。这完全取决于您要做什么。如果您要实现代码可维护性，我建议您使用包装器。

Answer 3

通常我更喜欢将 Repository 模式与 UnitOfWork 模式一起使用 (http://www.asp.net/mvc/overview/older-versions/getting-started-with-ef-5-using-mvc-4/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application) - 我在 UnitOfWork 实例对象中实例化 DbContext，然后将该 DbContext 注入到存储库中。之后我在控制器中实例化 UnitOfWork 并且控制器对 DbContext 一无所知：

public ActionResult Index()
{
    var user = unitOfWork.UsersRepository.GetById(1); // unitOfWork is dependency injected using Unity or Ninject or some other framework
    return View(user);
}

Answer 4

您问题的答案主要是opinion-based。在回答许多其他问题之前，没有人可以明确地说 "one way is better than the other"。您项目的规模/范围/预算是多少？有多少开发人员会参与其中？它只会有 (view-based) 个 MVC 控制器，还是会有 (data-based) 个 API 个控制器？如果是后者，MVC 和 API 操作方法之间会有多少重叠（如果有）？它会有 non-web 个客户端吗，比如 WPF？您打算如何测试该应用程序？

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

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

不过，这并没有决定将所有业务和 data-access 逻辑本质上保留在控制器中 "worse" 而不是替代设计。在设计 Web 应用程序的体系结构时做出的任何决定都有利有弊。无论您选择哪条路线，总会有 trade-offs。将所有应用程序代码保存在控制器中的优势包括降低成本和复杂性，从而缩短上市时间。对于非常简单的应用程序，over-engineer 复杂的体系结构没有意义。然而不幸的是，我个人从未有过开发简单应用程序的乐趣，所以我认为 "general opinion" 在控制器中保留业务和数据访问代码是 "probably not" 一个很好的 long-term 设计决定。

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

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

什么方法更好：为 DbContext 制作自己的包装器或在 Controller 中使用 DbContext

What way is better: make own wrapper for DbContext or use DbContext in Controller

c#

entity-framework-core

asp.net-core-mvc

asp.net-core