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方法的执行上。</p> <p>上面提到的这些基本功能都出现在Dojo基本库和核心库中。打包压缩之后的代码大小在80K左右，不会对整个页面的代码量造成很大的影响。</p> <h4>面向对象JavaScript与函数式JavaScript</h4> <p>面向对象的编程思想是目前比较流行的一种编程方法学。这种编程思想也被主流的编程语言所支持，包括Java、C++和C#等。很多开发人员都习惯于用面向对象编程思想中的类和对象的概念去进行分析和设计，再用相应的编程语言来完成实现。面向对象编程思想中的封装、继承和多态等概念，也比较适合对真实的问题域进行分析和抽象。在某些Ajax应用中，前端部分的逻辑比较复杂，同时也需要实现一部分业务逻辑。所需的代码量已经不是几个简单的方法这个级别，而需要进行完整的建模、分析和设计。很多开发人员会自然而然的使用面向对象的编程思想对Ajax应用的前端进行分析和设计。但是JavaScript语言并不是一门面向对象的编程语言，它在很多方面都不同于传统的面向对象编程语言。因此在从分析和设计到实现的过程中，会出现<a href="http://en.wikipedia.org/wiki/Impedance_mismatch">阻抗不匹配</a>的情况。对于这种不匹配的情况，解决的办法不外乎两种：一种是改变分析和设计时的思路，而另外一种则是对JavaScript语言进行面向对象方面能力的增强。</p> <p>JavaScript语言在设计的时候，就带有一些面向对象编程语言的影子，如new操作符和通过原型（prototype）可以实现的继承机制等。通过JavaScript的这些语言特性，可以实现完整的面向对象能力。Dojo框架所提供的面向对象方面的能力非常完备。最典型的用法是可以通过 dojo.declare()方法来声明一个类，并且可以支持多继承。使用Dojo可以很快的写出经典的支持多继承的面向对象的示例，如：</p> <pre>dojo.declare("Human", null, { think : function() {} }); dojo.declare("Machine", null, { work : function() {} }); dojo.declare("Robot", [Machine, Human], { turingTest : function() {} });</pre> <p>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应用中需要关注的重要因素。</p> <p>面向对象编程的思想进入到Web应用的前端开发领域，是一件好的事情。它使得广大前端开发人员可以用自己熟悉的方式来设计和开发Web前端。但是在 JavaScript语言本身和浏览器这个运行平台的双重限制下，需要适度的使用，不过未来的前景是乐观的。JavaScript是<a href="http://www.ecmascript.org/">ECMAScript</a>的方言之一，目前的实现基本都遵循的是<a href="http://www.mozilla.org/js/language/E262-3.pdf">ECMAScript第三版规范</a>。而<a href="http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-262.pdf">ECMAScript第五版</a>规范已经发布。值得一提的是，ECMAScript第四版尝试在JavaScript中引入类、包和名称空间等概念，不过由于各种原因被放弃了。而第四版的这些思想形成了新的正在开发中的<a href="http://ejohn.org/blog/ecmascript-harmony/">ECMAScript Harmony</a>项目。按照标准化过程的速度，短期之内JavaScript语言是不会拥有传统面向对象编程语言的类的结构，而包和名称空间的结构则需要等待更长的时间。不过这一天终会到来。随着<a href="http://code.google.com/p/v8/">V8</a>、<a href="http://en.wikipedia.org/wiki/Chakra_%28JScript_engine%29">Chakra</a>、<a href="http://webkit.org/blog/189/announcing-squirrelfish/">SquirrelFish</a>和<a href="http://my.opera.com/core/blog/2009/02/04/carakan">Carakan</a>等新的JavaScript引擎的出现，JavaScript语言本身的执行性能将会有大幅度的提升。这两个方面的改进会使得以面向对象的思想编写JavaScript程序变得更加自然。</p> <h4>Dojo的复杂度过高</h4> <p>Dojo是一个庞大和复杂的库，其中包含数以百计的模块。每个模块都有自己的源代码、测试用例、演示页面和文档说明等。从这个角度来说，Dojo的复杂度高于jQuery等其它框架。对于Ajax应用来说，有两种常见的<a href="http://ajaxpatterns.org/Ajax_App">风格</a>：Ajax Lite和Ajax Deluxe。对于Ajax Lite风格的Ajax应用来说，jQuery等轻量级框架是比较好的选择，可以很方便的对页面做出修改。只使用Dojo基本库也是不错的选择。对于 Ajax Deluxe风格的应用来说，Dojo可以体现出它的价值。在开发风格的复杂Ajax应用时，一套完整的用户界面组件库是非常有必要的，可以极大节省开发人员的时间。在这个层次上，Dojo和jQuery采用了不同的做法。jQuery非常小巧灵活，暴露给开发人员的概念非常少。$、CSS选择器和方法级联，就已经差不多是全部了。社区也贡献了非常多的<a href="http://plugins.jquery.com/">jQuery</a><a href="http://plugins.jquery.com/">插件</a>，丰富了jQuery本身的功能。这是一种自下而上的做法，先有一个稳健的基础，再依靠社区的力量发展壮大。Dojo的做法则正好相反。Dojo中已经集成了很多模块，满足各种不同的需求。这些模块背后都体现了相同的设计思想。以用户界面与数据的关系为例，Dojo定义了<a href="http://docs.dojocampus.org/dojo/data/">dojo.data</a> API来抽象异构数据源的访问接口。需要访问数据的用户界面组件都通过此API来访问数据。这种做法带来的问题是暴露给开发人员的概念过多，给开发人员的感觉是完成一件简单任务的起步就非常困难。不过这种做法也为框架本身的维护和扩展带来了方便。当构建一个复杂的Ajax应用的时候，这种复杂性有时候是非常必要的，尤其在团队工作的时候。对于一个复杂的问题，总是会需要一些稍微复杂的设计来保证解决方案的可维护性。与其选择自己去处理它，还不如交给一个设计良好的框架来完成。</p> <p>对于开发Ajax Lite风格的Ajax应用来说，也可以从Dojo基本库开始。当需要的时候再考虑Dijit库。</p> <h4>Dojo不易上手，学习曲线较陡</h4> <p>前面提到了Dojo的复杂性，这种复杂性会使得开发人员很难在较短的时间内入门。开发人员要理解和接受的概念过多。Dojo框架本身也提供了两种类型的编程风格，即前面提到的面向对象和函数式的方式。Dojo基本库和核心库比较多的采用的函数式的风格，比如dojo.connect()、 dojo.xhrGet、 dojo.declare()和dojo.query()等。开发人员可以把这些方法当成工具来使用。对于Dojo基本库和核心库来说，只需要查看相关的 API说明文档就可以知道每个方法的参数、返回值和需要注意的地方。Dijit库则使用的是面向对象的风格。Dijit库包含的是一些用户界面组件，组件内部封装了相关的逻辑。开发人员需要通过new操作符来在页面上创建出组件的实例。这样的使用方式对熟悉Java图形界面组件库，如SWT/JFace和 Swing的开发人员来说，是比较好理解的。而两种编程风格杂糅在一起，会对开发人员的理解造成一定的问题。在这点上，<a href="http://jqueryui.com/">jQuery UI</a>的做法就更加可取一些。在Dijit里面创建一个对话框并打开的做法是：</p> <pre>var dialogNode = dojo.query("#dialogNode")[0]; var dialog = new dijit.Dialog({}); dialog.open();</pre> <p>而在jQuery UI里面，使用的方式是：</p> <pre>$("#dialogNode").dialog({autoOpen : false}); $("#dialogNode").dialog("open");</pre> <p>jQuery UI在编程风格上与jQuery是相似的，采用的都是函数式的风格。这种一致性对开发人员来说是更加合适的。</p> <h4>用户界面组件</h4> <p>在Ajax应用的前端界面部分，少不了用户界面组件的支持。HTML语言本身提供了一些基本的元素，包括常见的div、span和表单元素等。使用这些基本元素可以构造出复杂的用户界面。但是相对于桌面应用开发时可以使用的组件来说，HTML语言的这些元素还是过于基本，无法快速高效的进行开发。比如一些常见的界面组件，如菜单、对话框、树形控件、表格控件、日期和时间选择器和富文本编辑器等，都需要开发人员自己来实现，不仅耗时而且质量也比较难以保证。对于这种情况，Dojo框架提供了自己的用户界面组件编程模型Dijit，以及一些高质量可定制的标准用户界面组件。通过使用和定制这些标准组件，可以很快速的构建出应用的界面。开发人员也可以根据编程模型，开发出自己应用所需的特有组件。</p> <p>从这个角度来说，Dojo框架希望提供的是与桌面开发相似的用户界面组件库，比较适合在集成开发环境中使用。开发人员通过拖拽的方式来添加组件，并设置组件的相关属性。通过这种方式，可以帮助开发人员更快的构建复杂的Ajax应用。Dijit库的好处在于提供了一个设计良好的Web应用前端组件编程模型，以及在这模型基础之上的众多参考实现。这就为创建一个良好的组件共享平台打下了基础。实际上，在Dojo扩展库中就已经有不少由社区贡献出来的组件。这个编程模型的一些优点在于：</p> <ul> <li>完整的生命周期管理。从创建到销毁，生命周期中的不同阶段都允许开发人员进行定制和扩展。 </li> <li>基于HTML模板的方式快速创建用户界面。支持在模板中以声明式的方式绑定 DOM元素和事件。 </li> <li>统一的组件接口，包括属性设置和获取和事件绑定等。 </li> <li>完善的主题支持，可定制的组件外观。 </li> </ul> <p>从前端开发人员的角度来说，如果对用户界面的组件化是一个必要的设计考虑，则Dijit是一个比较好的起点。</p> <h4>Dojo的性能比较差</h4> <p>对于Web应用来说，性能是一个非常重要的因素。既然JavaScript库是目前Ajax应用开发中必不可少的一部分，那么性能方面的差别会成为选择的重要因素。一般对Dojo框架的认识是速度很慢。实际上，影响Web应用性能的因素非常多，包括HTTP请求的个数、请求响应内容的大小、 JavaScript代码的执行时间、页面元素的重新布局和排列次数等。把页面的速度过慢单纯归咎于 JavaScript库本身，是有失偏颇的。</p> <p>对于Dojo库的一个比较常见的看法是Dojo库过于庞大，需要加载比较多的资源文件，导致页面的加载速度过慢。确实，与jQuery和 Prototype等JavaScript库相比，Dojo库分发包偏大。Dojo 1.5的分发包是2M，而jQuery 1.4.4压缩之后的大小才26K。不过两者的功能是不同的。Dojo库所提供的功能更多，所包含的代码量自然更大。造成这一原因的问题在于开发环境和部署环境的不同。对于jQuery来说，开发环境和部署环境是相同的，只需要复制单个JavaScript文件即可。而对于Dojo则没有这么简单，这中间缺少的步骤是构建过程。</p> <p>Dojo采用的是模块化的设计，其中包含非常多的模块，分布在Dojo基本库、核心库、Dijit库和扩展库中。通过<a href="http://docs.dojocampus.org/dojo/require">dojo.require</a>可以声明在页面中需要加载的模块。这个加载过程会需要从服务器端下载所需的JavaScript文件，从而导致在运行时过多的HTTP请求。Dojo的<a href="http://docs.dojocampus.org/build/index">构建系统</a>会把来自不同模块的JavaScript文件打包在一个文件中，只需要在页面上引用打包好的单个JavaScript即可。使用Dojo的构建过程，需要下载Dojo SDK，在utils/buildscripts/profiles目录下面添加一个构建文件，如myDojo.profile.js。在该文件中声明所需要包含的模块，如：</p> <pre>dependencies = { layers: [ { name: "dojo.js", dependencies: [ "dijit.layout.BorderContainer", "dijit.layout.ContentPane", "dojox.layout.ExpandoPane", "dojox.image.Lightbox" ] } ], prefixes: [ [ "dijit", "../dijit" ], [ "dojox", "../dojox" ] ] } </pre> <p>再通过运行</p> <pre>build profile=myDojo </pre> <p>action=release就可以启动构建过程，最后在release目录下面的就是可以直接复制到部署环境的Dojo库。Dojo的构建过程使用的是运行在Rhino上的JavaScript代码，可以很好的与Apache Ant集成。也可以选择使用其它图形化构建工具，如：<a href="http://o.sitepen.com/labs/toolbox/">Dojo Toolbox</a>。</p> <h4>参考资料</h4> <ul> <li><a href="http://docs.dojocampus.org/">Dojo Campus文档</a></li> <li><a href="http://www.dojotoolkit.org/documentation">Dojo官方网站文档</a></li> <li><a href="http://www.ibm.com/developerworks/cn/views/web/libraryview.jsp?view_by=search&sort_by=Date&sort_order=desc&view_by=Search&search_by=%E4%BD%BF%E7%94%A8+Dojo+%E7%9A%84+Ajax+%E5%BA%94%E7%94%A8%E5%BC%80%E5%8F%91%E8%BF%9B%E9%98%B6%E6%95%99%E7%A8%8B&dwsearch.x=14&dwsearch.y=13&dwsearch=Go">使用Dojo的Ajax应用开发进阶教程</a></li> <li><a href="http://blog.csdn.net/dojotoolkit">Dojo中文博客</a></li> </ul> <p>本文已经首发于<a href="http://www.infoq.com/cn">InfoQ中文站</a>，版权所有，原文为《<a href="http://www.infoq.com/cn/articles/dojo-misunderstanding-reality">Dojo框架：误解与现实</a>》，如需转载，请务必附带本声明，谢谢。 <br /><a href="http://www.infoq.com/cn">InfoQ中文站</a>是一个面向中高端技术人员的在线独立社区，为Java、.NET、Ruby、SOA、敏捷、架构等领域提供及时而有深度的资讯、高端技术大会如<a href="http://www.qconbeijing.com/">QCon</a> 、线下技术交流活动<a href="http://www.infoq.com/cn/qclub">QClub</a>、免费迷你书下载如<a href="http://www.infoq.com/cn/architect">《</a><a href="http://www.infoq.com/cn/architect">架构师</a>》等。​</p> </div> <div class="share_buttons" id="sharePanel"></div> <div class="article_next_prev"> <li class="prev_article"> <span>上一篇：</span><a href="http://blog.csdn.net/dojotoolkit/article/details/6076668">AMD规范：简单而优雅的动态载入JavaScript代码</a></li> <li class="next_article"> <span>下一篇：</span><a href="http://blog.csdn.net/dojotoolkit/article/details/6152243">使用Dijit实现界面组件化开发</a></li> </div> </div> <div id="ad_cen"></div> <script type="text/javascript"> new Ad(4, 'ad_cen'); </script>

查看评论

* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场

<script type="text/javascript"> var fileName = '6107003'; var commentscount = 3; var islock = false </script><script type="text/javascript" src="http://static.blog.csdn.net/scripts/comment.js"></script>

<script type="text/javascript"> new Ad(5, 'ad_bot'); </script>