第三章 MVC 模式，項目和約定 在深入瞭解ASP.NET Core MVC的細節之前，我想確保您熟悉MVC設計模式背後的思路以及將其轉換為ASP.NET Core MVC項目的方式。 您可能已經瞭解本章中討論的一些想法和約定，特別是如果您已經完成了高級ASP.NET或C#開發。 如果沒有，我鼓勵你 ...
第三章 MVC 模式，項目和約定
在深入瞭解ASP.NET Core MVC的細節之前，我想確保您熟悉MVC設計模式背後的思路以及將其轉換為ASP.NET Core MVC項目的方式。 您可能已經瞭解本章中討論的一些想法和約定，特別是如果您已經完成了高級ASP.NET或C#開發。 如果沒有，我鼓勵你仔細閱讀 - 深入地理解隱藏在MVC背後的東西可以幫助你在通讀本書時更好地與MVC框架的功能聯繫起來。
MVC的歷史
模型視圖控制器模式起源於20世紀70年代後期，來自施樂PARC的Smalltalk項目，它被設想為組織一些早期的GUI應用程式。 原始MVC模式的一些細節與Smalltalk特定的概念（如屏幕和工具）有關，但更廣泛的概念仍然適用於應用程式，並且它們特別適合於Web應用程式。
理解MVC模式
在高層次上，MVC模式意味著MVC應用程式將被分成至少三個。
- 模型，其中包含或表示用戶使用的數據
- 視圖，用於將模型的某些部分呈現為用戶界面
- 控制器處理傳入請求，對模型執行操作，並選擇要呈現給用戶的視圖 每一塊MVC架構都有明確的界定和獨立的，這被稱為分離問題。 在模型中操縱數據的邏輯只包含在模型中; 顯示數據的邏輯只在視圖中，處理用戶請求和輸入的代碼只包含在控制器中。 每個部分之間有明確的劃分，您的應用程式將更容易維護並延長其使用壽命，無論它最終變得多麼複雜。
理解模型
模型 - MVC中的M - 包含用戶使用的數據。有兩種廣泛的模型：視圖模型，它們代表從控制器傳遞到視圖的數據。領域模型：業務領域中的數據以及操作，轉換和規則，用於創建、存儲並操縱該數據，統稱為模型邏輯。 模型是您的應用程式工作的環境的定義。例如，在銀行應用程式中，該模型表示應用程式支持的銀行中的所有內容，如帳戶、總帳和客戶的信用限額以及可用於存入資金並從賬戶中提款等類似模型中數據的操作。該模型還負責保存數據的整體狀態和一致性 - 確保所有事務被添加到客戶不會比銀行有權獲得更多的錢或者比銀行更多的錢提取更多的錢。 對於MVC模式中的每個組件，我將描述它應該包括哪些東西和不應該包括哪些東西。
使用MVC模式構建的應用程式中的模型應該：
- 包含域數據
- 包含用於創建，管理和修改域數據的邏輯
- 提供一個清晰的API，以暴露模型數據和操作
模型不應該：
- 揭示如何獲取或管理模型數據的細節（換句話說，細節的數據存儲機制不應該暴露給控制器和視圖）
- 包含根據用戶交互轉換模型的邏輯（因為這是控制器的工作）
- 包含向用戶顯示數據的邏輯（應由視圖負責） 確保模型與控制器和視圖隔離的好處是可以讓測試變得更容易（我在第7章中描述單元測試），並且可以讓整個應用程式更簡單。
提示:許多剛接觸MVC的開發人員對在數據模型中包含邏輯感到困惑，認為MVC模式的目標是將數據與邏輯分離。 這是一個誤會：MVC模式的目標是將應用程式分成三個功能區域，每個功能區域可以包含邏輯和數據。 目標不是消除模型中的邏輯。 而是確保模型只包含用於創建和管理模型數據的邏輯。
理解控制器
控制器是MVC模式中的結締組織，用作數據模型和視圖之間的通道。 控制器定義提供在數據模型上運行的業務邏輯的動作，並向用戶提供查看顯示的數據。
使用MVC模式構建的控制器應該是：
- 根據用戶交互包含更新模型所需的操作
控制器不應該：
- 包含管理數據外觀的邏輯（即視圖的工作）
- 包含管理數據持久性的邏輯（即模型的工作）
理解視圖
視圖包含向用戶顯示數據或從用戶捕獲數據所需的邏輯，以便可以通過控制器操作進行處理。
視圖應該：
- 包含向用戶呈現數據所需的邏輯和標記
視圖不應該：
- 包含複雜的邏輯（放在控制器中更好）
- 包含創建，存儲或操縱域模型的邏輯 視圖可以包含邏輯，但應該簡單，且須謹慎使用。除了最簡單的方法調用或表達式，在視圖中放置任何東西，會使整個應用程式更難測試和維護。
MVC的在ASP.NET上的實現
顧名思義，ASP.NET Core MVC將抽象MVC模式應用於ASP.NET和C＃開發的世界。 在ASP.NET Core MVC中，控制器是C#類，通常派生自Microsoft AspNetCore.Mvc.Controller類。 從Controller派生的類中的每個公共方法都是與URL相關聯的行動方法。 當請求發送到與行動方法相關聯的URL時，執行該行動方法中的語句，以便對域模型執行某些操作，然後選擇要向客戶端顯示的視圖。 圖3-1顯示了控制器，模型和視圖之間的交互。
圖3-1 控制器，模型和視圖之間的交互。
ASP.NET Core MVC使用一種稱為Razor的視圖引擎，它是負責處理視圖的組件，以便為瀏覽器生成響應。 Razor視圖是包含C＃邏輯的HTML模板，用於處理模型數據以生成響應模型更改的動態內容。 我將在第5章中解釋Razor的作用。 ASP.NET Core MVC不會對領域模型的實現施加任何限制。 您可以使用常規C#對象創建模型，並使用任何資料庫，對象關聯映射框架或.NET支持的其他數據工具來實現持久性。
MVC與其他模式的對比
當然，MVC不是唯一的軟體架構模式。 還有很多其他的，其中有些是或至少已經非常受歡迎。 您可以通過查看替代方案瞭解有關MVC的許多內容。 在以下部分中，我簡要介紹了構建應用程式的不同方法，並將其與MVC進行對比。 一些模式與MVC有些許的差異，而另一些則完全不一樣。
我不是說MVC是最完美的模式。 我支持採取最佳方法解決手頭問題。 有些情況下，某些模式與MVC一樣好或可能更好。 我鼓勵您在選擇模式時做出明智的選擇。 您正在閱讀本書的事實表明，您已經決定使用MVC模式了，但是保持開闊的視野對你總是有好處的。
理解Smart UI 模式
最常見的設計模式之一就是智能用戶界面（smart UI）。大多數程式員在職業生涯中的某個時候創建了一個智能UI應用程式 - 我當然有。如果您已經使用Windows窗體或ASP.NET Web窗體，那麼您也這樣做了。 要構建一個智能UI應用程式，開發人員通常將一組組件或控制項拖到設計錶面或畫布上構建用戶界面。控制項通過發出按鈕按壓，擊鍵，滑鼠移動等事件來報告與用戶的交互。開發人員添加了一系列事件處理程式來響應這些事件的代碼;這些是在發出特定組件上的特定事件時調用的小塊代碼。這將創建一個單片應用程式，如圖3-2所示。處理用戶界面和業務的代碼都是混合在一起的，沒有任何分離的問題。定義數據輸入的可接受值並且查詢數據或修改用戶帳戶的代碼最終以小部分結束，並按預期的順序耦合在一起。
圖3-2 Smart UI 模式
智能UI是簡單項目的理想選擇，因為您可以快速獲得一些好的結果（相比之下，在MVC開發中，正如你將在第8章中看到的那樣，需要在交付結果前進行大量的初始投資）。智能UI也適用於用戶界面原型。這些設計UI工具可以真的很好，如果你和客戶坐在一起，想要捕捉到外觀和流程的要求，一個智能的UI工具可以快速有效地生成和驗證不同的想法。Smart UI最大的缺點是難以維護和擴展。混合領域模型和業務邏輯代碼與用戶界面代碼導致代碼冗餘，其中相同的業務邏輯被覆制和粘貼以支持新添加的組件。找到所有重覆的部分並修複可能很困難。添加新功能而不會破壞現有的功能幾乎是不可能的。測試智能UI應用程式也可能很困難，唯一的方法是模擬用戶交互，那非常不理想，提供全面測試覆蓋更是不太可能。 在MVC的世界中，Smart UI通常被稱為反模式：應該不惜一切代價避免。這種反感來自，人們花了一半的職業生涯嘗試開發和維護智能UI應用程式，後來結果卻一團糟，後來人們才發現MVC是一個更好的方案。 我的意思是說，拒絕智能UI模式是錯誤的。Smart UI模式並非都那麼糟糕，它有好的方面。Smart UI應用程式快速且容易開發。組件和設計工具生產者已經為開發做出了很大的努力。開發體驗是愉快的，甚至最無經驗的程式員可以在短短幾個小時內產生一些專業而又合理的東西。
Smart UI應用程式的最大弱點 - 可維護性 - 在小型開發工作中不會出現。 如果您正在為小客戶製作一個簡單的工具，Smart UI應用程式可以是一個很好的解決方案。 MVC應用程式太複雜太煩人。
理解模型-視圖體繫結構
在Smart UI應用程式中容易出現維護問題的部分是業務邏輯，它分散在整個應用程式中，使得修改或添加功能十分麻煩。 模型-視圖架構改進了好多，它將業務邏輯轉化為單獨的域模型。 這樣數據、進程和規則都集中在應用程式的一部分中，如圖3-3所示。
圖 3-3 模型-視圖模式
模型視圖架構可以是單片智能UI模式的改進 - 例如，更容易維護，但是會出現兩個問題。 首先是因為UI和領域模型是緊密結合的，所以在這兩者之間進行單元測試是很困難的。 第二個問題來自實踐，而不是模式的定義。 該模型通常包含大量的數據訪問代碼 -雖然不總是這樣，但通常是- 這意味著數據模型不僅包含業務數據，操作和規則。
理解經典的三層架構
為瞭解決模型視圖架構的問題，三層模式將持久性代碼與域模型分離，並將其放置在稱為數據訪問層（DAL）的新組件中。 如圖3-4所示。
圖 3-4 三層架構
三層架構是業務應用程式中使用最廣泛的模式。 它對UI的實現沒有任何限制，並且提供了很好的分離關註點，而不會太複雜。 而且可以創建DAL，使單元測試相對容易。 您可以看到經典三層應用程式和MVC模式之間的明顯相似之處。 不同的是，當UI層直接耦合到點擊事件GUI框架（如Windows窗體或ASP.NET Web窗體）時，幾乎不可能執行自動化單元測試。 而且因為三層應用程式的UI部分可能很複雜，所以有很多代碼不能被嚴格的測試。
在最糟糕的情況下，三層架構在UI層面缺乏執行規則意味著許多這樣的應用程式最終都是虛擬偽裝的Smart UI應用程式，並沒有真正的關註分離。 這給了最糟糕的可能結果：一個非常複雜的，不可測試的，不可維護的應用程式。
理解MVC變種
我已經描述了MVC應用程式的核心設計原則，特別是適用於ASP。 NET Core MVC。 其他人以不同的方式來解釋模式的各個方面，並添加到MVC中，以適應其項目的範圍和主題。 在以下部分中，我簡要介紹一下關於MVC主題的兩個最流行的變體的概述。 瞭解這些變體對於使用ASP.NET Core MVC並不是必不可少的，但是為了知識的完整，我將它包含進來，因為這涉及到大多數軟體模式討論中使用的術語。
理解Model-View-Presenter 模式
模型視圖呈現器（MVP）是MVC的一個變體，旨在更容易地與諸如Windows窗體或ASP.NET Web窗體之類的狀態GUI平臺相配合。這是值得嘗試的，能夠獲得最好的Smart UI模式的優點而且不會帶來問題。 在這種模式中，演示者（Presenter)與MVC中的控制器具有相同的職責，但與有狀態視圖的關係也更為直接，對用戶的輸入的值和操作可直接在UI組件中顯示。 這種模式有兩種實現方式：
- 被動視圖實現，視圖不包含邏輯。該視圖是由演示者直接操縱的用於UI控制項的容器。
- 監督控制器實現，視圖負責展現邏輯的元素（如數據綁定），並且已經從域模型中引用了數據源。 這兩種方法的區別在於視圖的智能化程度。無論哪種方式，Presenter都從GUI框架中解耦，這使得Presenter邏輯更簡單，適合於單元測試。
理解Model-View-View Model模式
模型視圖模型（MVVM）模式是MVC最近的一個變化。 它源於Microsoft，併在Windows Presentation Foundation（WPF）中使用。 在MVVM模式中，模型和視圖與MVC中具有相同的角色。 不同之處在於MVVM中視圖模型的概念，它是用戶界面的抽象表示，通常是一個C#類，用於顯示要在UI中顯示的數據的屬性，以及可以從UI調用的數據的操作 。 與MVC控制器不同，MVVM視圖模型不存在視圖（或任何特定UI技術）的概念。 MVVM視圖使用WPF綁定功能將視圖中的控制項（下拉菜單中的項目或按下按鈕的效果）暴露的屬性與視圖模型公開的屬性進行雙向關聯。
提示:MVC模式還使用術語view模型，但是指的是一個簡單的模型類，僅用於將數據從控制器傳遞到視圖，而不是域模型，這些模型是數據，操作和規則的複雜表示。
理解ASP.NET Core MVC 工程
當您創建一個新的ASP.NET Core MVC項目時，Visual Studio會為您提供項目中所需的初始內容的一些選擇。這個想法是為了減輕新開發人員的學習過程，併為常見的功能和任務應用一些節省時間的最佳實踐。我不是這種代碼模具方式的粉絲。意圖是好的，但執行總是很讓人崩潰。我最喜歡ASP.NET和MVC的特點之一就是我在裁剪平臺時有多大的靈活性來適應我的開發風格。 Visual Studio創建和填充的項目，類和視圖使我感到是在別人的風格下工作。我也發現內容和配置太通用，太平淡，無法使用。微軟不可能知道需要什麼樣的應用程式，所以它涵蓋了所有的基礎，但是以這樣的一般化方式，我最終只是刪除預設內容。 我的建議（給任何提出錯誤的人）是從一個空項目開始，並添加所需的文件夾，文件和包。不僅您將更多地瞭解MVC的工作原理，而且您可以完全控制您的應用程式所包含的內容。但是，我的想法可能不適合你。您可能會發現模板比我更加有用，特別如果您是ASP.NET的新手，並且尚未開發出適合您的開發樣式。您可能還會發現項目模板是一個有用的資源和創意來源，儘管在完全瞭解應用程式的工作原理之前，您應該謹慎地嚮應用程式添加任何功能。
建立工程
當您首次創建新的ASP.NET Core項目時，您可以選擇以下三個基本的起點：空模板，Web API模板和Web應用程式模板，如圖3-5所示。
圖3-5 ASP.NET 工程模板
空項目模板包含ASP.NET Core的管道，但不包括MVC應用程式所需的庫或配置。 Web API項目模板包括ASP.NET Core和MVC，其中包含示例應用程式，演示如何從客戶端接收和處理Ajax請求。 Web應用程式項目模板包括ASP.NET Core和MVC，其中包含演示如何生成HTML內容的示例應用程式。 Web API和Web應用程式模板可以配置不同的方案來驗證用戶並授權他們訪問應用程式。 項目模板可以給人需要遵循特定的路徑來創建某種ASP.NET應用程式的印象，但事實並非如此。模板僅僅是相同功能的不同起點，您可以使用任何模板添加所需的任何功能。例如，第20章中，我解釋瞭如何處理的Ajax請求以及第28-30頁的身份驗證和授權，所有這些都是從空項目模板開始的。
因此，項目模板之間的真正區別是Visual Studio在創建項目時添加的庫，配置文件，代碼和內容的初始集合。最簡單的模板（空）和最複雜（Web應用程式）之間存在很多差異，如圖3-6所示，它顯示了在創建項目之後的解決方案資源管理器。對於Web應用程式模板，我不得不將解決方案資源管理器集中在不同的文件夾上，因為單個列表對於列印頁面來說太長。
圖3-6 空項目模板和Web應用模板中的預設內容
Web應用程式模板添加到項目中的額外文件看起來令人望而生畏，但其中一些只是占位符或常用功能的示例實現。 一些其他文件設置MVC或配置ASP.NET。 還有一些是客戶端庫，它們將被併入應用程式生成的HTML中。 文件列表現在可能看起來很崩潰，但是在完成這本書時你會明白所做的一切。
無論您用於創建工程的模板如何，都會顯示一些常見的文件夾和文件。 工程中的某些項具有特殊角色，他們是硬編碼到ASP.NET中或MVC中或Visual Studio提供支持的工具中。 其他的則受到大多數ASP.NET項目或MVC項目中使用的命名約定的約束。 在表3-1中，我描述了您將在ASP.NET Core MVC項目中遇到的重要文件和文件夾，其中有些文件和文件夾預設不存在於項目中，但在後面的章節中我將介紹。
Table 3-1 MVC 工程中的文件項彙總
文件夾或文件
描述
/Areas
區域是將大型應用程式分割成較小的部分的一種方式。 我在第16章描述區域。
/Dependencies
“依賴關係”項目提供項目依賴的所有包的詳細信息。我在第6章中描述Visual Studio使用的包管理器。
/Components
這是定義用於顯示自包含功能（如購物車）的視圖組件類。 我在第22章中描述視圖組件。
/controllers
這是控制器類所在的地方。 這是一個約定，您可以將控制器類放在您喜歡的任何地方，因為它們都被編譯成同一個程式集。 我在第17章詳細描述了控制器。
Data
這是定義資料庫上下文類的地方，儘管我更傾向於忽略此約定，併在Models文件夾中定義它們，如第8章所示。
/Migrations
這是存儲資料庫模式的詳細信息，以便可以更新部署資料庫。 我在第12章中演示了部署的過程。
/Models
這裡放置視圖模型和域模型。 這是一個約定 您可以在項目中的任何位置或單獨的項目中定義模型類。
/Views
該目錄包含視圖和部分視圖，通常在與它們相關聯的控制器上命名的文件夾中組合在一起。 我在第21章詳細描述了視圖。
/Views/Shared
此目錄包含共用的佈局和視圖。 我在第21章詳細描述視圖。
/Views/_ViewImports.cshtml
該文件用於指定將包含在Razor視圖文件中的命名空間，如第5章所述。 它也用於設置標簽助手，如第23章所述。
/Views/_ViewStart.cshtml
該文件用於指定Razor視圖引擎的預設佈局，如第5章所述。
/bower.json
此文件預設隱藏。 它包含由Bower軟體包管理器管理的軟體包列表，如第6章所述。
/project.json
該文件指定了項目的一些基本配置選項，包括其使用的NuGet軟體包，如第6章所述。
/Program.cs
這個類配置了應用程式的托管平臺，如第14章所述。
/Startup.cs
該類配置應用程式，如第14章所述。
/wwwroot
這是靜態內容，如CSS文件和圖像所在的地方。 Bower包管理器、JavaScript和CSS包也在這裡，如第6章所述。
理解 MVC 約定
在MVC項目中有兩種約定。第一類只是建議您如何組織您的項目。例如，通常將您所依賴的第三方JavaScript和CSS包放在wwwroot/lib文件夾中。這是其他MVC開發人員希望找到它們以及軟體包管理器安裝的地方。但是你可以自由地重命名lib文件夾，或者完全刪除它，並將你的包放在別的地方。只要您的視圖中的腳本和鏈接元素指向您所在的位置，MVC就會運行您的應用程式。 另一種慣例來自於約定大於配置的原則，這是Ruby on Rails受歡迎的主要賣點之一。例如，約定大於配置意味著您不需要顯式地配置控制器及其視圖之間的關聯。您只需遵循一個特定的命名約定為您的文件，一切都正常。在處理這種慣例時，改變項目結構的靈活性較小。以下部分將說明用於替代配置的約定。
提示:所有的約定都是可以更改的，通過用你自己的MVC組件替換預設組件來實現。 我在本書中描述了不同的方法來解釋MVC應用程式的工作原理，但這些是大多數項目中將要處理的約定。
遵循控制器類的約定
Controller類的名稱以Controller結束，如ProductController，AdminController，和HomeController。 當從項目其他地方引用控制器時，例如使用HTML幫助器方法時，您可以指定名稱的第一部分（例如Product），MVC會自動將Controller添加到名稱中，並開始查找控制器類。
提示:您可以通過創建一個模型約定來改變這一點，我在第31章中描述。
遵循視圖的約定
視圖放在文件夾/Views/Controllername。 例如，與ProductController類相關聯的視圖放在/Views/ Product文件夾。
提示:請註意，Views文件夾中省略了"Controller"單詞：/Views/Product，not/Views/ ProductController。 起初看起來似乎是違反直覺的，但它很快就變得自然了。 MVC希望以該方法命名操作方法的預設視圖。 例如，與名為List的動作方法關聯的預設視圖應該稱為List.cshtml。 因此，對於ProductController類中的List操作方法，預設視圖預期為/Views/Product/List.cshtml。 在動作方法中返回調用View方法的結果時使用預設視圖，如下所示：
return View();
你可以用名字指定不同的視圖，像這樣:
return View("MyOtherView");
請註意，我不包括文件擴展名或視圖的路徑。 當尋找一個視圖時，MVC在控制器後面命名的文件夾中，然後在/Views/Shared文件夾中。 這意味著我可以在/Views/Shared文件夾中放置多個控制器使用的視圖，而MVC會發現它們。
遵循佈局的約定
佈局的命名約定是使用文件前面加下劃線（_）字元，並且佈局文件放在/Views/Shared文件夾中。 預設情況下，此佈局將應用於所有視圖/Views/_ViewStart.cshtml文件。 如果您不希望將預設佈局應用於視圖，則可以更改ViewStart.cshtml中的設置（或完全刪除該文件）以在視圖中指定其他佈局，如下所示：
@{ Layout = "~/_MyLayout.cshtml"; }
或者你可以不使用任何佈局，像下麵這樣：
@{ Layout = null; }
總結
在本章中，我向您介紹了MVC架構模式，並將其與您之前看到或聽到的其他模式進行了比較。 我討論了領域模型的重要性並引入了依賴註入，它允許您去分離組件以強制應用程式的各個部分之間的嚴格分隔。 在下一章中，我將解釋Visual Studio MVC項目的結構，並描述MVC Web應用程式開發中使用的基本C#語言特性。
