3

这几天我在一个 Web 应用程序中从头开始构建一个新应用程序。
（技术是Asp.Net，我使用的 ORM 是Entity Framework。如果重要的话）

我不确定每个请求广泛使用的模式会话是否真的很好。
正如我所看到的，该模式的优点是缓存不会增加，直到数据库会话崩溃\太大，因此效率低下。

但是每个请求的新会话不是太多了吗？这意味着每次服务器调用都会重置缓存，即使是像自动完成这样的简单 ajax 请求也会有一个全新的缓存，实际上每次按键都会重置缓存。

您在一个请求中查询相同的对象实体行的机会很小。

每个会话的会话不是更好的模式吗？兼具优势意义

  1. 缓存不会永远增长。
  2. 缓存其实可以用...

那么......为什么每个请求的会话被如此广泛地使用而每个会话的会话却不是？

说明：

  1. 当我编写 ORM 会话时，它同时适用于NHibernate's session和EntityFramework's DbContext.
  2. 我的意思是在每个请求上刷新 session\dbcontext 的提交保存更改。
4

2 回答 2

1

对我来说，这一切都是为了通过将一个工作单元限制在一个请求中来提供一致性。我不确定当出现问题时每个会话的会话将如何工作。

例如，如果处理了多个请求，然后在提交时收到乐观并发异常，您会怎么做？那时你可能会有几个合并冲突。

因此，每个请求的会话只会限制您的冲突暴露，并使请求范围内的工作单元。

于 2012-09-23T17:43:39.807 回答
1

每个请求的会话模式对于与 ORM 一起使用更加自然和健壮。它获得脏实体的机会更小，并且具有更可预测的资源管理。

如果我没听错，并且您的意思是 Session 下的 DbContext 实例，那么 Session Per Session 只能在应用程序中使用而无需修改数据，否则您将收到一个请求提交的意外数据，而其他请求执行数据修改。另外我不确定实体框架上下文是线程安全的——而处理请求是多线程的。

我不完全确定，但我认为 Entity Framework 并没有像您期望的那样广泛使用缓存（== 标识映射）。在选择实体集时，即使所有数据都在缓存中，它也会查询数据库——它只能避免构建新实体，而是使用身份映射中的现有实体。

对于缓存，还有其他解决方案，它们更好。

于 2012-09-23T17:13:59.720 回答