記得數年前，當ASP.NET剛出現時，天下間Web開發框架中似乎出現了一個“巨人”，WebForms這種似 乎人人都能掌握的開發框架幾乎瞬間流行起來。如果誰還在用傳統ASP這種控制與表現混合的開發方式， 似乎立即變得低俗了許多。於是乎許許多多人都學會了拖控件+綁定的方式，“Web開發人員”也越來越多 ，一片紅火，好不熱鬧。
風水輪流轉，不知從什麼時候開始Rails框架隨著RoR忽的流行了開來，.NET社區也出現了Monorail， 批判WebForms聲音也慢慢多了起來。如今微軟自己也推出了基於ASP.NET平台的MVC框架，很多WebForms的 反對者似乎更加自信了：連微軟自己都拋棄了WebForms，證明WebForms的確該退出歷史舞台了，也聽到了 一些類似於“WebForms不適合Web開發已經是公認的事實”這樣“無比肯定”的話。先不說微軟推出MVC到 底是不是意味著它拋棄了WebForms，單從那些MVC追捧者們“念念不忘”的WebForms的缺點上來看，我認 為他們大部分只是在“跟風”，就和當年許許多多人追捧WebForms一樣。
不過我必須承認，我對ASP.NET MVC的了解僅限於Scott Gu博客上所寫的內容，至今還沒有下載過 ASP.NET 3.5 Extensions CTP。而對於RoR和Monorail也僅限於一些資料和示例，從來沒有寫過一行代碼 。按照我的“標准”，我自己是沒有資格評論MVC框架的優劣的。不過我還是想寫這篇文章，因為我只會 WebForms平反，而不會“貶低”MVC框架；我只是想證明WebForms的那些缺點到底真的是缺點，還是開發 人員自身沒有好好利用起這把利器。因此我將會根據我的經驗，一一回應對WebForms比較常見的指責。如 果措辭上有任何的不妥，也請大家多多包涵。
我下面提到的做法，都是在經過實際開發過程檢驗的（例如開發人員與美工的合作），可能不是最佳 ，但是我認為還是不錯的。
一、ViewState
HTTP是無連接無狀態的協議，因此ASP.NET中提出了ViewState的概念，這樣數據被重新Post回頁面時 ，頁面（控件）的狀態就能恢復，因此才有了很多豐富的功能，例如一些復雜的控件事件。但是 ViewState帶來的問題就是，如果使用不當，那麼頁面體積就會增加許多，網絡中傳輸的數據太多自然會 影響性能。
但是ViewState真是必須的嗎？我可以很負責任地說，在如今大部分Web應用的頁面中，出現的幾乎都 是大量的鏈接，點擊鏈接就會跳轉到一個和當前頁面完全無關的新頁面，這樣的話，頁面上的ViewState 又有什麼用？因此我如果新建一個Web項目，做的第一件事情就是去Web.config中將enableViewState從全 局關閉——同時關閉的還有enableSessionState，這也是影響性能的因素之一（stateless也便於做Web服 務器層面的負載均衡）。
有人曾經反駁我，關閉了ViewState，用WebForm還有什麼意義？我的答案是：意義多的很。WebForm提 供了控件模型，我能夠使用“人人都能看懂和編寫”的方式來設置或讀取一個文本框裡的值。我能輕松地 響應不同按鈕的事件來編寫觸發各種業務邏輯。這就是意義，WebForms的開發還是非常簡單而清晰的（在 一定程度上吧，不要“濫用”永遠是正確的）。
嗯？剛才不是說只有保持ViewState才能使用控件的事件嗎？沒有ViewState怎麼從控件中重新獲取狀 態呢？請注意我之前所說的是“復雜事件”。什麼是復雜事件？TextBox的TextChange事件就是“復雜事 件”，GridView的Command事件也是復雜事件，但是Button的Click事件就是“簡單事件”；與此相對的， GridView裡的每一行的數據每一個子控件的狀態是“復雜狀態”，而TextBox的Text屬性則是“簡單狀態 ”。“復雜狀態”和“復雜事件”需要ViewState，因為與之有關的這些“控件”是ASP.NET“無中生有” 的，但是“簡單事件”和“簡單狀態”基於頁面中“必然”會提交的數據，它們自然能夠還能夠使用。在 我的ASP.NET開發過程中，使用的幾乎都是“簡單事件”和“簡單狀態”，而印象中放棄“復雜事件”和 “復雜狀態”並沒有給我帶來任何的困擾。
當某人送給我們10件禮物，而其中只有4件是我需要的，那麼為什麼不能簡單地放棄其余6件，偏偏要 去感謝只送給我們3件禮物的人而去指責前者呢？要知道他並沒有惡意，那多余的6件也沒有給我們造成任 何困擾。
但人就是那麼奇怪。
