Dojo框架：误解与现实[转载]

随着Ajax技术的流行，愈来愈多的Web应用使用Ajax技术来提升用户体验。使用Ajax技术的一个重要优点是不须要额外的浏览器插件支持，只须要使用浏览器原生的API，并利用JavaScript来操做便可。使用原生API时会遇到的两个比较大的问题是浏览器兼容性和底层A代PI接口带来的编程复杂性。一样的功能在不一样的浏览器上的实现方式是存在差别的。若是一个应用但愿支持不一样的浏览器，则开发人员须要添加不少的浏览器检测或嗅探的代码。好比一样的事件绑定功能，在IE上使用attachEvent，而在其它浏览器上则使用addEventListener。除了兼容性问题以外，浏览器提供的原生API的接口通常都比较适合用来执行细粒度的操做。当须要完成一些相对复杂的操做的时候，使用原生API接口会使得代码比较繁琐。以一个DOM查询为例：在当前文档树中查找给定ID的节点的全部给定标签的直接子节点。对于这样一个查询，使用原生DOM API的话，则会须要使用getElementById来查找节点，经过childNodes来获取子节点列表以及比较节点的标签名称等。所要求的码量会比较大。

JavaScript框架的出现，正是为了解决这两个比较大的问题，而不一样的JavaScript框架也提供了各自额外的附加价值。目前可使用的JavaScript框架很是之多，比较流行的也有十多种。这些流行的JavaScript框架包括jQuery、Dojo、YUI、MooTools、Prototype、Ext JS、Google Closure等。这些不一样的框架有着各自不一样的优点和不足，也有着对应的不一样的适用情景和范围。因为工做的关系，笔者对Dojo框架的使用最多，对于其它框架也有必定的了解。本文的目的是但愿澄清一些对于Dojo框架的误解，从而帮助开发人员选择合适的框架。

在开始以前，首先简要介绍一下Dojo框架的基本结构。Dojo框架由四个部分组成：Dojo基本库、核心库、Dijit和扩展库。基本库包含最基本的功能，核心库是基本库的扩展，Dijit是用户界面库，而扩展库则是各式各样的扩展组件。

 

知足Ajax应用开发基本的需求

Dojo和其它框架同样，都试图知足Ajax应用开发中的最基本的需求。这些基本的需求包括前面提到的浏览器兼容性和原生API的接口粒度问题，以及一些典型的应用场景。具体来讲，应该包括下面一些功能集：JavaScript语言加强、XMLHttpRequest封装、DOM查询与操做和事件处理等。而浏览器兼容性体如今这些功能集在不一样浏览器上的效果是同样的。

从Dojo框架来讲，对这些功能集的支持是比较丰富的。在JavaScript语言加强方面，对数字、字符串、日期类型、数组和JavaScript方法等有不少的加强功能。在I/O传输方面，除了经常使用的XMLHttpRequest 以外，还支持iframe和<script>等。dojo.query提供了相似于jQuery的DOM查询和操做的能力。 dojo.connect不但能够用来绑定DOM元素上的事件，还能够链接到JavaScript方法的执行上。

上面提到的这些基本功能都出如今Dojo基本库和核心库中。打包压缩以后的代码大小在80K左右，不会对整个页面的代码量形成很大的影响。

 

面向对象JavaScript与函数式JavaScript

面向对象的编程思想是目前比较流行的一种编程方法学。这种编程思想也被主流的编程语言所支持，包括Java、C++和C#等。不少开发人员都习惯于用面向对象编程思想中的类和对象的概念去进行分析和设计，再用相应的编程语言来完成实现。面向对象编程思想中的封装、继承和多态等概念，也比较适合对真实的问题域进行分析和抽象。在某些Ajax应用中，前端部分的逻辑比较复杂，同时也须要实现一部分业务逻辑。所需的代码量已经不是几个简单的方法这个级别，而须要进行完整的建模、分析和设计。不少开发人员会天然而然的使用面向对象的编程思想对Ajax应用的前端进行分析和设计。可是JavaScript语言并非一门面向对象的编程语言，它在不少方面都不一样于传统的面向对象编程语言。所以在从分析和设计到实现的过程当中，会出现阻抗不匹配的状况。对于这种不匹配的状况，解决的办法不外乎两种：一种是改变分析和设计时的思路，而另一种则是对JavaScript语言进行面向对象方面能力的加强。

JavaScript语言在设计的时候，就带有一些面向对象编程语言的影子，如new操做符和经过原型（prototype）能够实现的继承机制等。经过JavaScript的这些语言特性，能够实现完整的面向对象能力。Dojo框架所提供的面向对象方面的能力很是完备。最典型的用法是能够经过dojo.declare()方法来声明一个类，而且能够支持多继承。使用Dojo能够很快的写出经典的支持多继承的面向对象的示例，如：

dojo.declare("Human", null, {
  think : function() {}
});
dojo.declare("Machine", null, {
  work : function() {}
});
dojo.declare("Robot", [Machine, Human], {
  turingTest : function() {}
});

Dojo经过其面向对象JavaScript的支持，在必定程度上解决了前面提到的阻抗不匹配的问题。可是在全面使用Dojo提供的面向对象JavaScript 的能力的时候，要注意会带来的一些风险。首先要理解的是函数在JavaScript中是一等公民，能够做为对象的属性以及函数的参数和返回值来使用。 JavaScript中的闭包也是一个很是强大的概念，妥善使用的话能够写出简洁而强大的程序。若是彻底按照Dojo所抽象出来的面向对象的方式来使用 JavaScript，会丢失掉JavaScript语言自己的一些好的特质。因此不建议开发人员一开始就深刻到Dojo的面向对象JavaScript 的世界里面，而是首先多了解一些JavaScript语言自己的特征。好比理解JavaScript中的原型链（prototype chain）、this的含义、new操做符、执行上下文（execution context）和做用域链（scope chain）等。不然的话，一旦造成了思惟定势，可能会没法理解其它框架或是库的实现方式，毕竟不是全部的库都采用了Dojo这样的方式来实现。其次要认识到在性能方面可能带来的影响。熟悉Java的开发人员可能都习 惯于在设计的时候使用不少个细分的Java类，这些类之间经过精细的协做来完成具体的任务。这对Java来讲是合理的。而对于运行在浏览器中的 JavaScript这种解释执行的语言来讲，过多的对象和消息传递会对性能形成必定的影响，而性能又是Ajax应用中须要关注的重要因素。

面向对象编程的思想进入到Web应用的前端开发领域，是一件好的事情。它使得广大前端开发人员能够用本身熟悉的方式来设计和开发Web前端。可是在 JavaScript语言自己和浏览器这个运行平台的双重限制下，须要适度的使用，不过将来的前景是乐观的。JavaScript是ECMAScript的方言之一，目前的实现基本都遵循的是ECMAScript第三版规范。而ECMAScript第五版规范已经发布。值得一提的是，ECMAScript第四版尝试在JavaScript中引入类、包和名称空间等概念，不过因为各类缘由被放弃了。而第四版的这些思想造成了新的正在开发中的ECMAScript Harmony项目。按照标准化过程的速度，短时间以内JavaScript语言是不会拥有传统面向对象编程语言的类的结构，而包和名称空间的结构则须要等待更长的时间。不过这一天终会到来。随着V8、Chakra、SquirrelFish和Carakan等新的JavaScript引擎的出现，JavaScript语言自己的执行性能将会有大幅度的提高。这两个方面的改进会使得以面向对象的思想编写JavaScript程序变得更加天然。

Dojo的复杂度太高

Dojo是一个庞大和复杂的库，其中包含数以百计的模块。每一个模块都有本身的源代码、测试用例、演示页面和文档说明等。从这个角度来讲，Dojo的复杂度高于jQuery等其它框架。对于Ajax应用来讲，有两种常见的风格：Ajax Lite和Ajax Deluxe。对于Ajax Lite风格的Ajax应用来讲，jQuery等轻量级框架是比较好的选择，能够很方便的对页面作出修改。只使用Dojo基本库也是不错的选择。对于Ajax Deluxe风格的应用来讲，Dojo能够体现出它的价值。在开发风格的复杂Ajax应用时，一套完整的用户界面组件库是很是有必要的，能够极大节省开发人员的时间。在这个层次上，Dojo和jQuery采用了不一样的作法。jQuery很是小巧灵活，暴露给开发人员的概念很是少。$、CSS选择器和方法级联，就已经差很少是所有了。社区也贡献了很是多的jQuery插件，丰富了jQuery自己的功能。这是一种自下而上的作法，先有一个稳健的基础，再依靠社区的力量发展壮大。Dojo的作法则正好相反。Dojo中已经集成了不少模块，知足各类不一样的需求。这些模块背后都体现了相同的设计思想。以用户界面与数据的关系为例，Dojo定义了dojo.data API来抽象异构数据源的访问接口。须要访问数据的用户界面组件都经过此API来访问数据。这种作法带来的问题是暴露给开发人员的概念过多，给开发人员的感受是完成一件简单任务的起步就很是困难。不过这种作法也为框架自己的维护和扩展带来了方便。当构建一个复杂的Ajax应用的时候，这种复杂性有时候是很是必要的，尤为在团队工做的时候。对于一个复杂的问题，老是会须要一些稍微复杂的设计来保证解决方案的可维护性。与其选择本身去处理它，还不如交给一个设计良好的框架来完成。

对于开发Ajax Lite风格的Ajax应用来讲，也能够从Dojo基本库开始。当须要的时候再考虑Dijit库。

Dojo不易上手，学习曲线较陡

前面提到了Dojo的复杂性，这种复杂性会使得开发人员很难在较短的时间内入门。开发人员要理解和接受的概念过多。Dojo框架自己也提供了两种类型的编程风格，即前面提到的面向对象和函数式的方式。Dojo基本库和核心库比较多的采用的函数式的风格，好比dojo.connect()、dojo.xhrGet、 dojo.declare()和dojo.query()等。开发人员能够把这些方法当成工具来使用。对于Dojo基本库和核心库来讲，只须要查看相关的 API说明文档就能够知道每一个方法的参数、返回值和须要注意的地方。Dijit库则使用的是面向对象的风格。Dijit库包含的是一些用户界面组件，组件内部封装了相关的逻辑。开发人员须要经过new操做符来在页面上建立出组件的实例。这样的使用方式对熟悉Java图形界面组件库，如SWT/JFace和 Swing的开发人员来讲，是比较好理解的。而两种编程风格杂糅在一块儿，会对开发人员的理解形成必定的问题。在这点上，jQuery UI的作法就更加可取一些。在Dijit里面建立一个对话框并打开的作法是：

var dialogNode = dojo.query("#dialogNode")[0];
var dialog = new dijit.Dialog({});
dialog.open();

而在jQuery UI里面，使用的方式是：

$("#dialogNode").dialog({autoOpen : false});
$("#dialogNode").dialog("open");

jQuery UI在编程风格上与jQuery是类似的，采用的都是函数式的风格。这种一致性对开发人员来讲是更加合适的。

用户界面组件

在Ajax应用的前端界面部分，少不了用户界面组件的支持。HTML语言自己提供了一些基本的元素，包括常见的div、span和表单元素等。使用这些基本元素能够构造出复杂的用户界面。可是相对于桌面应用开发时可使用的组件来讲，HTML语言的这些元素仍是过于基本，没法快速高效的进行开发。好比一些常见的界面组件，如菜单、对话框、树形控件、表格控件、日期和时间选择器和富文本编辑器等，都须要开发人员本身来实现，不只耗时并且质量也比较难以保证。对于这种状况，Dojo框架提供了本身的用户界面组件编程模型Dijit，以及一些高质量可定制的标准用户界面组件。经过使用和定制这些标准组件，能够很快速的构建出应用的界面。开发人员也能够根据编程模型，开发出本身应用所需的特有组件。

从这个角度来讲，Dojo框架但愿提供的是与桌面开发类似的用户界面组件库，比较适合在集成开发环境中使用。开发人员经过拖拽的方式来添加组件，并设置组件的相关属性。经过这种方式，能够帮助开发人员更快的构建复杂的Ajax应用。Dijit库的好处在于提供了一个设计良好的Web应用前端组件编程模型，以及在这模型基础之上的众多参考实现。这就为建立一个良好的组件共享平台打下了基础。实际上，在Dojo扩展库中就已经有很多由社区贡献出来的组件。这个编程模型的一些优势在于：

• 完整的生命周期管理。从建立到销毁，生命周期中的不一样阶段都容许开发人员进行定制和扩展。
• 基于HTML模板的方式快速建立用户界面。支持在模板中以声明式的方式绑定 DOM元素和事件。
• 统一的组件接口，包括属性设置和获取和事件绑定等。
• 完善的主题支持，可定制的组件外观。

从前端开发人员的角度来讲，若是对用户界面的组件化是一个必要的设计考虑，则Dijit是一个比较好的起点。

Dojo的性能比较差

对于Web应用来讲，性能是一个很是重要的因素。既然JavaScript库是目前Ajax应用开发中必不可少的一部分，那么性能方面的差异会成为选择的重要因素。通常对Dojo框架的认识是速度很慢。实际上，影响Web应用性能的因素很是多，包括HTTP请求的个数、请求响应内容的大小、JavaScript代码的执行时间、页面元素的从新布局和排列次数等。把页面的速度过慢单纯归咎于 JavaScript库自己，是有失偏颇的。

对于Dojo库的一个比较常见的见解是Dojo库过于庞大，须要加载比较多的资源文件，致使页面的加载速度过慢。确实，与jQuery和Prototype等JavaScript库相比，Dojo库分发包偏大。Dojo 1.5的分发包是2M，而jQuery 1.4.4压缩以后的大小才26K。不过二者的功能是不一样的。Dojo库所提供的功能更多，所包含的代码量天然更大。形成这一缘由的问题在于开发环境和部署环境的不一样。对于jQuery来讲，开发环境和部署环境是相同的，只须要复制单个JavaScript文件便可。而对于Dojo则没有这么简单，这中间缺乏的步骤是构建过程。

Dojo采用的是模块化的设计，其中包含很是多的模块，分布在Dojo基本库、核心库、Dijit库和扩展库中。经过dojo.require能够声明在页面中须要加载的模块。这个加载过程会须要从服务器端下载所需的JavaScript文件，从而致使在运行时过多的HTTP请求。Dojo的构建系统会把来自不一样模块的JavaScript文件打包在一个文件中，只须要在页面上引用打包好的单个JavaScript便可。使用Dojo的构建过程，须要下载Dojo SDK，在utils/buildscripts/profiles目录下面添加一个构建文件，如myDojo.profile.js。在该文件中声明所须要包含的模块，如：

dependencies = { 
    layers: [ 
       { 
           name: "dojo.js",
           dependencies: [ 
                "dijit.layout.BorderContainer",  
                "dijit.layout.ContentPane", 
                "dojox.layout.ExpandoPane", 
                "dojox.image.Lightbox" 
           ] 
       } 
    ], 

    prefixes: [ 
        [ "dijit", "../dijit" ], 
        [ "dojox", "../dojox" ] 
    ] 
} 

再经过运行

build profile=myDojo 

action=release就能够启动构建过程，最后在release目录下面的就是能够直接复制到部署环境的Dojo库。Dojo的构建过程使用的是运行在Rhino上的JavaScript代码，能够很好的与Apache Ant集成。也能够选择使用其它图形化构建工具，如：Dojo Toolbox。

参考资料

• Dojo Campus文档
• Dojo官方网站文档
• 使用Dojo的Ajax应用开发进阶教程
• Dojo中文博客