在过去的几个月里，我将我的 Webforms 知识迁移到了 MVC 知识，我不得不说，在最初成为 MVC 怀疑论者之后，我爱上了 MVC 及其工作方式。
唯一我还不清楚的是静态类是如何在 MVC 中持久化的。在 Webforms 中，静态类值在访问应用程序的不同客户端之间共享，如果您决定使用静态类来保存与用户相关的变量，这可能会导致用户覆盖另一个用户值。
我的第一个问题是 MVC 中是否仍然如此？
然后我的第二个问题是关于在我的 MVC 应用程序中保存 DBContext 实例的位置。目前我将它作为静态 DAL 类中的公共变量。然后在所有客户端之间共享单个上下文。
我阅读的越多，我就越开始相信这是不正确的方法，但是在每个控制器内部重新创建上下文似乎是重复的。
将 Context 放在静态类中有缺点吗？
【问题讨论】：
标签： c# asp.net-mvc entity-framework
上下文应该是短暂的，所以它可能看起来是重复的，但是是的，在每个控制器中创建一个上下文。准确地说，每个请求使用一个上下文。
【讨论】：
在应用程序的整个生命周期中保留单个 DbContext 实例对我来说听起来不是一个好主意。我通常每个Request 使用一个DbContext 实例。
在决定应用程序中DbContext 的适当生命周期时，您可能需要考虑以下两点：
对多个请求重复使用相同的上下文可以让您受益于 缓存实体，您可以将许多命中保存到数据库中，但是 然后您可能会遇到性能问题，因为您最终可能会遇到 在某个时间将所有数据库实体保存在内存中。
另一方面，过于频繁地重新实例化上下文也不是 推荐，因为这是一项昂贵的操作。
您必须在这两种方法之间找到平衡点，对我来说，实例化 DbContextPer Request 在大多数情况下效果最佳。
【讨论】：
DbConext 不是线程安全的，EF 只允许在同一上下文中进行一个并发操作。因此，跨请求共享它不是一个好主意。 在大多数情况下，每个请求的上下文是最好的解决方案。 （提示：有一些 IoC 框架，例如 autofac，可以根据请求创建实例）
【讨论】：