ASP.NET MVC - DbContext的良好实践

Question

我正在使用Entity Framework启动一个新的.NET MVC项目,我正在努力解决一些问题.

1. 在我的模型中,我有大约150个实体(从数据库生成).只有一个DbContext是个好主意吗？如果没有,我应该如何划分我的实体？

2. 如果我有一个DbContext并且我创建了一个实例化数据库上下文对象的类变量(在Controller中),那么这个DbContext会发生什么？它是否在内存中为每个实体创建了单独的空间？在我的情况下,当我有150个实体时,它不会非常有效.我错了吗？

3. 我将在许多控制器中使用我的DbContext.创建一个MainController(我创建新的DbContext)是一个好主意,它将由其他控制器继承吗？因为这允许其他人访问相同的Context.

4. 处理我的DbContext的最佳做法是什么？我已经读过使用依赖注入是一种好习惯.但是通过这种方式,我将不得不为每个控制器注入上下文.哪种依赖注入方式最流行并且现在使用？

真的需要你的建议.它将使我更深入地了解这一发展.

Answer 1

1. 有一个是好的DbContext.如果您有很多,则只需确保在该上下文中存在所需的所有实体.例如,如果Person从数据库中检索出一个与它们相关的数据Address,则两者都必须存在Person并且Address必须存在DbContext.

   我没有尝试过使用多个DbContext实例,但要注意的一件事是,如果在多个上下文中包含相同的表,最终可能会出现类似名称或冲突的类.例如,如果包含Person两个上下文,则每个上下文将尝试创建一个名为的类Person.

2. 创建DbContext它时,它只会为您从数据库中检索的数据创建对象.因此,如果您从Person表中请求一行,则只会Person创建一个对象.如果请求100行,则将创建100个实例.

3. 有两种选择.一,在每个动作中创建一个新实例,完成你的工作,然后保存它.或者,DbContext在构造函数中创建一个并在整个类中重用它.

4. 这取决于您在第3点中选择的内容.如果将它传递给构造函数,则IDisposable在那里实现并释放它.如果在每个操作中创建一个新操作,请确保使用该using语句处理它.

对于依赖注入,有很多选项,教程等,关于如何在ASP.NET MVC中执行此操作.我个人使用Autofac和相关的MVC扩展,并将一个新的实例传递DbContext到每个控制器.

Answer 2

150 个实体并不是一个巨大的 DbContext，但它的大小超过了 EF 在第一个 DbContext 初始化时开始出现性能问题的大小。如果您可以在逻辑上将实体划分为责任区域（称为有界上下文），那么您可以考虑使用多个 DbContext。另外，您的应用程序需要使用所有这些实体吗？如果没有，您也许可以简化事情。另请注意，您至少需要 EF6 才能有效地工作，以前版本的实体框架存在多个上下文问题。

使用多个上下文时还必须小心。许多人会遇到麻烦，因为他们从一个上下文中获取一个实体，然后在另一个上下文中调用保存更改，然后不明白为什么他们的更改没有保存。或者，他们尝试将从一个实体检索到的实体添加到另一个实体，但您无法执行此操作。多个上下文使事情变得更加复杂，因此在拆分之前请确保您想要承担这种复杂性。

不必担心 DbContext 使用的内存量，只要正确处置它即可。除非您实际从所有这些表中加载对象，否则内存量将是最小的。

我认为通用基础控制器是一种代码味道。它通常是完全没有必要的，并且通常最终会成为您认为想要共享的每一段代码的垃圾场，这违反了单一责任原则。最重要的是，无论如何您都不应该在控制器中进行数据访问。您应该有某种类型的服务层或业务层来调用数据访问层。正确分离您的关注点是设计良好的 MVC 应用程序的关键部分。

是的，依赖注入是一个很好的实践。我不确定“必须注入我所有的控制器”是什么意思。依赖项注入的全部目的是注入您的依赖项，因此“必须”的概念使您看起来像是在试图避免您正在尝试做的事情。

依赖注入是一个原则。实现这一原则的方法有很多种，使用哪种方式完全取决于你自己的喜好和要求。除了确保您遵循原则而不是特定技术之外，我们无法告诉您什么是“最好的”。