按照我們編寫webform一般的習慣，首先在頁面上拖放乙個dropdownlist、乙個datagrid、乙個button控制項：
介面（webform.aspx）：
執行結果如圖所示，程式將根據下拉列表框選擇的值繫結datagrid，非常典型的乙個webform架構，體現出asp.net事件驅動的思想，實現了介面與**的分離。但是仔細看看可以從中發現幾個問題：
? 對資料庫操作的**重複，重複**是軟體開發中絕對的「壞味道」，往往由於某些原因當你修改了一處**，卻忘記要更改另外一處相同的**，從而給程式留下了bug的隱患。
? 後置**完全依賴於介面，在webform下介面的變化遠遠大於資料儲存結構和訪問的變化，當介面改變時您將不得不修改**以適應新的頁面，有可能將會重寫整個後置**。
? 後置**不僅處理使用者的輸入而且還負責了資料的處理，如果需求發生變更，比如需要改變資料的處理方式，那麼你將幾乎重寫整個後置**。
乙個優秀的設計需要每乙個模組，每一種方法只專注於做一件事，這樣的結構才清晰，易修改，畢竟專案的需求總是在不斷變更的，「唯一不變的就是變化本身」，好的程式一定要為變化作出準備，避免「牽一髮而動全身」，所以一定要想辦法解決上述問題，下面讓我們來看看設計模式。
設計模式
設計模式描述了乙個不斷重複出現的問題以及對該問題的核心解決方案，它是成功的構架、設計及實施方案，是經驗的總結。設計模式的概念最早來自於西方建築學，但最成功的案例首推中國古代的「三十六計」。
mvc模式下的webform
mvc模式是乙個用於將使用者介面邏輯與業務邏輯分離開來的基礎設計模式，它將資料處理、介面以及使用者的行為控制分為：model－view－controller。
? model：負責當前應用的資料獲取與變更及相關的業務邏輯
? view：負責顯示資訊
? controller：負責收集轉化使用者的輸入
傳統的webform一般繼承自system.web.ui.page類，而page controller的實現思想是所有的webform繼承自定義頁面基類，如圖：
利用自定義頁面基類，我們可以統一的接收頁面請求、提取所有相關資料、呼叫對model的所有更新以及向view**請求，輕鬆實現統一的頁面風格，而由它所派生的controller的邏輯將變得更簡單，更具體。
下面看一下page controller的具體實現：
page controller（basepage.cs）：public class basepage : system.web.ui.pageset}public dataset getportaldatasource()public dataset getsubjectdatasource( string portalid )protected override void render( htmltextwriter writer )}
現在它封裝了model的功能，實現了統一的頁面標題和頁尾，子類只須直接呼叫：
修改後的controller（webform.aspx.cs）：
public class webform : basepage//繼承頁面基類}private void button_click(object sender, system.eventargs e)}
從上可以看出bagepage controller接管了大部分原來controller的工作，使controller變得更簡單，更容易修改（為了便於講解我沒有把控制項放在basepage中，但是您完全可以那樣做），但是隨著應用複雜度的上公升，使用者需求的變化，我們很容易會將不同的頁面型別分組成不同的基類，造成過深的繼承樹；又例如對於乙個購物車程式，需要預定義好頁面路徑；對於嚮導程式來說路徑是動態的（事先並不知道使用者的選擇）。
面對以上這些應用來說僅僅使用page controller還是不夠的，接下來再看看front controller模式。
front controller模式下的webform
page controller的實現需要在基類中為頁面的公共部分建立**，但是隨著時間的推移，需求會發生較大的改變，有時不得不增加非公用的**，這樣基類就會不斷增大，您可能會建立更深的繼承層次結構以刪除條件邏輯，這樣一來我們很難對它進行重構，因此需要更進一步對page controller進行研究。
front controller通過對所有請求的控制並傳輸解決了在page controller中存在的分散化處理的問題，它分為handler和command樹兩個部分，handler處理所有公共的邏輯，接收http post或get請求以及相關的引數並根據輸入的引數選擇正確的命令物件，然後將控制權傳遞到command物件，由其完成後面的操作，在這裡我們將使用到command模式。
command模式通過將請求本身變成乙個物件可向未指定的應用物件提出請求，這個物件可被儲存並像其他的物件一樣被傳遞，此模式的關鍵是乙個抽象的command類，它定義了乙個執行操作的介面，最簡單的形式是乙個抽象的execute操作，具體的command子類將接收者作為其乙個例項變數，並實現execute操作，指定接收者採取的動作，而接收者具有執行該請求所需的具體資訊。
因為front controller模式要比上面兩個模式複雜一些，我們再來看看例子的類圖：
關於handler的原理請查閱msdn，在這就不多講了，我們來看看front controller模式的具體實現：
首先在web.config裡定義：
。。。
設計模式領悟之 原型設計模式
用原型例項指定建立物件的種類，並且通過拷貝這些原型建立新的物件。ps 當我們需要建立大量相同物件的時候，就可以用原型模式大批量複製物件。和現實生活中 的影印機相似，通過乙個原型 模板 批量複製相同的物件 複製需要用到memberwiseclone 方法 1，淺複製 如果欄位是值型別的，則對該字段進行...
web 設計模式
value object模式 高效的物件應該像整型那樣運作 如果你把同乙個物件資源賦值給兩個不同的變數，然後改變其中的乙個變數，另乙個變數仍然不受影響。事實 上，這就是value object模式的目標所在。物件和物件指標 工廠模式 在物件導向程式設計中,最通常的方法是乙個new操作符產生乙個物件例...
WEB設計模式
value object模式 高效的物件應該像整型那樣運作 如果你把同乙個物件資源賦值給兩個不同的變數，然後改變其中的乙個變數，另乙個變數仍然不受影響。事實 上，這就是value object模式的目標所在。物件和物件指標 工廠模式 在物件導向程式設計中,最通常的方法是乙個new操作符產生乙個物件例...