Dorado7与Extjs的比较

Dorado7与Extjs的比较

<!--[endif]-->

Dorado7和Extjs都是开源的Web展现层开发技术。表面上看似乎是相似度很高的两款产品，然而事实上他们之间存在很大的差别。究竟这两款产品各自适用于哪些场景呢？本文将从以下几个方面出发来对Dorado7与和Extjs做些比较。

产品功能设计方面的比较

众所周知，Extjs是一款优秀的前端Javascript库，拥有了一整套精美的界面控件。而Dorado7能做的并不仅限于此，对Web应用的开发者而言，Dorado7能够提供一个更加完备的生态系统。

要使用Extjs开发Web应用，开发者往往需要做很多前期的框架性工作。首先我们能想到的问题就是前端与后端如何进行数据交换，从Extjs提供的示例来看这似乎并不困难。然而对于真正的应用开发过程而言，这仅仅是一个开始，要让一个框架从可用变得好用、易用还有很长的路要走。

Dorado7的全称是Dorado展现中间件，从命名就可以看出Dorado7中有的并不只是Javascript，除了界面控件还包含大量的服务端Java实现，里面涵盖了展现层开发过程中所需要用到的大部分封装。所以，Dorado7提供的并不仅仅是控件，而是一种新的展现层的开发模式。

如果说Extjs、dojo等带来的是一种大量依赖Javascript的开发模式，那么GWT、JSF等就是另外一个极端，他们提倡尽可能的利用Server端的技术来掩盖对Javascript的需求，这么做带来的弊端就是大大增加了前后端之间的通讯次数。而Dorado7带来的则是介于两者之间的、集两者优点一种模式，Dorado希望在利用一些服务端技术降低界面开发复杂性的同时仍能充分发挥Javascript所具有的灵活性。要实现这种开发模式，必须依赖于大量的后端实现，就像GWT、JSF一样。

 

所以，Extjs和Dorado7其实并不是一个层面上的两个产品，一个是只包含Javascript的控件库，而Dorado7则是一种包含控件库的展现层开发框架。Extjs和Dorado7就好比咖啡豆和咖啡原液，咖啡豆固然可以泡成咖啡，但是大部分人并不知道该如何下手，手艺若是不精反倒会搞砸。

使用门槛和开发效率的比较

Extjs很强大，然而要把Extjs用好却并不是一件很简单的事，使用Extjs要求较高的Javascript技能。对于一个稍具规模的团队而言，通常只有少数几个人能够熟练的掌握Extjs的开发，这并不利于Extjs在大型项目团队中的推广。尽管Extjs推出已有相当长的时间，并且在业界享有相当高的声誉，但是事实上我们却很少在企业应用中看到Extjs的身影，Extjs更多仍只是掌握Geek们手中的*护手钩，更常被用在工具类产品中。

另外，Extjs的API虽然十分强大且灵活，但是利用Extjs开发出的页面的，其主要部分都是Javascript，大量的Javascript并不利于阅读和修改，因此Extjs对于项目的后期维护并不能带来正面的帮助。

Dorado7的设计初衷与Extjs不尽相同，Dorado7主要为MIS类Web应用的开发设计，因此在降低使用门槛方面投入了很多的精力。这里列举Dorado7中比较有代表性的两个特性来说明这个问题。

基于XML文件的界面开发模式

Dorado7在其默认的开发模式中抛弃了JSP，转而使用XML作为定义前端界面的主要形式。同时Dorado7还有专用的IDE(Eclipse Plugin形式)用以辅助这些XML的定义。这样设计的好处是可以大幅的降低产品的学习难度，同时提高应用的开发效率，降低后期维护的成本。近年来的很多展现层产品都采用了类似的模式并且获得了不错的反馈，例如SilverLight、XUL。

另外，您也不必担心XML的引入会降低Dorado7的灵活性。Dorado7的设计原则是利用XML配置文件快速的完成70%页面定义，然后通过用户事件、监听器等完成剩余的30%的客制化。这一设计理念始终存在于Dorado产品的中，在早期的Dorado5版本中就已经得到了很好的用户反馈。

以数据模型为核心的开发模式

由于MIS类Web应用中绝大部分逻辑都是在处理结构化的数据，因此Dorado7特别强调以数据模型为核心的开发模式。即Dorado7把界面中的数据提取出来变成一种独立的模型对象，同时把展现控件设计成可与数据模型进行绑定的数据敏感控件，使它们接受数据模型对象的管理。通过这种方式，我们把大部分的前端逻辑都提取并集中到了数据模型中。

例如当我们希望看到编辑框的值被自动设置为某数值的界面效果时，Dorado开发人员要做的并不是通过编辑框的API去修改编辑框的值，而是直接修改编辑框关联的数据模型中的属性值，然后数据模型会自动的更新编辑框中的显示。

这种设计可以带来诸多好处。首先，开发人员在普通的开发过程中接触到的API数量大幅减少，上手更快。其次，较为集中的页面逻辑代码有利于提高开发和维护效率。另外，开发人员也可以在开发过程中更加聚焦于业务逻辑本身的实现，不必频繁为琐碎的界面效果和API用法分散思维。

如果说Extjs是护手钩，那么Dorado7就是剑。 护手钩，练成后威力巨大，但难于练成，练习过程中多发自伤，属于奇门兵器。 剑，初学即能上手，练到深处，出神入化。

界面效果的比较

由于Extjs和Dorado7并不是同一级别的产品，所以前面的比较都变成了“有”和“无”的比较。接下来我们单独来看看两者中功能重合度较高的部分——界面控件。

单说展现效果，Extjs或许是目前业界做的得最好的。而Dorado7的展现效果十分接近Extjs的水准。看到这里或许您会有一个疑问，为什么Dorado7的前端不直接使用Extjs而是要另起炉灶？答案一小部分是因为Extjs的License，更重要的原因是Dorado7对前端的设计思路有着与Extjs不同的理解。

评价一套界面控件并不能只看展现效果，更要看它的整体设计。如前文所说，Dorado7特别强调以数据为核心的开发模式，又提出了独创的“立体数据模型”的概念。因此Dorado7从一开始就将这种特性融入到了控件的设计中。而对于已经成熟的产品如Extjs、dojo等，是很难在后期自然融入这些设计理念的。

 

综上所说，在前端控件方面，目前Extjs在控件表现力方面略微胜出Dorado7，在实现数据绑定方面则是Dorado7更加方便和自然，而这正是MIS类Web应用所需要的。放眼未来，在控件表现力方面，相信Dorado7可以借助其Addon扩展机制迅速的弥补与Extjs之间的微小差距。