永遠的MVC ======== [MVC][0] 是對軟件軟件系統三個基礎部分的描述, 就好像[馮·諾伊曼結構][1] 或者[哈佛結構][2]對計算機體系結構的定義. MVC 是客觀存在的, 是事實. - 無論你的代碼中是否顯示的使用了 MVC 的方法, 她都存在. - 無論你的代碼是否顯示的遵循 MVC 的方法, 她都存在. - 無論你的代碼是否違背了公認的 MVC 方法, 她都存在. 總之只要你寫代碼, 無論你怎么寫, 她都存在. 對于一個運算表達式: ```go a := b + c ``` 又或者對于一個函數: ```go func Foo(b,c interface{})(a interface{}){ // 函數主體, 完成的就是控制了 } ``` - a 就是 view - "+" 就是 controller - b,c 就是model **MVC在心中** ## 常見的方法 開發者通常會這么做: - 類型聲明, 包含 `Controller` 這個詞 - 文件名, 包含 `Controller` 這個詞 - 目錄名, 包含 `Controller` 這個詞 在名稱上顯示出來是好方法. 這增強了代碼可讀性, 一目了然. 當然如果目錄名已經用了`Controller`了, 目錄之下的文件或者類型聲明是否有必要再加上 `Controller`, 語言不同, 習慣不同, 并沒有定式. Go 語言一向提倡 **能省則省**. 依據 MVC 目錄看起來是這個樣子 ├───conf ├───controllers // 這里面因歸屬關系又嵌套了 N 層 │ └───something ├───models └───views ├───login └───signup 典型的**樹狀結構**增強了代碼可讀性, 是常見 MVC 目錄組織形式. TypePress的方法 =============== 能保有樹狀代碼目錄結構無疑有助于管理維護. 基于 Martini Injector 風格下, 對象間的依賴被降低, 對象依賴關系不必遵循樹狀結構, 目錄結構也不必保持樹狀. 這在很多時候會更靈活, 同時這也是一種不常見的方法, TypePress 將嘗試使用一些. ## 扁平目錄 意思是盡量降低目錄曾經深度, 視覺上不顯示依賴關系. 事實上這類似于組件獨立化. 如果代碼是輔助性的, 例如服務器端的 Handler, 那就表現為獨立的 Rep. 如果可以分組, 例如瀏覽器前端組件, 那就在同一個 Rep 下做扁平目錄. ## 自動注冊路由 **實驗性**想法, 目的是給應用生成工具提供基礎支持. 對于具體應用, 比如博客, 業務層面的控制器, 多具有層級關系. 其中還涉及角色控制和 http Request Method. 用 martini.Router 寫起來像這樣 ```go router.Get("/profile", roleAllow("Admin"),youHandler) ``` 如果用自動注冊路由寫起來像這樣 ```go core.AutoRouter(youHandler) ``` 前提是要把 path,method,role 寫到文件路徑里. 對應上面的例子, 完整的運行期路徑寫起來有這樣幾種 - github.com/UserName/RepName/Admin/GET/profile.go - github.com/UserName/RepName/Admin/GET.profile.go - github.com/UserName/RepName/Admin.GET.profile.go 都是能被識別的寫法, 依據大小寫和"/","."作為分割符號實現自動注冊路由是可能的. 由此設計出自動構建/裝配工具就有了基礎.**TypePress 將嘗試這種方式**. [0]: http://zh.wikipedia.org/zh/MVC [1]: http://zh.wikipedia.org/wiki/%E5%86%AF%C2%B7%E8%AF%BA%E4%BC%8A%E6%9B%BC%E7%BB%93%E6%9E%84 [2]: http://zh.wikipedia.org/wiki/%E5%93%88%E4%BD%9B%E7%BB%93%E6%9E%84