来自本人博客:http://ilovespringna.com/typecho/index.php/archives/34349/
这几个月一直在鼓捣的Cold框架,在自己的思考和借鉴了一些已有框架的方法后,算是有些成果了。尝试先写点小结,作为阶段性的巩固,因为代码越写越多,连自己都有些看不懂了。 在开始理清Cold的结构前,有几个关键的问题:
1、模块的颗粒度问题。
因为Cold现阶段的本质是利用前端的方式解决按需载入这一需求,因此每一个模块对应一个js文件,在应用中也相应地多出一个请求。如果像类似百度tangram以方法为粒度进行调度,便会多出成百上千个请求。或是极端考虑,整个框架为粒度(jquery,单文件模式),按需调用就没有意义。因此,需要在代码冗余度和请求数之间做平衡。2、命名空间和模块名。
这里有三个术语:模块的文件路径,模块名,模块对象。其中模块名是唯一标识模块的主键,模块对象是在内存里命名空间中安排的位置,文件路径则是文件的物理位置,用于引用文件。 因此一个模块的元数据可能如下:{ name : 'dragable', filesrc : '/cold/component/dragable.js', namespace : 'Cold.dragable' };这样在声明和使用一个模块时,开发者需要分别指明这个模块的名称,路径,和模块对象,既容易冲突、难以记忆,而且需要多余的文件进行管理存储,这是我不喜欢的。 比如我声明了另一个模块dialog时,其依赖于模块dragable,那么理想的代码如下:
define('dialog',{ requires : ['dragable'] },function(){ //do sth. });define在得到dialog的依赖项dragable后,并不知道dragable在哪,也不知道dragable在什么命名空间下,需要去别的文件中找到这个关系才能进行引用。因此Cold框架希望能够将这三个名称进行统一,本质上是模块定义的单一性。
3、模块依赖。
上面提到了我理想的模块依赖模型:开发者只需要在一处地方定义新的模块,只需要提供一个统一的模块标识符,在他的定义代码中能够做完所有的事,不需要重复定义和存储。模块依赖模型需要处理两个问题:递归依赖和循环依赖。 递归依赖,即模块a需要模块b,模块b需要模块c,形成一条a—b—c的依赖链。在这种情况下,c的定义代码必须先执行,然后是b,然后是a,而文件载入的顺序则可以随意。 循环依赖,即模块a需要模块b,模块b又需要模块a,这样就形成了无穷依赖,实际上是一个逻辑错误。 解决上面三个问题是Cold模块载入机制的目标。下一篇文章具体阐述Cold的结构和模块载入机制。