“每个请求的会话”模式是否利用了缓存？ （“每个会话的会话”或“每个请求的会话”）
我今天在Web应用程序中从头开始构建一个新的应用程序。
（技术是Asp.Net ，我使用的ORM是Entity Framework 。如果重要的话）
我不确定每个请求广泛使用的模式会话是否真的很好。
在我看来，模式的优点是缓存不会增加，直到数据库会话崩溃\太大而因此效率低下。
但是每个请求的新会话是不是太多了？ 这意味着每个服务器调用都会重置缓存，即使像auto-complete这样的简单ajax请求也有一个全新的缓存，实际上对于缓存重置的每个键击都是如此。
您在一个请求中查询同一对象实体行的可能性很小。
每个会话的会话是不是更好的模式？ 它具有两方面的优点
- 缓存永远不会增长。
- 实际上可以使用缓存…
那么…… 为什么每个请求的会话被如此广泛地使用，并且每个会话的会话不是？
澄清：
- 当我编写ORM会话时，它既适用于
NHibernate's session，也适用于EntityFramework's DbContext。 - 我的意思是在每个请求上对session \ dbcontext进行flush-commit-SaveChanges。
每个请求模式的会话对于与ORM一起使用更自然且更健壮。 它获得脏实体的机会较小，并且具有更可预测的资源管理。
如果我说得对，你的意思是Session下的DbContext实例比会话每会话只能在没有数据修改的应用程序中使用，否则你会得到意外的数据提交，而其他请求执行数据修改。 此外，我不确定entity framework上下文是否是线程安全的 – 处理请求是multithreading的。
我不完全确定，但我认为entity framework不会像您期望的那样使用缓存（==身份映射）。 在选择实体集时，即使所有数据都在缓存中，它也会查询数据库 – 它只能避免构建新实体，而是使用身份图中的现有实体。
对于缓存，还有其他解决方案，它们更好。
对我来说，一切都是通过将一个工作单元限制在一个请求中来提供一致性。 我不确定当出现问题时每个会话的会话如何工作。
例如，如果处理了几个请求，然后在提交时得到一个乐观的并发exception，你会怎么做？ 那时你可能会遇到几次合并冲突。
因此，每个请求的会话只会限制您的冲突风险，并使请求范围内的工作单元成为可能。