Microsoft 2013 新技術學習筆記 四

在繼續學習Model的實踐經驗以前，先思考一下Controller和View的實踐原則在本次系統重構中的應用，我手上是一個後臺管理系統(不是門戶系統、不是具體業務系統)，通俗點講就是給企業的運維人員用的一套系統。

後臺運維繫統最核心的就是導航菜單，一切工做從導航菜單開始，從UI結構上來說就是典型的左右結構(左邊導航右邊操做區域)，主流的Web UI框架都有這種結構的Layout。再深刻一層的核心是資源(這個不具有通用性，只是我手上現有系統的設計理念而已)：導航菜單是資源，企業組織結構是資源，用戶是資源，權限是對資源的權限.....

粗略分析一下資源的獲取流程及業務規則：

1. 獲取客戶端參數，具體規則：參數多是指定某類型的資源，也多是指定某個具體的資源
2. 根據參數找到所須要的資源，具體規則：根據參數從Model中獲取數據，固然數據通過了權限過濾
3. 返回給客戶端

針對這種狀況，相關的Controller的組織方案有不少：

• 不一樣類型的資源創建不一樣的Controller，在View中須要導航菜單的地方呼叫導航菜單的Controller，在View中須要組織結構的地方呼叫組織結構的Controller...
• 在單個Controller中經過不一樣的Action來處理不一樣類型的資源的訪問。建立ResourceController，在其中建立CreateNavMenu、CreateUser、CreateOU等Action
• 在單個Controller中經過同一個Action來處理不一樣類型的資源的訪問。在ResourceController中用一個名稱爲Create的Action來處理不一樣類型的資源的添加操做

後面兩種方案儘管將業務流程放入Controller中，而業務流程中的具體業務規則放入Model中，但因爲本系統中資源的類型是動態的，這兩種方法會讓Controller和View愈來愈不輕巧，或者Action個數愈來愈難以控制，或者Action內部的邏輯代碼愈來愈複雜。第一種方案將業務流程實際上分散在"組織"(這裏當動詞用，即增長一種類型的資源時，要增長對應的Controller)中了，當資源的類型愈來愈多時，只要遵循這個"分散的規則"就能夠優雅的增長新的功能，這不會減小代碼量的增長，但能持續保持代碼結構的清晰(這是從"管理"的角度來看這個結論而不是技術實現角度，對個人重構目標是合適的，若是你看到這篇文章，注意不要對你形成誤導)。

所以創建如下區域規則：

    建立名稱爲Core的區域，用來組織純粹的系統自身管理的Controller和View。本系統中後臺管理的基礎是資源，因此會有一個名稱爲ResourceController的控制器，

由於是後臺管理，從UI結構上來說重構後仍是典型的左右結構(左邊導航右邊操做區域)，主流的Web UI框架都有這種結構的Layout，從這個角度出發，第一個Controller是導航菜單(定名爲NavMenuController)，這個Controller就是單純的返回Json類型的導航菜單數據，經過JQuery在View中接收並顯示。而後會有身份驗證及受權兩個Controller，