介紹ASP.NET頁(yè)面生命周期
ASP.NET頁(yè)面生命周期
在面對(duì)此類問(wèn)題的時(shí)候，首先問(wèn)問(wèn)自己控件的數(shù)量，如果數(shù)量不多，直接通過(guò)設(shè)置控件的Visible屬性解決問(wèn)題就是了。這也就是說(shuō)，把可能要顯示的控件都聲明為Visible="false"，然后在代碼中判斷當(dāng)前應(yīng)該將哪個(gè)顯示出來(lái)。
如果控件比較多，然而還是能分組的，同一時(shí)間僅僅顯示其中的一組，那么你應(yīng)該考慮使用MultiView，這樣你的工作將會(huì)輕松不少。事實(shí)上，能夠使用 MultiView解決的，都應(yīng)該優(yōu)先考慮使用MultiView解決，這比起自己控制哪一個(gè)控件顯示哪一個(gè)控件隱藏要方便多了。其實(shí)MultiView 所做的，也就是幫你控制控件的顯示與隱藏。
這樣做的性能如何呢？我們關(guān)注兩方面的問(wèn)題，一方面是服務(wù)器端執(zhí)行的資源消耗，另一方面是傳輸?shù)膸捪?。我們先?lái)看看服務(wù)器端執(zhí)行的資源消耗吧，我們最常見(jiàn)的消耗應(yīng)該就是數(shù)據(jù)控件操作數(shù)據(jù)庫(kù)時(shí)的消耗了。在ASP.NET 1.x時(shí)代，我們沒(méi)有數(shù)據(jù)源控件，所以必須手動(dòng)進(jìn)行DataBind()，這也就是說(shuō)如果不手動(dòng)執(zhí)行DataBind()的話就不會(huì)進(jìn)行任何數(shù)據(jù)操作，因此只要我們記得在數(shù)據(jù)控件不顯示的時(shí)候也不要讓它執(zhí)行DataBind()就是了，那樣就不會(huì)有性能損失。在ASP.NET 2.0當(dāng)中，使用數(shù)據(jù)源控件的話數(shù)據(jù)控件是會(huì)自動(dòng)DataBind()的，這時(shí)候會(huì)造成控件隱藏時(shí)的資源消耗呢？事實(shí)上是不會(huì)的，數(shù)據(jù)控件即使已經(jīng)定義了 DataSourceID屬性，它也僅僅在自己***次可見(jiàn)時(shí)才進(jìn)行自動(dòng)DataBind()。如果數(shù)據(jù)控件的狀態(tài)是隱藏的（包括使用MultiView隱藏），它就不會(huì)自動(dòng)進(jìn)行DataBind()。因此，在ASP.NET 2.0中使用數(shù)據(jù)源控件以及MultiView之后其底層過(guò)程還是和ASP.NET 1.x手動(dòng)操作的一樣，就是少寫一些代碼而已。
我們接著來(lái)看看帶寬消耗如何，因?yàn)殡[藏的控件不輸出任何的HTML，因此帶寬消耗就是指ViewState了。控件隱藏后，ViewState是不變的，因此隱藏控件確實(shí)比完全不加載控件造成了更多的資源消耗，換取的是該控件的狀態(tài)得以保存。一般來(lái)說(shuō)，簡(jiǎn)單控件隱藏后多出來(lái)幾十字節(jié)的ViewState是可以忽略不計(jì)的，整個(gè)頁(yè)面中HTML縮進(jìn)所需的空格也都幾十上百字節(jié)了；但如果是復(fù)雜控件，擁有大量的ViewState，這時(shí)候你真的應(yīng)該考慮動(dòng)態(tài)加載了。
總的來(lái)說(shuō)，面對(duì)這類問(wèn)題時(shí)首先判斷顯示隱藏控件的邏輯是否復(fù)雜，控件本身是否復(fù)雜。如果是比較簡(jiǎn)單的情況，則直接使用 MultiView解決就是了。如果是復(fù)雜的情況，那就應(yīng)該考慮自己使用控件將此邏輯封裝在內(nèi)，而不是直接在頁(yè)面上暴露這些復(fù)雜性。關(guān)于封裝控件的問(wèn)題，在下一篇文章中再討論，因此我們繼續(xù)看下一類問(wèn)題。
既不確定類型也不確定數(shù)量的控件
有時(shí)候我們面對(duì)前面兩類問(wèn)題都有清晰的思路，但是面對(duì)復(fù)合問(wèn)題就感覺(jué)很混亂了。例如還是一個(gè)調(diào)查問(wèn)卷的顯示，數(shù)據(jù)來(lái)自XML，問(wèn)題類型包括單選和多選，每一道問(wèn)題的選項(xiàng)個(gè)數(shù)也不確定，這時(shí)候怎么辦呢？foreach嵌套foreach，外層迭代問(wèn)題內(nèi)層迭代選項(xiàng)，逐個(gè)CheckBox/RadioButton來(lái)生成？
這時(shí)候我們需要的是把問(wèn)題分而治之逐個(gè)擊破的思想。既然是上述兩類問(wèn)題的嵌套，我們就應(yīng)該能夠通過(guò)嵌套對(duì)應(yīng)的解決方案來(lái)實(shí)現(xiàn)。對(duì)于這個(gè)調(diào)查問(wèn)卷的例子，我們可以用Repeater來(lái)迭代問(wèn)題，先把這個(gè)定下來(lái)，再考慮模板里面怎么做。模板里面需要顯示的是一個(gè)不確定類型的問(wèn)題，因此模板里面放一個(gè) MutliView，把問(wèn)題類型的表達(dá)式綁定到其ActiveViewIndex屬性上，例如單選題就是0多選題就是1。然后MultiView里面的兩個(gè)View各自嵌套一個(gè)Repeater，第0個(gè)Repeater迭代選項(xiàng)并顯示為RadioButton，第1個(gè)Repeater迭代選項(xiàng)并顯示為 CheckBox。就這樣就完成了，我們沒(méi)寫任何一行后臺(tái)代碼，也沒(méi)有動(dòng)態(tài)創(chuàng)建任何控件。
然后我們來(lái)分析一下這個(gè)解決方案的性能。對(duì)比起動(dòng)態(tài)創(chuàng)建控件，它所使用的控件確實(shí)是多了一倍，因?yàn)橐坏绬?wèn)題同時(shí)創(chuàng)建了兩組選項(xiàng)，一組單選一組多選，只不過(guò)其中一組被隱藏了。然而隱藏掉的那一組唯一的服務(wù)器端資源消耗就是創(chuàng)建以及綁定，它們不輸出任何的HTML，因?yàn)樗鼈兊闹挡粫?huì)被改變所以也不會(huì)輸出任何的ViewState，并且它們也不會(huì)觸發(fā)任何事件，因此在對(duì)性能沒(méi)有特別要求的情況下這樣的性能損失還是可以接受的。至少，這比起你自己去研究ASP.NET頁(yè)面生命周期然后自己寫一大段代碼來(lái)實(shí)現(xiàn)動(dòng)態(tài)加載控件要好多了。
問(wèn)題與實(shí)驗(yàn)
本系列上一篇文章的問(wèn)題與實(shí)驗(yàn)一直沒(méi)有解答，現(xiàn)在給出參考答案如下：
1.為Page增加一個(gè)ShowCheckBox的屬性：
- bool ShowCheckBox {
- get { return (ViewState["ShowCheckBox"] == null) ?
false : (bool)ViewState["ShowCheckBox"]; }- set { ViewState["ShowCheckBox"] = value; }
- }
在OnLoad的時(shí)候檢測(cè)ShowCheckBox屬性，如果為true則添加上該CheckBox控件。在Button的 OnClick事件中，設(shè)置ShowCheckBox為true，并添加上CheckBox。記得這兩處創(chuàng)建的CheckBox必須擁有一致的ID屬性。
2. 這是為了讓ICallbackEventHandler的處理模型符合ASP.NET頁(yè)面生命周期的模型。雖然Callback發(fā)生的時(shí)候，ASP.NET頁(yè)面生命周期已經(jīng)與PostBack不同，然而ICallbackEventHandler還是讓Callback模仿了PostBack的頁(yè)面生命周期。RaiseCallbackEvent相當(dāng)于PostBack的Raise PostBackEvent階段，GetCallbackResult相當(dāng)于PostBack的PreRender階段。前者負(fù)責(zé)事件響應(yīng)，后者負(fù)責(zé)生成返回客戶端的HTML代碼。
這次想和大家討論的問(wèn)題是，你覺(jué)得你是***主義者嗎？面對(duì)上面的調(diào)查問(wèn)卷需求，你會(huì)選擇我所說(shuō)的Repeater套MultiView再套R(shí)epeater的做法，從而避免寫任何一行后臺(tái)代碼，還是會(huì)選擇自己封裝一個(gè)控件動(dòng)態(tài)創(chuàng)建所有控件，避免任何不必要的性能損失？
【編輯推薦】
