基于軟件測試開發技術.NET的Web應用框架構建模式

基于軟件測試開發技術.NET的Web應用框架構建模式 NET網站架構

關鍵字：.NET Web應用框架

　　本文對應于Web表示模式集群，文章的前半部分重筆墨的描述了MVC模式的架構、設計及其ASP.NET實現，而在更加復雜的系統中，隨后提出了Page Controller(頁面控制器)和Front Controller(前端控制器)作為MVC實現的補充，最后，簡要介紹了Web表示模式集群的另外兩個模式：Intercepting Filter(篩選器)和Page Cache(頁面緩存)模式。

　　軟件開發網

　　“體系結構設計者的第一個作品往往比較簡練和干凈。他知道自己并不了解正在進行的工作，因此他小心謹慎地設計它。在他設計第一個作品時，會進行多次修飾和潤色。這些會留到“下一次”使用……這第二個系統是他曾經設計的最危險的系統……一般趨勢是，在設計第二個系統時，將會使用在第一個作品中被小心擱置在一邊的所有思路和修飾，從而導致設計過了頭?！?/P>

　　—Frederick P. Brooks, Jr.發表于1972年的The Mythical Man Month(人月神話)。

　　Web上建立的第一個系統是簡單地鏈接在一起的靜態HTML頁面，以便在分散的小組之間共享文檔。隨著用戶的使用量增加，可響應用戶輸入的動態網頁日益普遍。早期的動態頁面一般是以通用網關接口(CGI)腳本的形式編寫的。這些CGI腳本不僅包含用來確定在響應用戶輸入時應當顯示什么內容的業務邏輯，而且還會生成表示HTML。隨著對更復雜邏輯需求的增加，對更豐富、更生動的表示形式的需求也隨之增加。這種增加了的復雜性給CGI編程模型帶來了挑戰。

　　不久，基于頁面的開發手段(如ASP和JSP)出現了。這些新方法允許開發人員將腳本直接嵌入到HTML面中，從而簡化了編程模型。當這些嵌入的腳本應用程序變得更復雜時，開發人員希望在頁面級別將業務邏輯與表示邏輯分開。為適應這一要求，隨之出現了具有幫助器對象和代碼隱藏頁面策略的標記庫。然后，又出現了提供動態配置站點導航和命令調度程序的精細框架，但所有這一切都是以增加復雜性為代價的。假設現在有大量的Web表示可選方案，如何為您的應用程序選擇適當的Web表示設計策略?

　　是否真的有一個設計策略能夠適應所有的情況?很不幸，在軟件設計中，消除過多的冗余和過度的復雜性是一個競爭性需求，很難能夠真正做到兩者之間的平衡。您可以從包含嵌入腳本的簡單頁面開始設計工作，但很快業務邏輯就會不斷重復出現在各個文件中，從而導致系統難以維護和擴展。通過將該邏輯移到一組協作組件中，可以消除冗余，但是這樣做會增加解決方案的復雜性。另一方面，您的設計工作可以從設計用來提供標記庫、動態配置和命令調度程序的框架入手，可是這樣雖然能夠消除冗余代碼，但它會大大增加系統的復雜性，而這通常是不必要的。

　　而如何考慮各個方面的需求，提出一個最合適我們應用的Web表示策略呢?這需要在復雜解決方案(支持將來可能發生變化的情形)和簡單解決方案(滿足目前的要求)之間做出抉擇，原則上適當增加成本是可取的，而過多增加成本卻是不可取的。那么廢話少說，我們就從“簡單”開始吧。

　　MVC(模型—視圖—控制)

　　許多計算機系統的用途都是從數據存儲檢索數據并將其顯示給用戶。在用戶更改數據之后，系統再將更新內容存儲到數據存儲中。因為關鍵的信息流發生在數據存儲和用戶界面之間，所以您可能傾向于將這兩部分綁在一起，以減少編碼量并提高應用程序性能。但是，這種看起來自然而然的方法有一些大問題。一個問題是，用戶界面的更改往往比數據存儲系統的更改頻繁得多。將數據和用戶界面這兩部分耦合在一起帶來的另一個問題是，業務應用程序往往會并入遠不止數據傳輸功能的其他業務邏輯。如何讓Web應用程序的用戶界面功能實現模塊化，以便您可以輕松地單獨修改各個部分?

　　Model-View-Controller正是這樣的模式，它實現功能模塊和顯示模塊的分離，使得應用程序更加可維護，可擴展，可移植和可復用，它最初是Trygve Reenskaug在二十世紀七十年代末為Smalltalk平臺開發的框架[Fowler03]，而發展到目前為止，已經形成了一個非常成熟的模式。

原文轉自：http://www.anti-gravitydesign.com