前端mvc目錄設計的思考

在前端的富應用開發領域,也稱爲單頁應用,經常使用的目錄劃分方式有按照職責或按照功能模塊進行劃分

按照職責

app
    + /model
    + /view
    + /controll
    + /router
    + /lib
    + app.js

按照功能模塊

app
    + /admin
       + view.js
       + controller.js
       + router.js
       + model.js
    + /login
    + ...

以上兩種方式各有利弊,按照職責劃分,可以比較清晰的看出整個目錄的結構,可是當應用比較龐大的時候,每一個職責內部可能存在大量的文件,同時因爲文件的依賴並非按照職責來劃分,在維護上會產生較大的查找成本,而按照功能劃分則正好相反.由於文件的依賴是按照功能來劃分,因此頁面的多少不會產生一個維護上的困難,形成的問題主要是目錄總體結構不清晰.
有同窗會說,既然如此就把二者結合一下不就好了?

app
    /page
       /admin
         +view.js
         +...
    /lib
    app.js

經過提供一個page的容器層來隔離大大小小的功能模塊,這算是一種混合方法,但不管上兩種仍是這三種方法都不能解決的一個問題是,通用功能或模塊的抽象.譬如 admin 下有一個函數或者ui要被其餘模塊公用了,一般咱們會這麼作

app 
    /common
        +public-view.js  
    /page
         /admin
          +private-view.js
    /lib

這看起來不錯,可是隨着開發不斷推動,需求不斷變化最後可能變成這樣

/common
  +public-view1.js
  +public-view2.js
  +public-controll.js
  +public-model.js
  +public-function.js
  +public-ui.js

結果顯而易見,這種隨着業務推動而不斷重構的目錄劃分方式所致使的問題就是公用代碼的管理困難,形成這個問題的根本緣由在於,咱們一開始就沒有用寫代碼的方式去設計一個目錄,或者說缺乏最基本的目錄劃分方式,基於這點我獲得了這張圖

上圖中關於目錄層級的部分,可能你們會以爲很熟悉,尤爲結合上面的結構圖,就會發現 page 其實做爲app的子類來定義的,沒錯,這裏我用了繼承的方式來設計目錄結構,用代碼來講明就相似這樣

page extends app
  mod extedns ui

由於page是app的子類,因此page繼承過的來的目錄 mod store ui 均可以被輕鬆的轉移到父類中去,用代碼說明相似以下

//a頁面中有一個私有的mod
  page ->a ->mod
  //如今b頁面也想用這個mod,因而咱們把這個mod掛載到page的父類上也就是app
  app -> mod
  //因而如今b就能使用這個mod了

基於這種劃分的思想,不管應用的頁面多麼複雜,本質上來說依然只是app的一個子類擴展了page.js和router.js兩個文件而已.這樣咱們就不用爲了如何去思考文件該放哪,一個私有模塊變成公有了該怎麼辦這些頭疼的問題了,同時我對目錄下的文件也作了簡單的定義,確保目錄之間是非耦合的關係.

mod: 等於依賴外部數據的ui
 ui: 不依賴外部數據就能自我實現的頁面元件.
 store: 數據接口
 common: dom無關的函數

固然咱們所用的框架以及技術架構都不必定相同,因此基於這套簡單的目錄結構就能夠進行編程同樣的擴展,從而下降維護成本.