就個人感覺而言。ASP.NET MVC是一種非常反人類的設計。（我沒有接觸過Java的MVC，不知道兩者是否一樣。如果一樣，那么搞Java的同學也挺可憐。）尤其是MVC的路由機制，灰常灰常反動。路由所帶來的“美觀的”URL，通過合理的文件層次布局+URL重寫機制同樣可以解決。但顯然文件目錄結構的方式，更直觀明了，貼近人們的自然思路。可惜不管我們?nèi)绾瓮虏?，薩蒂亞?納德拉估計是不會聽的。
MVC的默認組織機構是扁平的。所有的Controller都是平級的。在大型項目中，這完全是一個災難。當需要上百個甚至數(shù)百個Controller，或是為了讓代碼“自說明”時（指合理的給方法、文件命名，使閱讀者在沒有注釋的時候也能直接讀懂開發(fā)者的意圖），很多Controller需要同名時，尤其讓人崩潰。路是死的，人是活的。為了解決這一問題，聰明的程序猿想出了很多辦法。比如利用Area機制、重寫視圖匹配機制、重寫MVC框架等等。我們的OA系統(tǒng)中也有近百個Controller，不提前規(guī)劃好路由，后續(xù)的工作我們就無法展開。所以，在這一節(jié)，我們就來聊聊其中兩種不對MVC做大手術的方式。
（僅僅一個小功能模塊就需要10多個Controller，在大型項目中，甚至需要數(shù)百個Controller，對項目管理而言，如不進行合理劃分、管理，而按照mvc默認的平級存放，無疑會帶來災難性的后果。注：本圖已對功能模塊進行按目錄劃分）
MVC大型項目常見組織方式1——重寫視圖匹配機制，實現(xiàn)MVC多級目錄
該方式的核心要點是：根據(jù)功能劃分，對Controller和View進行多級目錄處理（如上圖）。然后通過路由優(yōu)先級和重載MVC自帶的視圖匹配邏輯的方式，達到精確控制URL與Controller、Views進行匹配。進行這是最接近自然思維的處理方式，合理而精細的安排路由優(yōu)先級的情況下，可以做到非常深的目錄層次。在我們的示例項目中，也將采用這種辦法。
