ASP.NET開發實戰——（五）ASP.NET MVC & 分層

上一篇文章簡要說明了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若所思。

歡迎關注個人公衆號，不只爲你推薦最新的博文，還有更多驚喜和資源在等着你!一塊兒學習共同進步！