JavaScript模块规范之AMD规范和CMD规范

模块化是指在解决某一个复杂问题或者一系列的杂糅问题时,依照一种分类的思维把问题进行系统性的分解以之处理。模块化是一种处理复杂系统分解为代码结构更合理,可维护性更高的可管理的模块的方式。可以想象一个巨大的系统代码,被整合优化分割成逻辑性很强的模块时,对于软件是一种何等意义的存在。对于软件行业来说:解耦软件系统的复杂性,使得不管多么大的系统,也可以将管理,开发,维护变得“有理可循”。

还有一些对于模块化一些专业的定义为:模块化是软件系统的属性,这个系统被分解为一组高内聚,低耦合的模块。那么在理想状态下我们只需要完成自己部分的核心业务逻辑代码,其他方面的依赖可以通过直接加载被人已经写好模块进行使用即可。

一、AMD

AMD就只有一个接口:define(id?,dependencies?,factory);

它要在声明模块的时候制定所有的依赖(dep),并且还要当做形参传到factory中,像这样:

代码如下:

define(['dep1','dep2'],function(dep1,dep2){...});

要是没什么依赖,就定义简单的模块,下面这样就可以啦

define(function(){
  var exports = {};
  exports.method = function(){...};
  return exports;
});

这里有define,把东西包装起来,那Node实现中怎么没看到有define关键字呢,它也要把东西包装起来,其实,只是Node隐式包装了而已..

RequireJS就是实现了AMD规范的

二、CMD

玉伯写了seajs,就是遵循他提出的CMD规范,比AMD稍微强大点,用起来感觉也方便些

三、AMD与CMD的区别

CMD相当于按需加载,定义一个模块的时候不需要立即制定依赖模块,在需要的时候require就可以了,比较方便;而AMD则相反,定义模块的时候需要制定依赖模块,并以形参的方式引入factory中

//AMD方式定义模块

define(['dep1','dep2'],function(dep1,dep2){
  //内部只能使用制定的模块
  return function(){};
});

//CMD

define(function(require,exports,module){
 //此处如果需要某XX模块,可以引入
 var xx=require('XX');
});

而SEAJS也有use功能也是需要先引入所有依赖的模块,如

//SEAJS.Use方式
seajs.use(['dep1','dep2'],function(dep1,dep2){
  //这里实现事务
});

四、插件支持

但全球有两种比较流行的 JavaScript 模块化体系,一个是 Node 实现的 CommonJS,另外一个是 AMD。很多类库都同时支持 AMD 和 CommonJS,但是不支持 CMD。或许国内有很多 CMD 模块,但并没有在世界上流行起来。

现在比较火的 React 及周边类库,就是直接使用 CommonJS 的模块体系,使用 npm 管理模块,使用 Browserify 打包输出模块。
不久的将来 ES6 中新的模块化标准,可能就都得遵循新的标准了,什么AMD、CMD可能到时也不会怎么用了。

但是目前来说,前端开发没有用模块化编程就真的out的了,而目前的模块化编程,本人还是建议用SEAJS,虽然很多插件需要追加或修改一小块代码才能支持。但改过一次就能反复使用,也不会影响其它标准的支持。总体还算是比较方便实用的。

单独解释AMD 与 CMD 区别到底在哪里?

看了以上 AMD,requireJS 与 CMD, seaJS的简单介绍会有点感觉模糊,总感觉较为相似。因为像 requireJS 其并不是只是纯粹的AMD固有思想,其也是有CMD规范的思想,只不过是推荐 AMD规范方式而已, seaJS也是一样。

下面是玉伯对于 AMD 与 CMD 区别的解释:

AMD 是 RequireJS 在推广过程中对模块定义的规范化产出。

CMD 是 SeaJS 在推广过程中对模块定义的规范化产出。

类似的还有 CommonJS Modules/2.0 规范,是 BravoJS 在推广过程中对模块定义的规范化产出还有不少??

这些规范的目的都是为了 JavaScript 的模块化开发,特别是在浏览器端的。

目前这些规范的实现都能达成浏览器端模块化开发的目的。

 区别:

1. 对于依赖的模块,AMD 是提前执行,CMD 是延迟执行。不过 RequireJS 从 2.0 开始,也改成可以延迟执行(根据写法不同,处理方式不同)。CMD 推崇 as lazy as possible.

2. CMD 推崇依赖就近,AMD 推崇依赖前置。看代码:

// CMD

define(function(require, exports, module) {
 var a = require('./a')
 a.doSomething()
 // 此处略去 100 行
 var b = require('./b') // 依赖可以就近书写
 b.doSomething()
 // ...
})

// AMD 默认推荐的是

define(['./a', './b'], function(a, b) { // 依赖必须一开始就写好
 a.doSomething()
 // 此处略去 100 行
 b.doSomething()
 // ...
})

虽然 AMD 也支持 CMD 的写法,同时还支持将 require 作为依赖项传递,但 RequireJS 的作者默认是最喜欢上面的写法,也是官方文档里默认的模块定义写法。

3. AMD 的 API 默认是一个当多个用,CMD 的 API 严格区分,推崇职责单一。比如 AMD 里,require 分全局 require 和局部 require,都叫 require。CMD 里,没有全局 require,而是根据模块系统的完备性,提供 seajs.use 来实现模块系统的加载启动。

CMD 里,每个 API 都简单纯粹。

4. 还有一些细节差异,具体看这个规范的定义就好,就不多说了。

(0)

相关推荐

  • JavaScript 开发规范要求(图文并茂)

    本人在开发工作中就曾与不按规范来开发的同事合作过,与他合作就不能用"愉快"来形容了.现在本人撰写此文的目的除了与大家分享一点点经验外,更多的是希望对未来的合作伙伴能够起到一定的借鉴作用.当然,如果我说的有不科学的地方还希望各路前辈多多指教.下面分条目列出各种规范要求,这些要求都是针对同事编码毛病提出来的,好些行业约定的其它规范可能不会再提及. 1.保证代码压缩后不出错 对于大型的JavaScript项目,一般会在产品发布时对项目包含的所有JavaScript文件进行压缩处理,比如可以利

  • JavaScript开发规范要求(规范化代码)

    本人在开发工作中就曾与不按规范来开发的同事合作过,与他合作就不能用"愉快"来形容了.现在本人撰写此文的目的除了与大家分享一点点经验外,更多的是希望对未来的合作伙伴能够起到一定的借鉴作用.当然,如果我说的有不科学的地方还希望各路前辈多多指教.下面分条目列出各种规范要求,这些要求都是针对同事编码毛病提出来的,好些行业约定的其它规范可能不会再提及. 1.保证代码压缩后不出错 对于大型的JavaScript项目,一般会在产品发布时对项目包含的所有JavaScript文件进行压缩处理,比如可以利

  • JavaScript 开发中规范性的一点感想

    可谓一劳永逸,不要重复造轮子:) 1.常用的方法统一放置 例如:在用户注册时,时常需要判断文本框中字符是否是汉字.英文.数字或邮箱地址等等.何不把这些方法统一放在一个脚本中,取名叫做utility.js呢? 复制代码 代码如下: //待需要时另存为一个js function isNull(obj) { if (!obj || obj.length==0 || obj=="") { parent.MyAlert("标注名不能为空!",alertImg); return

  • js 编写规范

    在一个项目中大量使用js,工程项目与网站开发有一些不一样,在我接触的工程项目中普遍使用js 不够多,大部分客户端可做事,交给了服务端,而且在使用js时不够规范,很容易造成代码难以阅读.内存泄漏问题,不注意js 输写方式.而在网站开发中(尤其一些大网站,js输出的非常漂亮.完美无论使用jquery,还是prototype 框架,还是不用框架,都有自己良好一套东东可用) js输写最好还是可以面向对象方式 用类方向进行包装 js输写两种方式 闭包 原型 闭包:(借用的一个例子) 复制代码 代码如下:

  • javascript代码规范小结

    1. Javascript代码应符合Douban-JSLint检验标准 1-1. 语句必须都有分号结尾,除了for, function, if, switch, try, while 1-2. 只有长语句可以考虑断行,如: TEMPL_SONGLIST.replace('{TABLE}', da['results']) .replace('{PREV_NUM}', prev) .replace('{NEXT_NUM}', next) .replace('{CURRENT_NUM}', curre

  • 浅析JavaScript中的CSS属性及命名规范

    许多CSS样式属性的名字中都有连字符,在JavaScript中,连字符被解释为减号. 因此,CSS2Properties对象的属性名和真正的CSS属性名有点不同. 如果一个CSS属性名含有一个或多个连字符,在JS中则需要删除了连字符,并且原来紧接在连字符后的字母改为大写. 要注意的是float是JS的关键字,所以在JS中float被写作cssFloat与或floatStyle. 下面是CSS自身属性与JavaScript中CSS编码对照表: 盒子标签和属性对照:CodeCSS语法 (不区分大小写

  • 超全面的JavaScript开发规范(推荐)

    这篇文章主要介绍的是关于JS的命名规范.注释规范以及框架开发的一些问题,首先来看看目录. 目录 1. 命名规范:介绍变量.函数.常量.构造函数.类的成员等等的命名规范 2. 注释规范:介绍单行注释.多行注释以及函数注释 3. 框架开发:介绍全局变量冲突.单全局变量以及命名空间 一.命名规范 驼峰式命名法介绍: 驼峰式命名法由小(大)写字母开始,后续每个单词首字母都大写. 按照第一个字母是否大写,分为: ① Pascal Case 大驼峰式命名法:首字母大写.eg:StudentInfo.User

  • JavaScript之编码规范 推荐

    一.命名 1.应给变量和函数取一个含义确切的名称,不要随意命名. 2.非构造函数采用驼峰命名法,尽量采用动宾结构,以与变量名相区别,如getName或IsFull.构造函数(即自定义类型)名称首字母大写,以与非构造函数相区别,如Person. 3.变量采用驼峰命名法.由于JavaScript是一种弱类型语言,因此建议在变量名称前加前缀:整形(i),浮点数(f),布尔型(b),字符串(s),数组(a).但不强制这么做,可根据个人爱好选择,选择好后就不要混用加前缀和不加前缀这两种方式了. 二.布局

  • JavaScript的代码编写格式规范指南

    对于熟悉 C/C++ 或 Java 语言的工程师来说,JavaScript 显得灵活,简单易懂,对代码的格式的要求也相对松散.很容易学习,并运用到自己的代码中.也正因为这样,JavaScript 的编码规范也往往被轻视,开发过程中修修补补,最终也就演变成为后续维护人员的恶梦.软件存在的长期价值直接与编码的质量成比例.编码规范能帮助我们降低编程中不必要的麻烦.而 JavaScript 代码是直接发送给客户浏览器的,直接与客户见面,编码的质量更应该受到关注. 本文浅谈 JavaScript 编程中关

  • 现如今最流行的JavaScript代码规范

    什么是最佳的JavaScript代码编程规范?这可能是一个众口难调的问题.那么,不妨换个问题,什么代码规范最流行? sideeffect.kr通过分析GitHub上托管的开源代码,得出了一些有趣的结果.一起来看看吧. 行末逗号对行首逗号行末引号: 复制代码 代码如下: var foo = 1,     bar = 2,     baz = 3; var obj = {     foo: 1,     bar: 2,     baz: 3 }; 行首引号: 复制代码 代码如下: var foo =

随机推荐