AMD的规范演化

对于web项目来说,打交道的不仅仅有后台,前台页面也是少不了的,而前台的页面js也常常是我们后台程序员必须要使用的语言, 今天说下项目中的js的组织方式。

文件函数型

所谓文件函数型是指所有的js的脚本都是中都是一个一个的方法,没有任何的封装,这也是传统的项目中常用的方法。如下:

file1.js

1
2
3
4
function add(a,b){
return a+b;
}

file2.js

1
2
3
4
function minutes(a,b){
return a-b;
}

当我们想使用个方法的时候只需要应用相应的js就行了,这样的缺点很明显,就是要时刻明确文件之间的相互依赖关系的顺序,不然就会导致程序无法正常的运行。 比如还是上面的两个js,我在file1.js中有家一段代码:

file1.js

1
2
3
4
5
6
7
8
function add(a,b){
return a+b;
}

function sum(a,b,c){
return add(a,minutes(b,c));
}


如果在引用的时候,先引用的file1.js则会导致files1.js中有方法没有找到。 如果项目足够的大,就纯粹的js的依赖关系就足以让我们焦头烂额。

这种方法还有很多潜在的风险,如果我在file1.js中有定义了一个minutes方法,这样file2.js中的方法就面临被覆盖的风险,所以这种布局的方式,不应该是项目的首选。

jquery扩展型

在web的项目中,在面对dom操作的时候,传统的js的过于繁杂,所以jquery的使用应该占了很大的一部分的比重(确切的说在MVVM框架流行前)。

jquery也提供了两种扩展方法:   

  • 静态方法扩展    

    jquery静态方法的扩展是直接扩展到$对象上面 :

1
2
3
$.funcA=function(){
// do something
}

在任何引入jquery的地方都可以使用$.funcA()来调用

  • jquery对象方法扩展
1
2
3
4
$.fn.funcB=function(){
//do something
}

使用的方法: $(“#id”).funcB()来调用。

上面的方面解决了方法见的相互的依赖顺序问题,但没有解决方法被覆盖的问题,同时又带来了一个副作用,增加了js方法的调用深度,降低了js的执行效率。

模块加载型

模块话加载是对jquery扩展和文件方法的一个进化,把每个方法都用一个模块封装起来,不至于被外面的方法覆盖。

module1.js

1
2
3
4
5
6
7
8
var module1=function(){

return {
add:function(a,b){
return a+b;
}
}
}();

module2.js

1
2
3
4
5
6
7
var module2=function(){
return {
minutes:function(a,b){
return a-b;
}
}
} ();

如果想使用add方法可以直接引用module1.js,调用module1.add方法。

上面的方法解决的方法被覆盖的问题,但没有解决模块化依赖的问题,这个问题的解决就要靠我们下面要说的AMD的规范。

AMD模块开发规范

上面模块话的开发虽然解决的js的方法的覆盖问题,但js依赖的问题仍然存在,解决这个问题的终极方案就是AMD规范。

AMD规范就是其中比较著名一个,全称是Asynchronous Module Definition,即异步模块加载机制。从它的规范描述页面看,AMD很短也很简单,但它却完整描述了模块的定义,依赖关系,引用关系以及加载机制。

这里用requirjs来解释说明AMD加载的原理:

定义模块:

1
2
3
4
5
6
7
8
9
define(['math', 'graph'], 
function ( math, graph ) {
return {
plot: function(x, y){
return graph.drawPie(math.randomGrid(x,y));
}
}
};
);

上面代码 依赖math和graph两个库,在定义模块前声明了依赖。

引用模块:

1
2
3
require(['foo', 'bar'], function ( foo, bar ) {
foo.doSomething();
});

更多内容参见:
阮一峰-requireJS和AMD规范