作者 Jonathan Allen譯者 趙劼 發布於 2007年12月10日 下午9時35分
Rick Strahl在他對ASP.Net平台下的Web Form和MVC框架的觀察中首先談到了Web Forms的強大之處。他提到，Web Forms已經被證明是一個非常穩定和成熟的平台。即使在性能要求非常高的情況下，它也不太會出現擴展方面的問題。同時，Rick還認為從Web Froms入門web開發是一件非常容易的事情。
微軟設計了一個完整web開發環境，使得構建Web應用有了新的體驗，開發人員只需在一個可視化設計器中拖放控件、並且在表單中 設置屬性即可。與此同時，開發人員可以編寫代碼來響應事件，這使得對於程序邏輯的操作變得非常直觀，就好像並非在開發一個Web應用一樣。Web Forms模型提供了一個高度抽象的框架，使得入門變得非常容易。但是它也容易造成一些問題，因為它在很多方面將開發人員和低端的Web機制隔離開來。我 稍候將回過來再談一下這個次要的問題。
他在總結中談到，這個框架有著非常強大的擴展能力，並且肯定了它對自定義控件這一產業所做出的貢獻（可能ASP.Net控件廠商比其他平台下的總和還要多）。
對“高度抽象”進行了褒揚之後，Rick開始闡述它的缺點。
這既是一種幸運也是一個禍根。Web Forms讓開發人員能夠輕松地拖放控件，並且通過響應頁面和控件的各種事件來快速開發Web應用。這一點很不錯，但是首先這種高度的抽象使很多開發人員 完全忽略了——甚至從沒有了解過在這背後HTML是如何運作的。這往往會產生無法通過校驗的HTML代碼，或者是一些非常冗余，難以管理的Html布局， 這對於頁面設計人員非常不友好。同時，如果沒有合理控制ViewState的話，你很容易得到一個包含大量VIEwState的頁面，它的尺寸遠遠超過所 需的內容，最終使得頁面打開異常緩慢。
Web Forms框架的缺點之一，就是微軟在這個抽象背後構建了一個非常復雜的引擎，它給頁面的執行過程帶來了許多的負面效應。如果你曾經構建過包含大量組件的 復雜頁面，就會發現某些時候要協調好數據綁定，頁面生成等事件的順序，並且在頁面的生命周期中選擇恰當的時間來設置不同的控件是一件非常困難的事情。你是 否曾經在Init、Load或者PreRender事件中加載過數據？你是否在PostBack事件中進行過賦值？Web Forms需要服務器端的一個獨立的表單中進行操作，因此你可能無法輕易地將它分解成小的邏輯單元。在一些復雜情況下，事件處理程序會變得非常龐大，你很 難對它們的工作進行重構，最終你會得到許多難以維護的代碼，並且幾乎無法進行測試。
他繼續詳細討論了VIEwState，事件管理和PostBack機制的問題。對於這些內容還沒有做到了如指掌的ASP.Net開發人員應該通過文章內容再努力學習一下。
有個問題可能會使非.Net平台的開發人員感到非常驚訝：我們很難在設計期間就確定一個控件的ID。由於文檔中少有提及的命名容器鏈（Naming Container Chain）存在一定的缺陷，我們只有在運行時期才能知道“txtPassword”控件最終會獲得一個形如 “PublicSiteTemplate1_ctl00_txtPassWord”的ID。而在使用其它技術開發的普通頁面中，這應該是一個相對較短的 ID。
含糊不清的控件ID以及ViewState對於如今的Web 2.0站點來說都是嚴重的問題。唯一不會受到VIEwState帶來的負面影響的框架是ASP.Net AJax，但這還是一個不成熟的類庫。
