前端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无关的函数

固然咱们所用的框架以及技术架构都不必定相同,因此基于这套简单的目录结构就能够进行编程同样的扩展,从而下降维护成本.