ASP.NET Session 对象中的实体框架对象上下文？

Question

我们有一个多层的 Asp.NET Web 窗体应用程序。数据层有一个名为DataAccess 的类，它实现IDisposable 并具有我们的实体框架对象上下文的实例作为私有字段。该类具有许多返回各种实体集合的公共方法，并且在释放其对象上下文时将释放它。

由于我们遇到了许多问题，我们认为将对象上下文（或 DataAccess 实例）在服务器上的作用域中保留更长时间将是一个很大的优点。建议在 这篇文章 以便每个 Http 请求有一个实例。

我想知道的是：将对象上下文的实例存储在 HttpContext.Current.Session 对象中会产生什么问题？？？

• 我假设 Session 对象已完成并在用户会话过期时设置为垃圾回收，因此该实例将被正确处理。
• 我假设大多数默认浏览器设置都会让我们的应用程序毫无疑虑地放置其 SessionId cookie。
• 对象上下文将处理的数据量并不大，并且不会对我们像样的服务器硬件造成问题，因为随着时间的推移缓存和相对较少的并发用户。

这实施起来会相对较快，并且不会影响我们许多现有的单元测试。

我们将使用 AutoFac 和 ServiceProvider 类来提供实例。当需要 ObjectContext 的实例时，它将由类似于以下的代码返回：

private static Entities GetEntities(IContext context)
{
    if (HttpContext.Current == null)
    {
        return new Entities();
    }

    if (HttpContext.Current.Session[entitiesKeyString] == null)
    {
        HttpContext.Current.Session[entitiesKeyString] = new Entities();
    }

    return (Entities)HttpContext.Current.Session[entitiesKeyString];
}

干杯。

Answer 1

我认为在会话状态中存储 ObjectContext 不是一个好的做法，因为该类旨在封装工作单元模式 - 您加载一些数据（实体），修改他们，提交您的更改（由 UOW 跟踪），然后您就完成了。 UOW 对象并非旨在或设计为长期存在的。

也就是说，它可以在不造成任何重大灾难的情况下完成，您只需确保了解幕后发生的事情即可。 如果您打算这样做，请继续阅读，以便您知道自己将面临什么并了解权衡。

---

我假设 Session 对象已完成，并在用户会话过期时设置为垃圾回收，因此该实例将被正确处置。

这实际上是不准确的，或者至少看起来是基于其措辞方式。会话到期/注销不会立即导致任何项目被处置。它们最终将被最终确定/处置，但这取决于垃圾收集器，您无法控制它何时发生。这里最大的潜在问题是，如果您碰巧在 ObjectContext 上手动打开一个连接，该连接不会自动关闭 - 如果您不小心，您最终可能会泄漏数据库连接，这会导致常规单元测试/集成测试/实时测试不会发现这些问题。

对象上下文将处理的数据量并不是很大，并且不会对我们像样的服务器硬件造成问题，因为随着时间的推移缓存和相对较少的并发用户。

请记住，增长是无限的。如果某个特定用户决定连续 12 个小时使用您的网站并整天运行不同的查询，那么上下文将会变得越来越大。 ObjectContext 没有自己的内部“垃圾收集”，它不会清除长时间未使用的缓存/跟踪实体。如果根据您的用例，您确定这不会成为问题，那么很好，但应该困扰您的主要问题是您对情况缺乏控制。

---

另一个问题是线程安全。 ObjectContext 不是线程安全的。会话访问通常是序列化的，因此一个请求将阻塞等待其会话状态，直到同一会话的另一请求完成。但是，如果有人决定稍后进行优化，特别是页面级只读会话的​​优化，请求将不再持有独占锁，并且最终可能会遇到各种竞争条件或重入问题。

最后但并非最不重要的当然是多用户并发问题。 ObjectContext 永远缓存它的实体，直到它被释放为止。如果另一个用户在自己的 ObjectContext 上更改相同的实体，则第一个 ObjectContext 的所有者将永远发现该更改。这些过时的数据问题可能非常难以调试，因为您实际上可以看到查询进入数据库并返回新数据，但 ObjectContext 会用已经存在的旧的、过时的数据覆盖它。在缓存中。在我看来，这可能是避免长期存在的 ObjectContext 实例的最重要原因；即使您认为您已对其进行编码以从数据库中获取最新数据，ObjectContext 也会认为它比您更聪明，并将旧实体返还给您。

---

如果您了解所有这些问题并已采取措施缓解这些问题，那就好了。但我的问题是，为什么您认为会话级 ObjectContext 是一个好主意？创建 ObjectContext 实际上是一个非常便宜的操作，因为元数据是为整个 AppDomain 缓存的。我敢打赌，要么你错误地认为它很昂贵，要么你试图在几个不同的网页上实现复杂的有状态进程，而后者的长期后果比任何特定的后果都要糟糕得多只需将 ObjectContext 放入会话中可能会造成损害。

如果你无论如何都要继续做这件事，只要确保你这样做是出于正确的理由，因为没有太多充分的理由这样做。但是，正如我所说，这绝对是可能的，并且您的应用程序不会因此而崩溃。

---

更新 - 对于其他考虑否决此问题的人，因为“同一会话上的多个请求可能会导致线程安全问题”，请阅读 ASP.NET 会话状态概述文档。序列化的不仅仅是会话状态的单独访问；任何获取会话的请求都会对该会话保留独占锁，直到整个请求完成后才会释放该锁。除了我上面列出的一些优化之外，在默认配置中不可能有两个同时请求持有对 ObjectContext 的同一会话本地实例的引用。

由于上面列出的几个原因，我仍然不会在会话状态中存储 ObjectContext，但这不是线程安全问题，除非您将其设为线程安全问题。

Answer 2

每个请求应该使用一个 ObjectContext，不应该将其存储在 Session 中。长期保存在ObjectContext中的数据很容易被破坏：

1. 如果插入的数据不违反ObjectContext中的规则，但违反了数据库中的规则怎么办？如果插入违反规则的行，是否会将其从上下文中删除？图像情况：您使用一个上下文，突然您请求更改一个表中的数据，将行添加到另一个表中，然后调用 SaveChanges()。其中一项更改会引发约束违规错误。你如何清理它？清理上下文并不容易，在下一个请求中获取新的上下文会更容易。

2. 如果有人从数据库中删除数据，而数据仍在上下文中怎么办？ ObjectContext 会缓存数据，并且不会时不时地检查数据是否仍然存在或是否已更改:)

3. 如果有人更改了 web.config 并且会话丢失了怎么办？似乎您想依靠 Session 来存储有关登录用户的信息。表单身份验证 cookie 是存储此信息的更可靠的地方。会话在很多情况下都可能丢失。

ObjectContext 被设计为短暂的，最好在需要时在请求中创建它并在其结束时进行处置。

如果每个请求的上下文不适合您，那么您可能做错了什么，但不要通过使用 Session 使情况变得更糟。