漫话Ajax框架（二）

陈金洲观点

　　毫无疑问，AJAX被越来越多的接受。这不仅仅体现在技术的应用上，更体现在行业范围内的需求提升上。Web应用这种类型不仅仅被用在企业业务系统，更多被用在Web2.0应用中。这些应用意味着以前只能被几十人几百人使用的系统，突然之间会有几十万几百万的用户。用户有了更多选择，能够吸引用户驻留的，除了华丽的界面，那么就是流畅的操作界面和快速的响应。作为实现不打断用户操作的关键技术AJAX, 从吸引用户这一点上，具有不可替代的使命。

　　意味着华丽、AJAX的Web2.0应用同样也冲击着企业应用的需求。虽然没有统计数据，但可以看到越来越多的企业应用要求更直观的界面，更流畅的操作，更少的延迟。例如，在前两年，级联下拉框的实现，大多数的框架（或者应用）的实现是选中一个时刷新整个页面，然后根据选中的那个更新下一个下拉框的待选值列表。这个实现在今天看起来几乎是完全不可接受的，无论对客户还是对开发者。

　　开发者这边，去年还有关于AJAX几宗罪的讨论，然而现在看来，更多的讨论沉浸到了某一个具体技术中。在认清AJAX技术本质之后，更多的开发者或欣然接受，或用户要求，开始了AJAX相关技术的学习和使用。从我周围看来，曾经认为JavaScript是不太入流的语言的程序员，现在已然逐渐发现，JavaScript很有趣，很强大；用JavaScript实现很酷的网页效果，很有成就感，等等。

　　另外， AJAX这个词本身，早已远远超越了它所代表的本来含义。AJAX原本是异步的JavaScript和XML。然而一看到一个绚丽的网页（Web应用），几乎大多数人，具备Web相关知识的，第一个问题往往是：这用的AJAX吧？──AJAX现在几乎成为圆角、拖拽、绚丽、无刷新的代名词。当一个名称上升为一种概念、一种直觉的时候，我们应该知道，相关的技术应用到了什么程度。

　　现在几乎已经没有人手工与XMLHttp对象打交道，绝大多数的开发者都使用Buffalo, DWR, Prototype等辅助库、框架进行开发。

　　AJAX框架的选择

　　由于现在很少有人只用一种AJAX技术，我将AJAX框架的范围扩大一些，分为偏重展现、偏重传输、工具型三个部分。由于我自己的Web工作语言主要在Java, Ruby以及Python之间，以下的评价不包含PHP, .NET下的一些工具。另外，对自己开发的和它的主要竞争者DWR有主要的比较，其他的仅作泛泛评述，估妄言之。

　　偏重展现：YUI, Qooxdoo, Dojo

　　·YUI ：目前设计比较完整，美观，全面的界面工具库。

　　·Qooxdoo: 开源的另一种选择。

　　·Dojo: 比较完善的库结构，丰富的界面控件。

　　偏重传输：Buffalo, DWR

　　Buffalo特性：

　　1、基于prototype。如果你的AJAX应用也是基于prototype，那么可以减少重复加载prototype的带宽，并且获得相当一致的编程概念。

　　2、Bind: 提供了对结果数据的处理，直接将数据绑定到页面对象并展示，这是一个动人的特性。在2.0中，Bind能力更加强大，能够将值直接绑定到表单元素、表格、DIV/Span、甚至整个表单上。关键是这种绑定是无侵入并且与buffalo整体结构完全整合，对外表现只有一个简单的{{buffalo.bindReply}}或者{{Buffalo.Bind.bind}}即可。

　　3、序列化：Buffalo支持任意对象，任意深度，任意数据结构的Java到JavaScript以及JavaScript到Java的双向序列化，并且支持引用。

　　4、生命周期对象访问：1.2.4之前需要继承一个BuffaloService,从1.2.4开始就不需要继承了，引入了线程安全的BuffaloContext对象，只需要通过BuffaloContext.getContext()即可获得一个线程安全的引用，并且对Request的各种属性进行操作。

　　5、对Collection/Array的模糊处理：Buffalo中提供了对Collection/Array对象的模糊识别能力。例如：服务器端有一个方法需要List参数，客户端传递过去一个javascript数组就可以了，不需要费心的组装对象。

　　6、客户端组装对象：Buffalo支持在客户端组装对象，甚至可以直接将整个表单序列化为一个对象作为参数传给远程客户端。

　　7、对重载方法的处理能力：由于Java与JavaScript之间类型的不匹配，DWR的代码生成无法对重载方法进行处理。例如，sum(double,double), sum(int, int) DWR很可能不知道你要调用哪一个。从2.0开始Buffalo支持了对重载的处理。

　　DWR特性：

　　1、支持Batch，可以将多个Service函数调用放在一个XMLHttpRequest请求中完成。

　　2、Converter：可以转换任意类型的Java对象到JavaScript，并允许直接使用。例如：Customer类包含一个address变量，当AjaxCall返回Customer对象的时候，可以直接在Javascript中使用customer.address来获得Address的信息。

　　3、允许Expose部分函数和属性。（Buffalo无限制，可以访问Service中的任意函数。）

　　4、DWR2.0中提出了Reverse Ajax，提供在Java代码中来处理页面上元素的功能。

　　工具型：Prototype, JQuery, Dojo

　　·Prototype：得益于Ruby语言的设计，它使得你能够以几乎类似于编写Ruby的方式编写JavaScript。由于绑定在Ruby On Rails的发行包中，它成为近两年最流行的AJAX工具。早期它小巧灵活，现在由于加入太多的特性，日渐臃肿。目前1.6版本大小已经超过120K。

　　·JQuery：Prototype的主要竞争者。简单是它最大的优点。大多数常见的复杂操作、效果，JQuery的代码量能够比Prototype少50%以上。

　　·Dojo：采用类似于Java包的管理方式，实现按需加载JS。提供了全面的AJAX、DOM操作支持。然而需要在HTML TAG中嵌入额外的属性，使得网页不能遵守W3C标准，不少开发者对此耿耿于怀。

　　来自RIA框架的冲击？

　　我并不赞同这种说法，恰恰相反，我认为像Silverlight，Flex等这些RIA框架要考虑来自Web应用的冲击。Web领域几乎已经不存在技术壁垒，能做哪些，那些不适合，负载均衡等等已经有充分的资源可以参考。各种模式都可以灵活的应用到其中，各种测试工具（如Selenium网页测试工具）、开发工具支持得非常出色。而RIA框架要考虑的问题远远要比现在的Web应用多得多。除了RIA所承诺的更容易的实现华丽的效果──在多种JS库的支持下这些效果在Web下并非难事──他们有更多的问题需要考虑：资源的获取和释放，测试的支持，本地存储的问题，事件机制，状态的同步，客户机、服务器数据交互机制（序列化反序列化）等等。RIA想如同现在的Web应用般大规模，远不到时候。大多数基于RIA应用的考虑是让应用能够离线运行，然而与此同时浏览器也在发展，基于网页的本地存贮已经在Google Reader中可以实际使用。也许某一天浏览器就是一个完美的RIA平台，Web应用只需添加本地存贮支持就可以离线使用──类似于Flex、Silverlight的RIA技术，与Web应用，哪个更容易被接受，还真难见分晓。