「每個請求的會話」模式是否利用緩存？ （「每個會話的會話」或「每個請求的會話」）

Question

我現在在Web應用程序中從頭構建一個新的應用程序。
（該技術是Asp.Net和我使用的ORM是Entity Framework。如果它的事項）

我不確定的，如果每個請求廣泛使用的模式會議確實是一個很好的一個。
正如我所看到的，該模式的優點在於，直到數據庫會話崩潰時，緩存纔會增加\因爲太大而效率低下。

但是不是每個請求的新會話太多？這意味着每一次服務器調用都會重置緩存，甚至像auto-complete這樣的簡單ajax請求也會有一個全新的緩存，實際上對於緩存重置的每一次擊鍵都是如此。

在一個請求中查詢同一個對象實體行的機會很小。

是不是會話每次會話是一個更好的模式？它同時具有這兩個優點含義

1. 緩存將永遠不會增長。
2. 緩存可以實際使用...

所以...... 爲什麼每個請求會話的用途很廣泛，每個會話會議是不是？

---

澄清：

1. 當我寫ORM會話它同時適用於NHibernate's session和EntityFramework's DbContext。
2. 我的意思是在每個請求上flush-commit-saveChanges of session \ dbcontext。

Answer 1

對於使用ORM，每個請求模式的會話更加自然和健壯。它有較小的機會去弄髒實體並具有更可預測的資源管理。

如果我認識你並且指的是Session下的DbContext實例，那麼Session Session Session只能在沒有數據修改的應用中使用，否則當其他請求執行數據修改時，您會收到意外的數據提交請求。另外我不確定實體框架上下文是線程安全的 - 處理請求是多線程的。

我不完全確定，但我認爲實體框架不使用緩存（==身份映射）如您所期望的那樣寬。在選擇實體集時，即使所有數據都在緩存中，它也會查詢數據庫 - 它只能避免構建新實體，而是使用身份映射中的現有實體。

對於緩存還有其他解決方案，他們更好。

Answer 2

對我來說，這完全是關於通過將一個工作單元約束到一個請求來提供一致性。我不確定每次會話會話在事情出錯時會如何工作。

例如，如果處理了幾個請求，然後在提交時獲得樂觀併發異常，您會怎麼做？那時你可能會有幾次合併衝突。

因此，每個請求的會話只會限制您的衝突風險並使請求範圍上的工作單元。