2009-07-23 37 views
15

有6種技術來管理ASP.NET 3.5中的狀態(據我所知)。ASP.NET狀態管理在適當的情況下

(1) View State 
(2) Cross Page Posting 
(3) Query String 
(4) Session State 
(5) Application State 
(6) Cookies 

任何人都可以給我一些適當的例子,我應該使用這些技術?

例如:

(*) Session State: Personalization, Buy Cart, etc. 
(*) Cookies: Saving User Credentials, etc. 

回答

5

國家管理選項

視圖狀態:

使用,當你需要存儲少量的信息頁面將回發到自身。使用ViewState屬性提供了具有基本安全性的功能。

控制狀態:

使用,當你需要存儲少量的狀態信息往返於服務器之間的控制。

隱藏字段:

使用,當你需要存儲少量的信息頁面將回發到自身或到另一個頁面,而當安全不是問題。

只能在提交給服務器的頁面上使用隱藏字段。

餅乾:

使用,當你需要存儲少量的客戶端和安全性上的信息是不是一個問題。

查詢字符串:當你從一個頁面少量的信息轉移到另一和安全不是問題

使用。

只有當您通過鏈接請求同一頁面或另一頁面時,纔可以使用查詢字符串。

服務器端管理選項

應用狀態時,你存儲所使用的許多用戶經常更改,全球信息和安全性是不是一個問題

使用。不要在應用程序狀態下存儲大量信息。

會話狀態

當你存儲短命信息的使用特定於單個會話和安全性是一個問題。不要在會話狀態下存儲大量信息。請注意,將在應用程序中的每個會話的生存期內創建和維護會話狀態對象。在託管許多用戶的應用程序中,這會佔用大量的服務器資源並影響可伸縮性。

配置文件屬性

使用,當你存儲需要在用戶會話過期被持久化,需要在你的應用程序的後續訪問再次檢索用戶特定的信息。

數據庫支持

當你存儲大量的信息,管理事務,或信息必須經受得住應用和會話使用重新啓動。數據挖掘是一個問題,安全性是一個問題。

+0

有關更多詳細信息,請訪問http://coscientech.blogspot.com或http://msdn.microsoft.com/en-us/library/z1hkazw7.aspx – xxxxxxxxxadfas 2010-09-23 07:46:41

15

有很多可以影響這個因素,所以我不會對所有的人發表意見。但這裏有幾個要點:

  • ViewState - 當你將發佈回到同一頁面頻繁(東西你幾乎被迫通過ASP.Net Web表單做),這非常有用。取決於您正在構建的應用程序類型,它的確切變化有多大用處。對於公共互聯網網站,應該非常謹慎地使用它。您甚至可能希望在默認情況下關閉它。對於本地Intranet網站,這是一個很好的工具,特別是對於較少,較重的網頁表單頁面。

  • Query String - 使用此選項可以存儲您需要允許用戶爲頁面或進程添加書籤並在稍後返回的狀態。即使這樣,你也可能希望把它保留在某種散列中,你可以在數據庫查找中用它作爲關鍵字,以避免一個真正巨大的url(儘管散列有它們自己的問題)。另外,很多用戶都喜歡直接擺弄查詢字符串,因此在這裏放置太多可能會很危險。不小心將數據暴露給不應該以這種方式看到它的用戶。

  • Application State - 請記住,這是所有用戶共享的,所以請適當使用。像查看計數這樣的事情可以在這裏。

  • Cookies - 不要使用cookie來存儲用戶憑證。他們只是普通的未加密文本文件。使用cookie將密鑰存儲到會話中(即使在這裏您可以並且現在應該使用無cookie會話)以及將針對該用戶和瀏覽器的簡單個性化設置。例如,我工作時的顯示器尺寸與家庭不同,因此將顯示器尺寸/佈局設置放入Cookie是很好的,因爲這些設置適用於每臺計算機,但如果其他人讀取該設置,則不會損害我的安全性信息。

現在我想從「查詢字符串」部分強調這個概念:

你可能要保持它歸結爲某種哈希的,你可以在一個數據庫作爲重點使用查找

此外,哈希有自己的問題,但我想指出的是,在我的名單談幾個項目(包括查詢字符串)關於從客戶端的Web瀏覽器將數據上傳到網絡服務器:ViewState中,查詢字符串,Cookie和Cross-Page Post。您希望最小化您從客戶端移動到服務器的數據。這個概念適用於所有這些,並有以下幾個原因:

  1. 從客戶端拉動數據公共互聯網網站。即使寬帶連接通常會削弱可用於上傳的帶寬。與可能位於數據庫和Web服務器之間的千兆以太網(或更快)連接相比,512Kpbs(在許多地區仍是典型的寬帶上傳速率)爲沒有任何。儘管您可能認爲數據庫查詢速度很慢(現在也是如此),但它仍然可能是一個更好的方式,而不是等待來自客戶端的相同數據。
  2. 將數據保存在服務器上更便宜,因爲您不需要支付將數據發送到客戶端或從客戶端發送出去所需的帶寬,並且帶寬的成本通常比服務器硬件的成本高。
  3. 它更安全,因爲即使當客戶端的計算機或連接受到威脅時,所有黑客最初都可以訪問的哈希鍵可能會在其解密時到期。當然,如果做錯了,他可以直接使用該鍵,所以你仍然需要小心。

因此,對於大多數情況,我推薦的做法是先在Session中保留一個數據庫密鑰,然後讓代碼輕鬆從基於該密鑰的數據庫中提取所需的代碼。當您遇到瓶頸時,配置文件找出它們的位置並開始緩存這些頁面或控件,或直接在會話中保留該數據/查詢結果。

1

不知道您的意思是應用程序狀態下的緩存對象。

Cache對象是管理應用程序廣泛狀態的好方法,例如,記錄源和訪問您的網站(例如防止DDOS攻擊)。

+0

緩存對象是存儲靜態數據(或者變化不大但被應用程序引用的任何數據)的好地方,可以防止每次都從數據庫或文件系統讀取數據。 – Keith 2009-07-23 12:59:36

1

(3)查詢字符串 (4)會話狀態 (5)應用程序狀態 (6)餅乾

1.視圖狀態

  • 聲明:使用盡可能少。好的一點是總是如果可能的話,每個狀態都可以通過一個url訪問。
    • F.e.分頁應使用URL(因此/url/?p=2代替在Viewstate中存儲頁面)
  • 用於在頁面循環之間保持控制狀態。
    • F.e.將選中的項目存儲在複選框中,以便確定它是否已更改。

2.跨頁投遞

不要。查看viewstate的免責聲明。使用此URL,或將數據存儲在會話/ cookie /配置文件中,如果需要保留大量屬性。

CPP的主要缺點是用戶無法在其瀏覽器中使用「後退」和「前進」按鈕。當用戶點擊後退按鈕時,它想撤銷該頁面上的所有內容,然後重試最後一個。使用CPP通過嚮導單擊它們時;如果沒有很多「你確定要重新發送blablablabl」,這種行爲是不可能的。

3。查詢字符串

使用很多。網頁可以訪問的每個可見狀態都應該可以通過URL訪問。有屏幕閱讀器的人會爲此感謝你。通過使用查詢字符串,不需要使用純JavaScript解決方案。

/url/?page=2 // when doing paging, don't use postback for this 
/url/?tab=advanced-search // when having tabs on top of your page 

4.會話狀態

使用此短生命的物體,那纔有意義時間訪問者訪問您的網站。例如:

  • 這一定向導的步驟達成
  • 網頁用戶訪問了你想要把緩存之前
  • 小物件,但有用戶綁定

不要使用會話,但是配置文件之類的東西:

  • 精選語言

因爲這些事情在下次用戶訪問您的網站時也有意義。

5.應用程序狀態

從不。使用ASP.NET緩存或memcached,或任何緩存框架。

6.餅乾

會話ID,對通過認證的用戶的配置文件ID;匿名用戶的用戶首選項(在第二個列表中列出的所有內容)。