从dojo.require的变迁看dojo设计的思想变化

dojo1.4的时候，我还在dojo.provide,dojo.delare来声明一个新module。从dojo1.7开始，dojo开始使用Asynchronous Module DeFinition (AMD)来声明一个新module.

dojo1.7之前

dojo.provide("my._TemplatedWidget");
dojo.require("dijit._WidgetBase");
dojo.require("dijit._TemplatedMixin");
dojo.declare("my._TemplatedWidget",[ dijit._WidgetBase,dijit._TemplatedMixin ],{});

dojo1.7之后

define([ "dojo/_base/declare","dijit/_WidgetBase","dijit/_TemplatedMixin" ],function(declare,_WidgetBase,_TemplatedMixin){
    return declare([ _WidgetBase,_TemplatedMixin ],{});
});

第二种方法好像少了module的名字，而不是像以前那样子declare("my._TemplatedWidget",[ _WidgetBase,{})。其实，名字已经不重要了，在dojo1.7中，重要的是获取module。为什么dojo1.7之后已经不重视module的名字了呢？后面我会讲到。

在1.7之前，每次想动态的加载一些module,可以用dojo.require,1.7之后，可以用新的require方法。

dojo1.7之前

dojo.require("dojo.dom");
dojo.require("dojo.fx") 

dojo.addOnLoad(function(){
    // The piece we had before…
    var greeting = dojo.dom.byId("greeting");
    greeting.innerHTML += " from Dojo!";
 
    // …but Now,with a fun animation!
    dojo.fx.slideto({
        top: 100,left: 200,node: greeting
    }).play();
});

dojo1.7之后

require(["dojo/dom","dojo/fx","dojo/domready!"],function(dom,fx){
    // The piece we had before…
    var greeting = dom.byId("greeting");
    greeting.innerHTML += " from Dojo!";
 
    // …but Now,with a fun animation!
    fx.slideto({
        top: 100,node: greeting
    }).play();
});

从上面的例子可以看出，dojo.require所需要的module都放入了define或require中的【】中了。这中新的设计模式被称为AMD。

dojo1.7以后几乎再也不需要类似以"."来连接的类名了。而是可以将所有的代码放入callback函数，然后使用require（[dependencies],callback)的形式来执行。callback里面再也没有长名字了，都可以使用module的local名字。

从以上例子可以看出，dojo自1.7以后，引入了Namespace和module类似的模式。类的名字已经不再重要，重要的是module的文件地址。module以文件地址作为namespace，主要为了能通过http寻找到module的地址并引入。这样就避免了1.7之前需要维护module名与文件结构所带来的混乱。1.7之后，只维护module的文件地址。回到上面的问题，为什么declare([ _WidgetBase,{})不再给类赋名了呢？看下面例子：

require(["my/_TemplateWidget"],function(MyTemplate){
    var instance = new MyTemplate();
});

使用module地址来引入module，然后将里面定义的class赋予MyTemplate本地变量，在callback函数中只需要使用本地变量名就可以了。

Require的参数dependencies里面包含两类，一类是真正的依赖的类，另一类是插件。比如["dojo/dom","dojo/domready!"]，dojo/domready就属于插件，意思是当dom解析完毕以后再执行callback。对于依赖，如果不存在，dojo回去加载。当加载完成之后，将执行callback函数。

以上介绍了AMD中的MD部分，A还没说。1.7之前的dojo.require使用的是同步XHR来获取js的，拿到的js内容使用eval函数，使js文本编程真正的js，同步XHR会block所有的js执行，可见效率多么的低。而1.7之后的require是使用重建<script>的方法来加载需要的js文件的，在script上注册"load"事件的监听。可见其是异步的，并且少了eval，效率提高了很多。综合起来，就成了AMD。

无论dojo.require还是require,都需要对散文件发送http请求。建议对常用的module进行压缩，使用dojo的build system把用的所有module都压缩到一个dojo.compressed.js文件中。一次请求获得多有的module。

AMD的风格带来的好处

1，异步加载，安全和效率均提高

2，代码干净，风格统一，不用再见到很多的dojo.xhrPost,dojo.io.iframe,dijit.Menu.

3，提供插件的功能，简化一些事件的处理。

。。。应该还有，想不起来。

原文地址：https://www.jb51.cc/dojo/291545.html

从dojo.require的变迁看dojo设计的思想变化

相关推荐