從應用程序編程（C＃/ Visual C ++）到ASP.NET（C＃）的一些問題

Question

在我工作的新地方，我一直在開發一個Web應用程序框架。 我是ASP.NET框架的新手（6個月），事情看起來非常簡單，但我有幾個問題，我想問你ASP專業人士。 我會注意到我對C＃並不陌生。

長壽命對象/緩存

處理每次頁面不想重新初始化的對象的首選方法是什么？ 我注意到有一個可以使用的緩存管理器，但使用它有什么警告嗎？ 例如，我可能想要緩存各種各樣的東西，我正在考慮圍繞緩存編寫一個封裝器，它以前綴緩存名稱為例，這樣我就可以使用相同的底層.NET緩存管理器實現不同的緩存。

1）我是否需要考慮我想要緩存的對象的設計考慮因素？

2）如果我想在Web應用程序的生命周期中實現一段時間的管理器（顯然是線程安全的），是否足以在app_start期間初始化它並在app_end中將其終止？ 或者這是不受歡迎的，並且任何管理器都是在所服務頁面的構造函數/ init方法中唯一創建的。

3）如果我在應用程序啟動時初始化了一個長期對象，那么當應用程序池被回收時，這可能會受到影響嗎？ 如果它在應用程序端被破壞，它只是被破壞然后再次重新創建的情況？ 我很滿意這個限制，我只想更清楚:)

長壽線程

我對此做了一些研究，這個問題可能是多余的。 在ASP.NET環境中啟動工作線程似乎是不安全的，而是使用Windows服務來執行長時間運行的任務。 后者不是一個問題，目標環境將具有安裝服務的功能，但我只想仔細檢查這是絕對必要的。 我理解線程可以拋出異常而死，但我不明白禁止它們的原因。 如果.NET提供了一個包含System.Thread的線程框架，但也提供了關於Application Server何時要回收App-Pool的通知，我們實際上可以做一些關於它的事情，而不僅僅是關注並在我們停止。

在ASP.NET中是否有任何線程解決方案，或者它基本上是“服務”？

我相信我會有更多的疑問，但現在就是這樣。

編輯：謝謝你的所有回復！

Answer 1

1）緩存的主要內容是了解緩存的生命周期，以及緩存中緩存（特別是大）對象的影響。 考慮在每次訪問default.aspx頁面時生成的內存中緩存1MB對象; 經過一年的生產，你每小時獲得10,000次點擊，物體壽命為2小時。 您可以輕松地咀嚼內存，這可能會影響性能，也可能導致事件過早地從緩存過期，從而導致其他問題。 只要你了解所有這些的影響，你就沒事了。

2）在Application_Start中啟動它並在Application_End中將其關閉就可以了。 您還可以使用http模塊實現自定義HttpApplication。

3）是的，當你的應用程序池被回收時，它調用Application_End，一切都被關閉並銷毀。

4）（線程）線程的問題與縮放有關。 如果你點擊default.aspx頁面，它會激活一個線程，並且該頁面在2分鍾內達到10,000，你可能會在你的應用程序池中運行大量的線程。 同樣，只要您了解啟動線程的后果，您就可以做到。 ThreadPool是另一個故事，asp.net運行時使用ThreadPool來處理請求，因此如果你占用所有線程池線程，你的應用程序可能會掛起，因為沒有可用於處理請求的線程。

Answer 2

所以這是你要記住的主要內容。 在您工作時，IIS可能會重置或自行重置（基於標准）。 除非在等待響應時停止呈現頁面，否則您永遠不會知道何時會發生這種情況（在這種情況下，您將獲得瀏覽器通知頁面停止響應，最終。

主題

這就是您不應該在ASP.NET應用程序中使用線程的原因。 但是，這並不是說你不能。 再一次，你需要正確配置IIS引擎（我在生成大量線程時已經將它掛起，但這可能與機器有關）。 如果您可以相信沒有人會讓ASP.NET重新編譯您的代碼/重新啟動您的應用程序（例如，通過保存 web.config ），那么您將遇到的問題比您可能沒有的那么少。

您可以使用也在IIS / .NET上運行的ASMX或WCF服務，而不是運行Windows服務。 隨你（由你決定。 但是對於多個服務池，它允許您在安裝和構建方面保持“在相同環境中”的所有內容。 他們顯然不共享相同的processpool / memoryspace。

“你錯了！”

我相信有人會讀到這個並且去“但是你無法在ASP.NET中進行操作!!!” 所以這里的鏈接向您展示如何從古老的MSDN中進行操作http://msdn.microsoft.com/en-us/magazine/cc164128.aspx

現在進入Long life對象/緩存

高速緩存

所以它取決於緩存的含義。 這是每個用戶，每個系統，每個應用程序，每個數據庫還是每頁？ 每種都是可能的，但根據需要需要一些設計和復雜性。

每頁最簡單的方法是使用靜態變量。 如果您將其用於用戶代碼內容，這也是非常危險的，因為如果有多個用戶使用該頁面，則無法向最終用戶表明該變量將會發生變化。 相反，如果你需要某些東西與用戶一起生活，特別是你可以將它填入會話（服務器端緩存，留在用戶，他們可以在多個頁面中使用它），或者你可以將它插入到ViewState中。

您在上面引用的緩存管理器適用於應用程序樣式緩存，其中使用webapp的每個人都可以使用相同的數據存儲。 對於您希望盡快恢復值的密集查詢，這可能是有益的，只要它們不是陳舊的。 這取決於你自己決定。 此外，如果您使用數據庫層進行存儲，那么應用程序設置等內容也可以存儲在那里。

長期緩存對象

您可以在app_start中初始化它沒有任何問題，如果您覺得有必要，也可以在最后銷毀它，但是，您需要注意我最初描述的關於系統拋出所有代碼的內容並重新啟動。

龍骨過度死亡

但是當你（這里的應用程序池）重新啟動時（據我所知），你不會得到通知，所以你可以在任何事情上喋喋不休。 始終假設應用程序會在您請求之前拒絕您，並且每個請求都是第一個請求。

真的，這只是首先回到網頁設計。 您不知道這是第一個訪問者還是第五個百萬分之一（除非您當然將這些信息存儲在內存中）所以就像應用程序是無狀態的一樣，您還需要將您的體系結構規划為盡可能無狀態。 這就是網絡應用程序很棒的地方。

如果您需要定期報告狀態，請考慮堅持使用桌面應用。 如果您可以忍受無狀態，歡迎使用ASP.NET和Web開發。

Answer 3

1）我是否需要考慮我想要緩存的對象的設計考慮因素？

2）如果我想在Web應用程序的生命周期中實現一段時間的管理器（顯然是線程安全的），是否足以在app_start期間初始化它並在app_end中將其終止？ 或者這是不受歡迎的，並且任何管理器都是在所服務頁面的構造函數/ init方法中唯一創建的。

數據緩存和輸出緩存之間存在差異。 我認為你正在尋找數據緩存，這意味着緩存一些對象以便在應用程序中使用。 這可以通過HttpContext.Current.Cache完成。 您還可以緩存頁面輸出並在條件上區分它，以便頁面邏輯根本不必運行。 此功能也內置於ASP.NET中。 在進行數據緩存時要記住的一點是，您需要注意緩存的內容的范圍。 例如，在使用Entity Framework時，您可能想要緩存從DB檢索到的某個對象。 但是，如果您的數據庫上下文是每個請求的范圍（對於訪問您站點的每個用戶來說都是一個新的，可能是正確的方法），那么您的緩存對象將依賴此DB上下文進行延遲加載，但是DB Context將在第一個之后被處理掉請求結束。

3）如果我在應用程序啟動時初始化了一個長期對象，那么當應用程序池被回收時，這可能會受到影響嗎？ 如果它在應用程序端被破壞，它只是被破壞然后再次重新創建的情況？ 我很滿意這個限制，我只想更清楚:)

在ASP.NET中使用線程的最大問題可能是它在與您的所有請求相同的進程中運行。 即使這本身不是問題，也可以配置IIS（如果您不擁有服務器，幾乎肯定會配置），關閉應用程序，如果它處於非活動狀態（您提到）可能會導致問題對於這些線程。 我已經看到了解決方案，包括確保IIS永遠不會回收應用程序池，以產生一個線程，即使在托管服務器上也可以使網站保持活動狀態