公告栏里写到：Dojo的高门槛一旦跨过，必将别无所求。含义有二：第一，Dojo难学；第二，Dojo很强大。
这也揭示了本博客的目标：帮助大家用好Dojo这个优秀的Ajax框架。
在回答为什么选择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的门槛其实并不高。
by Nate，2010-6-12
