上一篇文章簡要說明了MVC所代表的含義並提供了詳細的項目及其控制器、視圖等內容的創建步驟,最終完成了一個簡單ASP.NET MVC程序。
注：MVC與ASP.NET MVC不相等，MVC是一種開發模式，而ASP.NET MVC是MVC這種模式的其中一種實現方式，本文中提到的MVC如果沒有特指，那麼均表示ASP.NET MVC。
本文將從ASP.NET的M-V-C到底代表什麼？如何編寫對應的代碼？來討論如何使用ASP.NET MVC開發應用程序。
○ ASP.NET MVC與分層
○ ASP.NET MVC中的M代表什麼
○ ASP.NET MVC的V和C是如何交互的
○ ASP.NET MVC中的C應該如何處理業務邏輯
○ 如何使用ASP.NET MVC
ASP.NET MVC與分層
什麼是分層？
在瞭解分層之前，先了解一下層次的概念，層次是指系統在結構或功能方面的等級秩序。具有多樣性，可按物質的質量、能量、運動狀態、空間尺度、時間順序、組織化程度等多種標準劃分。不同層次具有不同的性質和特徵，既有共同的規律，又各有特殊規律。（來自百度百科）
所以分層實際上是根據一定的標準和規律，將一個整體劃分爲多個層次，保證每一個層次中的內容都有共同的性質和特徵，便於針對每一個層次進行維護管理。
代碼分層：
代碼分層就是將代碼根據其功能特性將代碼分而治之，代碼分層一般分爲三層（所以也被稱爲三層架構），分別是UI層、業務邏輯層和數據層，分層架構主要是把整個系統的數據存儲、業務邏輯、UI實現進行關注點分離：
○數據層：關注數據是如何存儲的不需要業務邏輯來處理，只需要調用相應接口就可以完成數據的獲取、存儲等功能。
○業務層：把業務區分出來可以更好的專注於業務邏輯的實現，對於一些業務邏輯較爲複雜的系統可以使用領域驅動(DDD)的方法去實現。另外業務邏輯可以被重用，一個常見的例子就是MVC以及Web API，MVC用於Web端應用開發，Web API還可以用於爲其它客戶端或者是提供第三方應用使用，所以業務邏輯的實現不能在UI層，否則就回出現MVC的Controller中存在一份代碼，而Web API的Controller中也存在相同的一份代碼，以致於代碼難以維護。
○UI層：需要做的就只有用戶界面的設計，設計師只需要去關心如何將需要表達的內容完美的表達給用戶並提高用戶體驗即可。
另外分層架構的“層”其實應該是根據業務特性、系統複雜度等因素來拆分的，分層可以讓適合的人做適合的事情，並且設計模式中的“依賴倒置”原則定義模塊直接要依賴抽象而不是實現，只要定義出抽象(接口)那麼多個團隊即可同時對不同的“層”進行開發。
注：以上的分層架構特指服務端分層架構，像移動應用甚至一些單頁應用也會特意的進行分層以享受分層帶來的代碼管理的便利。
ASP.NET MVC是什麼？
在上一篇文章中介紹了ASP.NET MVC以及MVC分別代表的意義。從意義上看起來MVC的概念和三層架構的概念很相似，它們分別都對應了UI、業務邏輯和數據。但是它們有着很大的區別，MVC的View、Controller、Model的作用是處理UI顯示、操作和數據交換。換句話說ASP.NET MVC在三層架構中僅僅是UI層的一種實現。
ASP.NET MVC中的M代表什麼
M代表數據模型，但是應用程序中是存在多種數據模型的，比如與數據庫一一對應的數據模型、用於顯示的數據模型，ASP.NET MVC中很容易混用這兩種模型，舉個例子，用戶信息除了用戶特徵還會包含用於登陸系統的密碼等信息。對用戶信息修改時除了修改特徵還會修改密碼等，但是在顯示時就肯定不會把密碼顯示出來。還有一種情況就是一個列表頁面，它不僅僅顯示記錄條目，還會顯示分頁信息，但是分頁信息是不會存儲到數據庫中的，所以這兩種模型是有明顯區別的。
ASP.NET MVC在分層架構中被定位爲UI的實現，那麼這裏的M應該被看作用於顯示的數據模型。一些人也把它稱爲View Model，但是這個View Model與MVVM模式下的View Model有本質的區別，這裏的View Model是用於顯示的數據模型。
ASP.NET MVC的V和C是如何交互的
根據之前的分析MVC的Model是用來展示的數據，所以理所應當的Controller應該生成一個Model交付給View來渲染。相反的，在通過Web頁面提交一些數據時，這些數據來自View，那麼View也應該提供一個Model交給Controller來執行相應的業務，它們的關係如下：
ASP.NET MVC中的C應該如何處理業務邏輯
Controller用於處理來自客戶端的請求，然後給出響應。而這個處理的過程就對應了實際的業務邏輯，而MVC又處於業務邏輯層之上，所以Controller唯一能做的就是直接調用業務邏輯，這裏的調用應該是順序的，沒有任何邏輯判斷的，所有的處理均交付給邏輯層。
如何處理Controller和業務層的數據交換？視圖模型還是實體模型(數據庫模型)?
首先視圖模型不可用，因爲MVC在業務層之上，如果使用視圖模型，那麼下層依賴上層是違反依賴原則的。而且視圖模型可能包含分頁等信息，也不是業務層需要的。
其次可以用實體模型來交換，這個方案看上去可以，MVC以及業務都依賴一份實體模型。但是如果使用領域驅動來設計模型的時候怎麼辦？這時的“實體”包含了部分業務邏輯，而這部分的邏輯一般是不可以被UI層直接調用的。
根據以上的分析發現兩種都存在不符合的應用場景，所以引入了DTO（Data Transfer Object）數據傳輸對象這個概念，關於這個概念後續在分析，現在的博客系統先使用實體模型來處理數據交換。
如何使用ASP.NET MVC
任何一個工具，不同的人可能會有不同的效果，對於軟件開發來說除了完成功能性需求的開發，更重要的還有保證開發效率、軟件質量、代碼質量等非功能需求，以保證軟件能夠在適合的時間開發完成，代碼可測試、可維護。但是不同的開發者使用工具習慣不一致，對於ASP.NET MVC來說，有的人可能習慣把Model當數據庫模型和頁面模型使用、把所有業務邏輯編寫到Controller中、過多使用ViewBag等對象傳輸數據到View等。對於這些方法來說它仍然能夠實現功能性需求，而且對於個人來說使用習慣的方法效率最高，但是對於一個團隊來說這往往會造成很大的麻煩，每個人保持自己的風格，最後整個項目代碼被改的面目全非，代碼沒有可讀性、無法維護、無法測試等等。
所以在使用工具前必須統一規範。沒有規矩不成方圓。ASP.NET MVC 在某些角度上對於MVC來說也是一種規範。
規範有好有壞，但無論好壞，只要存在規範，那麼在修改規範時也會更容易，本系列文章會根據“博客系統”的進度來設定不同的規範，對於ASP.NET MVC的使用來說，應該有以下幾點：
○ Controller只能順序調用業務邏輯，不存在任何判斷語句。
○ View在一般情況下只是用Controller傳過來的Model對象，避免ViewBag等對象的使用。
○ Model只作爲View和Controller之前的傳輸對象使用，與數據實體無關。
小結：
本章進一步的分析了MVC的概念，並在最後提出了規範，對於規範來說更多的指編碼規範，比如命名規範、註釋規範等等，這裏的規範僅僅是對統一對ASP.NET MVC的使用方法，使得代碼便於維護、測試，甚至後續使用代碼生成器來生成代碼也更加容易(關於代碼規範等內容會在後續引入更多介紹)。
歡迎添加個人微信號：Like若所思。
歡迎關注我的公衆號，不僅爲你推薦最新的博文，還有更多驚喜和資源在等着你!一起學習共同進步！
