1、什麼是設計模式？
模式的了解
模式是一種解決問題的思路，而不是具體的做法。
設計模式的了解
在軟體開發領域，設計模式是為解決開發中某一類問題而提出的一種解決方案。是以，設計模式本質上是思想，而不是代碼。設計模式追求的思想上的複用，而不是代碼上的複用。
2、ASP.NET MVC概述
ASP.NET MVC是一種建構Web應用程式的架構，它将一般的MVC（Model-View-Controller）模式應用于ASP.NET架構。
MVC将Web應用程式劃分為三個主要的部分，以下是MSDN給出的定義：
模型（Model）：模型對象是實作應用程式資料域邏輯的應用程式部件。 通常，模型對象會檢索模型狀态并将其存儲在資料庫中。 例如，Product 對象可能會從資料庫中檢索資訊，操作該資訊，然後将更新的資訊寫回到 SQL Server 資料庫内的 Products 表中。
視圖（View）：視圖是顯示應用程式使用者界面 (UI) 的元件。 通常，此 UI 是用模型資料建立的。 Products 表的編輯視圖便是一個視圖示例，該視圖基于 Product 對象的目前狀态顯示文本框、下拉清單和複選框。
控制器（Controller）：控制器是處理使用者互動、使用模型并最終選擇要呈現的視圖來顯示 UI 的元件。 在 MVC 應用程式中，視圖僅顯示資訊；控制器則用于處理和響應使用者輸入和互動。 例如，控制器處理查詢字元串值，并将這些值傳遞給模型，而模型可能會使用這些值來查詢資料庫。
3、ASP.NET MVC的發展曆程
我們以一張時間軸線圖開始，了解一下ASP.NET MVC的發展曆程。
2007年2月，Microsoft公司的Scott Guthrie在旅途中草拟了ASP.NET MVC的核心程式。經過9個預覽版本，于2009年3月13日，正式釋出ASP.NETMVC1官方版本。
時隔一年，ASP.NETMVC2于2010年3月釋出，部分主要特征如下：
• 帶有自定義模闆的UI輔助程式
• 在用戶端和服務端基于特性的模型驗證
• 強類型的HTML輔助程式
• 改善的Visual Studio開發工具
• 支援将大型應用程式劃分為域
• 支援異步控制器
• 使用Html.RenderAction支援渲染網頁或網站的某一部分
• 新的輔助函數、使用工具和API增強
2011年1月，ASP.NET MVC3正式推出，部分主要特征如下：
• 支援Razor視圖引擎
• 支援.NET4資料注解
• 改進了模型驗證
• 提供更強的控制和更大的靈活性，支援依賴項解析(Dependency Resolution)和全局操作過濾器(Global Action Filter)
• 豐富的JavaScript支援，其中包括非侵入式JavaScript、jQuery驗證和JSON綁定
• 支援NuGet，可以用來釋出軟體，管理整個平台的依賴
2012年9月，ASP.NET MVC4正式釋出，新增功能主要包括：
• ASP.NET Web API
• 增強了預設的項目模闆
• 添加使用jQuery Mobile的手機項目模闆
• 支援顯示模式(Display Mode)
• 支援異步控制器的任務
• 捆綁和微小(minification)
2013年10月，ASP.NET MVC5與Visual Studio 2013一起釋出，下面列出了一些主要特征：
• One ASP.NET
• 新的Web項目體驗
• ASP.NETIdentity
• Bootstrap模闆
• 特性路由
• ASP.NET基架
• 身份驗證過濾器
• 過濾器重寫
4、建立ASP.NET MVC4應用程式
1、選擇“檔案”->“建立”->“項目”選項，如下圖所示：
2、在“建立項目”對話框左側的“已安裝”->“模闆”->“Visual C#”清單下，選中Web選項，選擇ASP.NET MVC4 Web應用程式，将應用程式命名為MyFirstMvcProject，點選“确定”按鈕，如下圖所示：
3、在彈出的“新ASP.NET 項目”對話框中，選中“基本”模闆，視圖引擎選擇“Razor”，同時将“建立單元測試項目”勾選上，點選“确定”按鈕，如下圖所示：
4、至此，一個新的MVC項目已經建立完成，如下圖所示：
5、ASP.NET MVC應用程式結構
新的MVC項目建立完成後，會自動向這個項目中建立一些目錄，下表介紹了這些目錄的主要用途。
目錄
用途
App_Data
用于存儲想要讀取/寫入的資料檔案
App_Start
用于儲存一些功能的配置代碼
Content
用于儲存CSS、圖像和其他站點内容
Controllers
用于儲存處理URL請求的控制器類
Models
用于儲存表示和操縱資料以及業務對象的類
Scripts
用于儲存JavaScript庫檔案和腳本
Views
用于儲存負責呈現輸出結果的UI模闆檔案
在預設情況下，ASP.NET MVC應用程式對約定的依賴性很強，這樣就避免了開發人員配置和指定一些項，因為這些項可以根據約定來推斷。這個概念通常被稱為“習慣優于配置（convention over configration）”。
ASP.NET MVC對于程式結構的約定如下：
1、每個Controller類的名字以Controller結尾，儲存在Controller目錄中。
2、應用程式的所有視圖放在單獨的Views目錄下。
3、控制器使用的視圖是在Views主目錄下的，與控制器名稱相同的子目錄中。
ASP.NET Webform 背景代碼（behind code）—— 福音與詛咒
我們已經在項目開發中使用過ASP.NETWebform技術，大家會發現它更接近可視化設計，換句話說，開發者隻需要從設計面闆中拖拽控件即可完成UI，接着在behindcode中實作邏輯代碼即可完成最後的Web頁面功能。
是以換句話說，當你從設計面闆中拖拽一個按鈕時，在背景代碼中就會生成一個button對象，你隻需要在按鈕的點選事件中實作事件響應代碼即可。
public partial class WebForm1 :System.Web.UI.Page
{
protected void Page_Load(object sender, EventArgs e)
{
// Developers write code here
}
protected void Button1_Click(object sender, EventArgs e)
}
當我們在頁面中拖拽一些UI元素時，輕按兩下它們即可在背景代碼中生成一系列事件響應代碼，這些邏輯代碼都在ASPX.CS檔案中。
這個背景代碼檔案是ASP.NETWebForm的關鍵，你可以在這個檔案中應用.NET的所有特性，包括事件、委托、HTTP協定以及Session等等。
但是這種behindcode模式有5個問題，下面我們将一一講述這5個問題，并用MVC的設計思想來分别解決這些問題。
問題1：基于視圖的方案來解決基于行為的需求
我們的網站最終是由使用者使用的，使用者通路網站肯定會有特定的目的，網站要做的就是通過讓使用者的互動行為來完成其想要的目的。比如當使用者通路一個購物網站時，也許他的互動行為會是這樣的：
· 購買産品
· 列印發票
這些互動行為是通過按鈕點選、右鍵點選和浏覽器URL實作的。由于這些互動都是基于HTTP協定的，是以如果我們能将這些互動行為映射到具體的一些方法上，那麼整個架構将會變得簡單很多。
但是微軟做不到這樣，因為它要實作可視化網頁程式設計，是以他們最終選擇了基于視圖的解決方案。
從上圖可以看出，整個請求過程看上去很奇怪：
· 使用者發起一個HTTP請求，比如HTTPPOST / GET
· IIS伺服器将請求映射到視圖
· 視圖調用頁面的生命周期，通過事件驅動，調用合适的互動方法
· 最後将互動的結果展現給終端使用者
因為微軟一開始就選擇了基于視圖的設計方案，是以架構本身很難向基于使用者互動的設計思想靠攏。換句話說，當使用者發出“購買”請求時，先是通路了視圖頁面“Shopping.aspx”，背景邏輯代碼在“Shopping.aspx.cs”中，頁面生命周期中會将頁面的計算結果傳回給使用者。
如果利用MVC的思想，都是基于使用者互動行為的話，那麼請求流程将會是如下所示：
問題2：壞架構的副作用——緊耦合
當選擇了一個錯誤的架構以後，未來将會出現很多難以解決的副作用，在ASP.NETWebForm中就出現了這個問題。盡管behindcode背景代碼被分離到不同的檔案中，但是ASPX.CS檔案和ASPX檔案卻緊密的聯系在一起，這将導緻系統的耦合度很高，并且很難解耦合，這是一個很頭疼的問題。
簡單地說，我們很難将Customer.aspx.cs和CustomerDetailed.aspx簡單地剝離開，背景代碼已經緊緊地将其捆在一起，而且也很難複用。如果我們可以将請求先通過action，而不通過視圖view，action得到的資料再由控制器決定由哪個view展示，那麼請求的流程将會是這樣的：
是以我們可以很友善地控制最終結果是由移動頁面展示還是正常頁面展示，如下代碼：
publicActionResult Index(string DeviceType)
if (viewType == "Mobile")
{
returnView("MobileView");
}
else
returnView("NormalView");
}
問題3：HTML不是唯一的傳回類型
由于視圖view和背景代碼behindcode緊密耦合在一起，是以預設的傳回類型就固定了，都是HTML類型。如果你想改變類型就必須設定Content-type和調用Response.End方法。
如果我們建立一個Action，傳回的類型由Action中指定，系統就可以在同一個action中根據不同條件輸出不同的傳回類型。代碼如下：
publicActionResult Index(string viewType)
if (viewType == "JSON")
return Json(new Customer(),JsonRequestBehavior.AllowGet);
returnView("DisplayCustomer", new Customer());
問題4：視圖和資料的靈活組合
Webform是視圖優先的架構，是以視圖決定了展現的資料，是以視圖的擴充性就很差，如果遇到複雜的資料結構，這種方式就顯得力不從心了。
但是如果是行為優先的架構的話，當我們觸發action時，action可以根據不同的請求選擇不同的資料模型和視圖結構，如下圖：
在MVC中，你可以在不同的view中選擇相同的資料模型，比如下面的代碼，customerdata資料既可以綁定在DetailCustomer視圖中，也可以綁定在Customer視圖中。
publicActionResult Index(string ViewName,Customer customerdata)
if (ViewName =="Detailed")
returnView("DetailCustomer",customerdata);
returnView("Customer",customerdata);
但這在WebForm中實作起來是非常麻煩的。
問題5、将behind code當做普通的類來進行單元測試
behindcode背景代碼在WebForm中是一個非常龐大的類，并且不能簡單地執行個體化。要知道WebForm是繼承于Page類的，Page類不能直接執行個體化，因為它有太多的依賴項。
publicpartial class WebForm1 : System.Web.UI.Page
{
protected void Page_Load(object sender,EventArgs e)
public void Button1_Click(objectsender, EventArgs e)
Session["SomeSession"] ="Is this set";
}
為什麼我們想要執行個體化Page類呢？其中一個原因就是可以友善單元測試。比如我要測試一個按鈕點選事件，用來檢查Session是否設定成功。在WebForm中的代碼看起來不是那麼舒服：
[TestMethod]
publicvoid TestMethod1()
WebApplication22.WebForm1 obj = newWebApplication22.WebForm1();
obj.Button1_Click(this, newEventArgs());
并且運作時還會抛出一個異常：
在MVC中，這個類變成了一個普通類，我們可以在測試工程中将它執行個體化，并對類裡面的屬性方法、Session、ViewBag 、 TempData等進行單元測試。
publicclass HomeController : Controller // this class is simple
public ActionResult Index()
return View("SomeView");
是以是否選擇MVC解決方案？
· 将behindcode中的代碼轉移到controller類中，并将原來的方法轉換成action方法。
· 中間層用資料模型和邏輯接口代替。
· 視圖view隻用來展現資料和頁面布局。
· DAL層和其他層沒有什麼變化，因為它和behindcode關系不大。
是以MVC架構中，使用者的請求分為下面3個步驟：
· 終端使用者發送請求，路由器将請求路由到合适的Controller，Controller是邏輯實體和行為Action的集合。
· Controller将請求映射到特定的Action。
· Action有兩個任務，第一是擷取合适的資料，第二是将這些資料和視圖View綁定起來。Action建立資料模型，并将資料模型連接配接到指定View，輸出最終的相應結果。