將 DataTable object 存儲在 asp.net session 中的壞主意

Question

我知道將 DataTable 存儲在 asp.net 中的 session 變量中是不好的，因為它將使用大量服務器的 memory。 我不明白的是，那你在什么時候做什么：

1. 用戶進入需要加載數據表 object 的頁面（來自 SQL 服務器）。
2. 用戶單擊簡單事件的單選按鈕（例如，某些控件被禁用）。
3. If you don't save the DataTable object in the session, you have to load it from the SQL server again upon postback on same page instead of just fetching it from the session?

感謝幫助。

Answer 1

DataTable 是相當重的對象，因此不建議將其存儲在 ViewState 或 Session 中。 您描述的場景是關於緩存數據的。 那么，為什么不使用 ASP.NET 的緩存呢？

ViewState雖然它在服務器上使用的 memory 不如 Session 或 Cache 多，但仍然需要在服務器上進行序列化/反序列化，需要一些臨時 ZCD69B4957F06CD818D7BF3D61980E291服務器（只需在任何瀏覽器中查看查看源代碼，您就會看到帶有 base-64 編碼數據的非常大的隱藏輸入）。 如果您不使用加密，任何人都可以解碼在每個請求中傳遞的數據，如果其中任何數據是敏感的，則會導致潛在的安全問題。 ViewState 也適用於少量數據，通常最好堅持使用主要數據類型，如整數和字符串。

Session通常也不是一個好主意，因為它還需要序列化/反序列化，除了每個用戶對 memory 的壓力之外，這還增加了額外的開銷。 Session 具有memory 限制，隨着並發用戶的增加，每個用戶的限制會降低。 Session 數據不會“過期”，直到每個用戶的實際 session 過期，默認為 30 分鍾。 Session 非常適合用戶特定的數據，但建議保持非常小，並再次堅持主要數據類型，如整數和字符串。

緩存不序列化任何數據，並且僅由於操作系統的位數而受到大小限制。 在 Windows 2003 32 位上，您可以使用 800 MB 的總應用程序池大小（如果使用 /3GB 開關，則為 1.2 或 1.3 GB）。 在 64 位下，有更多的自由和限制，實際上只有您配置的可用系統數量達到 memory。 緩存的一個好處是，隨着 memory 壓力的增加，緩存可以過期以釋放 memory 用於更重要的事情。 當 memory 壓力不是一個因素時，您還可以控制物品何時過期（不能保證過期）。 如果使用 SQL 服務器，則可以采取額外的步驟，您可以將緩存依賴於數據庫中的數據，讓數據本身決定何時過期您的緩存，確保數據新鮮。

最后，可以使用經常被遺忘的應用程序object，但只能用於您知道可以在用戶之間共享並且不需要經常更改的數據（希望在應用程序重新啟動之前不會更改）。

使用 Microsoft 的ViewState 、 Session 、 Cache和Application對象的文檔來確定每個特定場景的最明智使用。 除了使用 AJAX（以避免整頁回發）和 HTTP 壓縮以減少傳遞給客戶端的負載之外，正確使用這些組合可以使站點響應速度非常快。

在 Web 場和負載平衡等更復雜的場景中，還有其他問題需要考慮。 您需要問自己的問題如下：如果用戶訪問的服務器與最初請求的服務器不同，是否應該創建新的 session？ 無論用戶點擊什么服務器，緩存都應該工作嗎？ 這些問題將為您帶來可能會改變您存儲數據的位置的解決方案。 InProc Session 比使用 SQL 服務器作為 session 服務器更寬容，因為有額外的序列化限制。

Answer 2

如果您只想在頁面級別使用它，另一種存儲 DataTable 的方法是在ViewState中。 ViewState["dtbl"] = DataTable;

您可以從ViewState Simply DataTable dtbl = (DataTable)ViewState["dtbl"];