这几天我在web应用程序中从头开始构建了一个新的应用程序
(技术是Asp.Net，我使用的ORM是Entity Framework。如果重要的话)
我不确定被广泛使用的模式每个请求的会话是否真的是一个好模式
在我看来，这种模式的优点是，在数据库会话崩溃之前，缓存不会增加，因为它太大，因此效率低下。
但是，针对每个请求的新会话不是太多了吗？这意味着每一次服务器调用都会重置缓存，即使是像auto-complete这样的简单ajax请求也会有一个全新的缓存，事实上，对于每一次按键，缓存都会重置。
在一个请求中查询同一对象实体行的可能性很小。
每次会话 不是更好的模式吗？它既有的优点
- 缓存不会永远增长
- 缓存实际上可以使用
所以为什么每个请求的会话被如此广泛地使用，而每个会话的会话却没有
澄清：
- 当我编写ORM会话时，它同时适用于
NHibernate's session和EntityFramework's DbContext - 我的意思是在每次请求时刷新会话\dbcontext的SaveChanges
每个请求的会话模式对于与ORM一起使用更自然、更健壮。它获得脏实体的机会更小，并且具有更可预测的资源管理。
如果我说得对，你的意思是Session下的DbContext实例比Session Per Session只能在应用程序中使用，而不需要修改数据，否则当其他请求执行数据修改时，你会收到请求提交的意外数据。此外，我不确定实体框架上下文是线程安全的，而处理请求是多线程的。
我不完全确定，但我认为实体框架并没有像您期望的那样广泛地使用缓存(==标识映射)。在选择实体集时，即使所有数据都在缓存中，它也会查询数据库——它只能避免构建新的实体，而是使用身份映射中的现有实体。
对于缓存，还有其他解决方案，而且它们更好。
对我来说，这一切都是为了通过将工作单元约束到单个请求来提供一致性。当出现问题时，我不确定每节课的效果如何。
例如，如果处理了几个请求，然后在提交时出现乐观并发异常，该怎么办？此时可能会出现多个合并冲突。
因此，每个请求的会话只会限制冲突的暴露，并使请求的工作单元具有范围。