應用程序框架實戰三十:表現層及ASP.NET MVC介紹（一）

　　本文將介紹表現層及ASP.NET MVC的一些要點，特別是ASP.NET MVC的一些抽象和封裝技巧，若是你對MVC還不瞭解，能夠參考《ASP.NET MVC4 高級編程》，做者Jon Galloway等，這本書由ASP.NET MVC團隊成員編寫，至關不錯。

表現層的職責

　　表現層的職責是展現和收集數據，將領域層的數據和邏輯展現出來，並收集用戶輸入的相關信息。

　　搞清楚表現層的職責之後，你就應該清楚，表現層不是你應該編寫業務邏輯的地方，這也是分層架構的核心。

　　若是要展現一個計算值，不該該在表現層直接完成計算，相反，由領域層進行計算，表現層直接拿到結果並展現，這樣可讓表現層代碼很是簡潔，同時業務邏輯被高度內聚到領域層。

　　不少時候，爲了提高用戶體驗，咱們會在頁面上使用Js進行客戶端計算，從而得到快速響應，但也致使業務邏輯泄露到Js中。在大多狀況下，這是能夠接受的，不過在你準備用Js編寫這些重複邏輯時，能夠先考慮是否可使用Ajax請求服務端完成。每當你須要進行客戶端實時計算時，就發送請求給服務端，領域層完成計算，返回結果。

　　儘可能減小業務邏輯副本，當需求變化或發現BUG時，代碼同步更輕鬆。

　　對於管理系統來講，儘可能讓程序員少寫Js，儘可能封裝和抽象，由於Js是弱類型，沒有編譯時檢查，代碼提示很弱，哪怕使用了Resharper，代碼提示功能依然不佳，細長的提示滾動條，看得你兩眼直冒金星。另外Js不少技巧看上去很怪異，初學者使用這些技巧，Bug率將大幅上升。當項目交給新人維護，長篇的Js更使其痛苦不堪。固然這是給普通團隊的建議，少寫Js可讓你的項目容易維護，高水平團隊請忽視。

Mvc介紹

　　MVC是一個表現層架構模式，將表現層分紅三個部分，模型、視圖和控制器。

　　當Http請求發送到ASP.NET MVC引擎時，MVC引擎查找路由表以決定由哪一個控制器操做來處理這個請求。

　　控制器是一個指揮中心，它調用後端的服務，並將獲得的模型交給視圖顯示。

　　你能夠直接在控制器方法中操做DbContext或倉儲，並使用Linq語句進行查詢。當你逐步意識到控制器代碼變得複雜時，能夠建立應用層服務來簡化表現層。

　　應用服務爲表現層提供惟一的API訪問點，大幅下降控制器複雜度，控制器的全部操做，都經過應用服務一個明確的API完成，不只操做更規範，並且控制器將變成很薄的一層。

　　控制器的開發要點是，保持儘可能簡單，沒事少寫代碼。把你的需求交給應用層服務去實現，你只須要簡單調用其接口就好了。

　　模型是指數據與業務邏輯，即領域模型，大部分時候，你能夠在MVC視圖中直接操做領域實體，視圖模型ViewModel不是必須的。不過出於某些緣由考慮，視圖中操做的也多是DTO或ViewModel，當界面變得複雜時，經過爲特定視圖引入專門的ViewModel 能夠簡化界面開發。

　　你可能已經發現了名目繁多的實體類型：領域實體、DTO、ViewModel、查詢實體等，確實讓人眼花繚亂，我將在後續用專文討論，以方便你根據須要取捨。

約定優於配置

　　「約定優於配置」原則，建議你儘可能遵循默認約定，並造成習慣，這樣能夠大幅下降學習成本和工做量，同時得到更一致的目錄結構和代碼風格，查找特定類型的文件變得很是容易，可維護性大大提升了，你僅在必要時才須要經過配置來覆蓋默認值。

　　「約定優於配置」原則對目錄結構和命名產生了深遠影響。

　　項目的目錄結構相當重要，但大部分程序員對目錄結構不太關心，由於建立文件夾沒有技術含量，簡單的容易被忽視。

　　當你準備修改某個功能時，第一步起碼先得找到相關的文件。

　　若是你平時不太注意目錄結構的管理，建立文件很隨意，隨便找個地方就扔進去了，隨着項目文件的增多，你的開發工做將會愈來愈亂，當你要找某個文件時，你會在目錄樹中四處亂點，「哦，不在這，哦，也不在那，哦耶，終於找到了」。

　　當你要找一個控制器時，你會去查找Controllers目錄，而不是一個叫ABCD的目錄，這就是命名約定。若是存在一個名爲TestController的控制器，默認在Views目錄中就會有一個Test的目錄與之對應，這樣在查找控制器對應的視圖時就能很是輕鬆。

　　當你的全部文件都可以根據約定，分門別類的放到清晰命名的目錄中時，整個項目的質量將大幅提高。

　　我在封裝EasyUi時，把控件Id的命名做了一些約定，好比表格叫grid。這樣不少Js回調函數，就能夠在內部完成，不須要你手工處理了，若是你遵循這些約定，開發一個簡單的EasyUi CRUD操做，基本不須要寫Js。

 

　　.Net應用程序框架交流QQ羣: 386092459，歡迎有興趣的朋友加入討論。

　　謝謝你們的持續關注，個人博客地址：http://www.cnblogs.com/xiadao521/