內容 先決條件 介紹 ASP。NET Webform背後的程式碼-福利和詛咒 問題1:-基於行動的需求的基於檢視的解決方案 問題2:-不良架構的副作用:-緊密耦合 問題3:- HTML不是唯一的響應型別 問題4:檢視和資料的靈活組合 問題5:-使後面的程式碼成為單元測試的普通類 所以解決方案是MVC? 我們失去了什麼? 父親的請求 感謝我的女兒Sanjana創造了這張圖片。如果你能在FB https://www.facebook.com/photo.php?這將有助於她將來成為一名漫畫家。我只是想告訴她，她在繪畫方面有多好，應該把它作為職業道路來考慮。 順便說一句，上面的圖片將幫助你視覺化為什麼MVC比webforms更好。當你閱讀這篇逐步學習MVC的文章之前，這個影象將幫助你連線在一起。 先決條件 在本文中，我將使用兩個經常使用的術語。NET Web表單和ASP。淨MVC。許多開發人員認為ASP。NET不同於MVC。但事實上MVC是一種架構編碼風格，而ASP。淨框架。如果你來自認為ASP的類別。NET和MVC是不同的，所以我誠實的建議是首先閱讀這篇文章，以避免任何進一步的混亂http://computerauthor.blogspot.in/2014/08/aspnetvs-mvc-vocabul-confusion_15.html 介紹 如果你看一下微軟最近的議程，你會清楚地看到他們主要關注的是MVC, MVC和MVC。所以問題是，為什麼微軟如此熱衷於拋棄像ASP這樣成功的東西。並說服微軟web開發社群使用asp.net Webform。淨MVC。 這就是本文所關注的。 ASP。NET Webform背後的程式碼-福利和詛咒 如果你仔細觀察ASP。這是一種用於web開發的RAD /視覺化方法。換句話說，開發人員拖放設計器上的使用者控制元件和後面程式碼中的VS工具程式碼。 換句話說，當你在設計器上拖放按鈕控制元件時，一個按鈕物件就被建立了，開發人員可以在按鈕物件的單擊事件中編寫程式碼。 隱藏,複製Code

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)
        {
            // Developers write code here
        }
    }

因此，當開發人員拖放這些UI元素時，雙擊以獲得前端的事件，並在這些事件中編寫邏輯等等。在後端，微軟程式碼的邏輯在ASPX.CS部分類檔案中巧妙地和安靜地。 現在這部分程式碼檔案是成功交付ASP的關鍵。NET Webformprojects的開發速度更快，封裝了大量的技術細節，如事件、委託、HTTP協議POST、GET、會話管理等。你可能會想閱讀這篇文章為什麼Microsoft有分部類?以及Microsoft UI的成功故事。 但是由於後面程式碼的定位和呼叫方式，它有5個嚴重的問題。因此，讓我們來討論這5個問題，以及MVC如何幫助解決這些問題。 問題1:-基於行動的需求的基於檢視的解決方案 網站在一天結束時被終端使用者使用。終端使用者帶著特定的目的來到一個網站，他們通過行動來傳達他們的目的。例如，如果有人來購物門戶，他將交流他的目的使用行動:- 購買產品。打印發票 現在這些動作是通過點選按鈕、右鍵或通過瀏覽器URL等來傳達的。基於這種基於動作的結構，Web選擇了HTTP協議，因為它具有POST、GET、PUT、DELETEetc等動作，可以更清楚地傳達終端使用者的意圖。這也使得REST成為處理終端使用者請求的流行方式。因此，從邏輯上講，如果我們能將這些動作對映到程式的方法/函式，那將更有意義，也能保持架構簡單。 但是微軟沒有辦法，他們想要支援RAD概念，或者我們可以稱之為視覺化程式設計概念，所以他們最終為基於動作的結構提供了基於檢視的解決方案。 所以對於web表單(如上圖所示)，請求流變得很奇怪:- 終端使用者通過HTTP POST / GET等操作傳送請求。IIS webserver將這個請求對映到一個檢視。檢視呼叫頁面生命週期，遍歷事件，然後呼叫適當的操作。最後，action put將結果以HTML格式傳送給終端使用者瀏覽器。 最後，微軟為基於動作的需求提供了基於檢視的架構。因此，架構本身在邏輯上並不適合終端使用者的基於操作的方法。換句話說，如果終端使用者傳送了一個“購買”動作，它首先會出現一個類似“購物”的檢視。aspx，誰反過來踢“購物。aspx。執行一個複雜的頁面生命週期，然後執行將滿足終端使用者的要求的操作。 這就像擊中要害。在一個複雜的頁面生命週期之後，end請求被對映到實際的操作就完成了。所以，我們應該讓以行動為導向的建築師，而不是以檢視為導向的建築師。或者我可以換一種說法“我們如何使行動優先而不是檢視優先?” 先點選動作，然後動作會抓取檢視。這將使流程更有邏輯和清晰。這正是MVC架構所做的。第一次命中是一個屬於控制器的操作，然後控制器用適當的模型呼叫檢視。 問題2:-不良架構的副作用:-緊密耦合 一旦你以一個錯誤的架構開始，你最終會調整事情，然後你會以嚴重的副作用結束。在這個案例中，同樣的事情發生了。背後的程式碼在不同的檔案中看起來是不同的，但實際上卻從來沒有解耦過，比如ASPX. cs不能與ASPX分離。 簡單地說，我無法附加“Customer.aspx”。cs”與“CustomerDetailed。aspx”很容易。後面的程式碼與檢視緊密耦合。它是不可重用的。 如果你曾經分析過背後程式碼的數量w.r。對於這個專案的其他層次來說，它的規模是巨大的，有著複雜的事件。從長期的角度來看，這使得程式碼難以閱讀和維護。 因此，如果我們能將檢視第一基於的架構改變為操作第一基於的架構，那麼我們就能在不同的檢視中重用相同的操作程式碼。例如，如果終端使用者傳送一個動作“Display”，它可以呼叫“DisplayDesktop”。aspx”或者它可以顯示“DisplayMobile”。aspx "取決於裝置的型別。 所以在MVC操作取決於情況，我們可以呼叫“MobileView”或“NormalView”，下面是相同的樣例程式碼。想象一下在Webform後面的程式碼中實現這個，非常困難，對吧。 隱藏,複製Code

public ActionResult Index(string DeviceType)
{
           if (viewType == "Mobile")
            {
                return View("MobileView");
            }
            else
            {
                return View("NormalView");
            }
}

問題3:- HTML不是唯一的響應型別 由於檢視和程式碼之間的緊密耦合，甚至響應型別在webform中都是固定的，所以預設是HTML。如果您希望更改它，則需要使用Content-type和“Response”。結束“方法等，安靜乏味。 如果我們先建立"行動"結構那麼行動就有足夠的空間來決定應該採取什麼樣的反應型別。這使得我們的系統在相同的動作和不同的輸出方面更加靈活。 下面是一個簡單的MVC操作程式碼，根據傳遞給操作的值傳送JSON或HTML結果。webformview很難實現這種靈活性，因為它們只能發出HTML。 隱藏,複製Code

public ActionResult Index(string viewType)
{
            if (viewType == "JSON")
            {
                return Json(new Customer(), JsonRequestBehavior.AllowGet);
            }
            else
            {
                return View("DisplayCustomer", new Customer());
            }
}

問題4:檢視和資料的靈活組合 當我們向用戶傳送響應時，它是檢視(顯示)和資料(模型)的組合。Webform是一個檢視優先的架構，因此檢視決定連線哪個模型，這使得檢視不那麼靈活，也涉及到複雜的決策制定。這顯然違反了SOLID原則的SRP，請在這裡閱讀更多關於SOLID原則的內容。 但是，如果我們採用“行動第一”架構，那麼首先出現的是“行動”，他選擇模型和檢視來發送不同的響應。 在MVC操作中，您可以編寫如下所示的程式碼。你可以拿起同一個模型，然後用不同的視角將它連線起來。例如，在下面的程式碼中，我們採用了“customerdata”模型並附加了“DetailCustomer”檢視，而相同的模型在其他情況下附加了“Customer”檢視。 隱藏,複製Code

public ActionResult Index(string ViewName,Customer customerdata)
{
            if (ViewName == "Detailed")
            {
return View("DetailCustomer",customerdata);
            }
            else
            {
                return View("Customer",customerdata);
            }
}

通過Webform實現這種靈活性是非常困難的，因為呼叫是在檢視本身上進行的，然後需要在頁面生命週期中編寫所有決策制定邏輯，並重定向到其他檢視，這樣實現就不那麼清晰了。 問題5:-使後面的程式碼成為單元測試的普通類 webform背後的程式碼是一個非常典型的笨重的部分類，它不能直接用簡單的c#程式碼例項化。請記住，Webform螢幕繼承自“Page”類。這個頁面類不能直接建立，因為它有很多依賴項。 隱藏,複製Code

public partial class WebForm1 : System.Web.UI.Page
    {
        protected void Page_Load(object sender, EventArgs e)
        {

        }

        public void Button1_Click(object sender, EventArgs e)
        {
            Session["SomeSession"] = "Is this set";
        }
    }

接下來你會想到為什麼要例項化這個page類。我希望例項化這個page類的地方之一是用於單元測試。我想呼叫按鈕點選方法的動作，測試會話變數是否設定正確，檢視狀態是否正確等等。 但是，如果您嘗試像下面程式碼中所示那樣做，您將以如下所示的奇怪程式碼結束。注意那些傳遞給按鈕單擊方法的難看的事件引數。 隱藏,複製Code

[TestMethod]
public void TestMethod1()
{
            WebApplication22.WebForm1 obj = new WebApplication22.WebForm1();

            obj.Button1_Click(this, new EventArgs());
}

當你呼叫它時，它要求更多的東西，這使得UI單元測試不可能。 在MVC中，這就變成了一個普通的類。一個可以在簡單的單元測試專案中例項化的類，你可以用一種簡單的方式測試各種方面，比如session,viewbag, tempdata。 隱藏,複製Code

public class HomeController : Controller // ß this class is simple 
{
        public ActionResult Index()
        {
            Session["SomeSession"] = "Is this set";
            return View("SomeView");
        }
}

所以解決方案是MVC? 從基於檢視的架構到ac加強基於MVC架構我們需要做以下結構變化(上圖給出了視覺化檢視相同的):- 後面的程式碼移動到一個控制器類與所有的事件轉換方法可稱為行動。中間層成為模型提供資料和業務邏輯。檢視只顯示,定位和佈局。木豆和其他層不改變很多,因為他們沒有直接與後臺程式碼的問題。 所以與MVC架構我們有以下三個步驟流程:- 終端使用者應用程式傳送他的請求。應用程式將請求路由到控制器。控制器是一個邏輯實體,團體一起行動。控制器將請求對映到一個特定的行動。現在行動有兩個任務首先需要訪問適當的資料取決於行動和第二資料必須連線到正確的觀點。操作建立模型物件並將模型檢視傳送最終的響應。 我們寬鬆的什麼? ASP的最大優勢。淨WebForm RAD /視覺化程式設計。儘管它是一個快速和骯髒的做事的方法能幫助你更快地完成應用程式,讓你的客戶感到滿意和按時交貨。你可以閱讀本文討論將在http://www.codeproject.com/Articles/808297/Things-you-will-miss-in-ASP-NET-MVC-as-an-ASP-NET MVC小姐 的Webforms的決定是正確的方式在2000年對微軟,因為它想遷移VB6, VF, vc++開發人員他們都沉迷於RAD程式設計。我認為Webform已經實現了的目標是建立現在朝著更好的和邏輯架構即MVC。 如果你確信MVC的辦法你可以學習MVC 2天即16小時使用下面的視訊。 也從Web表單與MVC文章閱讀和學習。 本文轉載於：http://www.diyabc.com/frontweb/news1855.html