为 MVC 控制器声明 DbContext

Question

在线查看一些 MVC 示例，我发现通常在控制器中，DbContext 变量被声明为私有成员变量（即全局）并且可供所有方法访问。

但是，我最近看到一篇关于 ASP.NET Identity 的文章，并注意到在控制器中，在每个方法中声明了 DbContext（这需要它）。

这种方法有安全优势吗？也许限制安全对象的生命周期以获得更好的整体安全性？！？！

如果不是，那么我认为第一种方法更有效，其中数据库上下文在控制器加载时被实例化。

以下是我能找到的关于 DbContext 的所有信息，但没有什么可以真正回答我的问题。

DbContext declaration - Framework 4.1 - MVC 3.0

MVC, DbContext and Multithreading

Answer 1

对于每个请求，都会构造一个新的控制器实例。因此，出于所有意图和目的，dbcontext 是在构造函数中实例化还是在任何给定方法中封装并不重要。

除了样式选择之外，在给定方法中声明和包含 dbcontext 的原因是：

• 不需要它的方法不会实例化上下文，从而消除开销（如果有的话）。这也可以使用惰性初始化模式来完成。
• 上下文在方法完成后立即处理，而不是在请求结束时处理。一般来说，这不应该是一个问题；通常，如果用户等待的时间超过几秒钟，您就会遇到更大的问题。
• 不同的方法使用不同的上下文。

其中，声明单个上下文并实例化一次的一些原因：

• 您只有一个地方可以实例化一个上下文，而不是很多地方。在典型的应用程序中，无论如何，大多数页面都需要数据库中的一些信息。
• 调用其他方法的方法不会各自保留自己的上下文对象实例。
• 您可以创建一个基本控制器类，默认情况下会创建一个 dbcontext 对象，从而允许您在所有继承的控制器中保持 DRY。

Answer 2

Answer from @Ic。很不错。我想补充一点，如果您需要将信息从您的请求传递到您的 DbContext 构造函数，那么您需要在您的操作方法中创建您的 DbContext 实例。原因是 Request 对象在控件进入您的操作方法之前将为空。

更多信息：我需要根据用户的位置动态构建连接字符串。我将该位置保存为我通过请求对象访问的 cookie。我在操作方法中有一个有效的请求，但它在构造函数中或控制器的类级别属性中为空。