为什么选择 Dojo

Dojo的高门槛一旦跨过,必将别无所求。含义有二:第一,Dojo难学;第二,Dojo很强大。

这也揭示了本博客的目标:帮助大家用好Dojo这个优秀的Ajax框架。

在回答为什么选择Dojo之前,我们看看哪些人已经选择了Dojo:

Dojo支持者

既然能被众多著名IT公司支持,Dojo必然有它的独特之处,那就是:架构。

一个稳定、可扩展、可维护的架构是所有高质量应用的基石。如果所有人都按自己的思路随心所欲的写代码,那就不会有那么多软件方法学,设计模式的存在。Dojo在一定程度严格规定了这样的开发规则,这也是很多人难以上手的原因。

以典型的数据,逻辑,表现的三层架构为例,来看看Dojo中树(Tree)是如何设计的:

树形结构是各种开发最常用的一个组件,其本质是:一种数据表现视图,负责处理用户交互(逻辑)和内容展示(表现),不存储任何数据。Dojo中的树完全符合这样的本质,所有数据的存储和对数据的操作都是通过专门的DataStore来实现。

因此,当我们习惯性的想用Tree.addNode(text)这样的方法去增加一个节点时时,却发现方法不存在。而正确的做法是:通过DataStore来增加一条数据,Tree会自动的更新数据的变化到界面。修改删除节点也是同样的逻辑,甚至节点的按需载入(Lazy Load)也是DataStore的逻辑,而不是Tree的。这实现了数据层的分离。

同样,当我们习惯性的想给一个树节点的icon属性指定一个图片路径,来改变节点的图标,这在我们需要根据节点内容决定图标时很常用。但我们却会发现无法找到这样的API。正确的做法是派生一个新类,重写getIconClass方法去改变节点的CSS Class,再通过CSS来指定节点的图标。这实现了表现层的完全分离。

显然,这个Tree很难用。要创建一个树,我们首先得学会DataStore,熟悉它的API;还得知道如何从Dojo的Tree去派生新类来重写方法,这又要去了解整个Dojo的类的继承机制。很多人开始抱怨,Dojo真难用。但其实只要前进一步,就会海阔天空。

表面上看,这些架构和模式,增加了开发难度。而实际上,它却增加了代码的健壮性和可维护性。在这样一个实际开发代码只占整个项目时间10%的没有银弹的时代,架构才是提升整个软件质量的关键。良好的架构,可以大大降低整个项目的风险。而从Dojo中,我们能够潜移默化的学习到Ajax应用应该如何去设计。

很多时候,最好的选择就是自己最熟悉的工具。但如果恰好这个最熟悉的工具又是一个强大的工具,那将事半功倍。当你需要去开发一个长期的或者大量使用Ajax的应用,Dojo将是最好的选择。

从熟悉到习惯之后就会发现,Dojo的门槛其实并不高。

摘录自博客:
http://blog.csdn.net/dojotoolkit/archive/2010/06/12/5667003.aspx