Love.Passion.Dream

浅谈前端模块划分和MVC的关系

写这篇文章主要是对自己开发了近一年来的javascript富客户端产品所做一个框架层次的总结。涉足前端开发一年多,也基本都接触的是包含大量javascript的富客户端产品的开发。上万行的代码必然需要考虑下代码的组织维护,需要考虑一些框架的问题。虽然我也从来没有开发过一些纯页面的JS代码不超过100行的项目,但是也能感受到前端的变化,能够感觉得到前端对于框架的急迫需求。然而我也没有达到开发真正意义框架的高度,但是也不妨做一下前期的探索。

先谈谈模块划分吧,引自seajs官网的话是说:

SeaJS 的最大好处是:提升代码的可维护性。如果一个网站的 JS 文件超过 3 个,就适合用 SeaJS 来组织和维护代码。开发的代码越多,SeaJS 就越适合。

可以看到像seajs这样的模块加载器起到的做用是对大量的JS代码做一个划分和管理。但是这样看来,其实模块加载器更重要的是起到了一个工具的作用,实际上关键的是我们自己需要把程序模块化,哪怕是简单的用function包装起来。所以只是简单的利用这些模块加载库实现对于代码的一个模块化管理还不够。这样其实和写在一个js文件中但是代码却通过不同的function把功能划分得很清楚的代码没有什么分别。

那模块划分是否应该涉及到MVC的划分?如果采用了MVC的架构开发一个项目,是否需要用seajs这样的模块加载器去划分M层V层和C层?

为了回答这个问题,先来找一个MVC的框架来研究一下,看看前端是如何来实现MVC架构的。就看看现在很火的backbone吧。

Backbone为复杂Javascript应用程序提供模型(models)、集合(collections)、视图(views)的结构。其中模型用于绑定键值数据和自定义事件;集合附有可枚举函数的丰富API; 视图可以声明事件处理函数,并通过RESRful JSON接口连接到应用程序。

backbone提供了一个类库来实现对MVC的一个划分,提供Backbone.View和Backbone.Model等方法来对代码进行一个封装。这样看来也和模块加载器有部分同样的目的,但是显然模块加载器只是提供了一个对代码的管理,Backbone实现的功能则更深层次的从设计模式上来提供了一个解决方案。

那项目中是否需要同时使用像seajs这样的模块加载器和像Backbone这样的MVC框架呢?是的,我想应该这么做,因为显然他们两个的作用是不一样的,应该是相辅相成的。比如说可以将Backbone的View和Model放在不同的模块中来使用,这应该是脑海中立刻能想到的念头。我在之前的项目中也尝试过这么做,但是感觉是过于强求了。最后得到的效果其实并不好。很生硬的吧M,V,C放在不同的模块中真心感觉只是把代码中不同的function分拆为几个文件来引用。结构任然让人感觉很混乱,也没有充分利用好模块加载器的工具应该有的作用。

我也一直在思考应该怎么去结合seajs和Backbone去管理组织代码。那不妨先研究下其他非浏览器端的语言是怎么实现的。以JavaEE为例子,它将view层的jsp文件放到一个文件夹中进行管理,各个controller也被打包为不同的类,model也独立出来与数据库关联。这可以看做就是模块划分吧。然后他们直接的关联则通过spring等框架来组织。这样看来似乎模块划分是为MVC这样的框架来服务的。也就是说是否可以这样理解:我们在浏览器使用框架做MVC等设计模式的架构,但是浏览器的局限性限制了一些代码上的管理,所以需要模块加载器这样的工具去辅助它?

这样看来现在的模块加载器似乎还不符合这样的要求,因为这似乎也脱离了模块加载器原本的功能。最后一番思想斗争之后我得出了这样的结论:

模块加载器是用来将项目按照功能划分,实现代码管理和按需加载的功能。而框架则应该在模块管理器管理的模块之下实现MVC等架构。但是至于该架构下的文件,模板等的管理则需要框架所提供的工具也就是一个更细粒度的模块加载器来管理,这个工具应该只是一个预处理的功能,不局限于浏览器。这样的工具有否?

这几天总算觉得项目的架构和代码结构让人感觉很不舒服,一直在寻找解决方案。在看那本Javascript Web富应用开发的书,也在了解其他各种框架。这篇博客也像是流水账似的头脑风暴写了出来。不过最后任然也没有找到好的解决方案,希望有谁看到了能够指点迷津。**
**