传统Web框架 PK AJAX -来自BJUG邮件列表的讨论

本人对struts支持ajax一事，表示怀疑。。就如目前许多MVC框架所言：均支持ajax技术，但是哪个框架能将ajax很好的嵌入其中那？但也正是ajax的XMLHttpRequest具备良好的适应能力能够胜任从servlet到web
service的web模式。
但这不是ajax支持struts么？？怎么成为struts支持ajax呢？struts做了哪些工作用来支持ajax？？

David，我已经看过了dlee的文章：
正在翻译WebWork in
Action的网友Perhaps帮我去咨询了这本书的作者对于Ajax技术的看法。作者回复道：
WebWork is a web framework which provides some features that use AJAX
techniques. For example, WebWork provides a validation framework and
some AJAX functionality such that AJAX is used to validate form input
data within the browser, even though the validation rules are on the
server side.

仅仅是寥寥片语，对于Ajax所能起到的作用也局限在非常少的几个传统领域，即数据验证这样一类JavaScript的传统领地。由此我得出的判断是：看来作者对于Ajax的研究也不多。
由此我更进一步得出的判断是Struts/WebWork/JSF的开发者们都没有为即将来到的新世界做好准备！不是我狂妄，而是我确信他们并没有真正理解自从Ajax出现一年以来，Web开发技术的世界所发生的变化。

这个新的世界是什么呢？就是Ajax/Flash/XUL/XAML将会把我们带向的那个RIA应用的世界，是一个用户感受不再受到忽视的世界，是一个真正实现了所谓的“科技以人为本”的世界。

大家可以看看Ajax in Action的第5章，这本书电子版在很多地方都可以找到，便于大家看到我们的译文之后准备板砖。
在这本书中，将Ajax应用分成3种大的类别：
1. 以内容为中心的应用
2. 以脚本为中心的应用
3. 以数据为中心的应用

在目前Ajax框架领域尚未出现Killer级产品的过渡阶段，很多时候确实需要在现有架构基础上增加Ajax功能，以便改善应用的交互性。这种情况就是作者所谓的"以内容为中心的应用"。具体描述我就不多说了。
但是，从长远来看，Ajax技术的发展趋势是以数据为中心的应用。这一类Ajax应用是最复杂的，甚至还需要在客户端引入MVC架构。Ajax技术的发展现在已经超越了传统的Web开发架构（Struts/WebWork/JSF/ASP.NET），将来的发展趋势是，在客户端成熟的基于组件的Ajax开发框架配合强大的IDE开发工具，在服务器端成熟的业务层框架，两方面相互配合构成一种基于服务的架构。比较有可能的是这样一类组合：
客户端dojo或者其他强大的Ajax框架/组件库 + 服务器端Spring+Hibernate/iBatis通过Servlet暴露一些服务接口。
服务器端由大包大揽退化为一种服务提供者的角色，而将表现层的开发任务完全交给了客户端。客户端是使用Ajax/Flash/XUL/XAML一类技术建造的高度智能的客户端RIA应用。

这种基于组件的Ajax框架与JSF/ASP.NET的相同之处就是他们都是基于组件的。但是这里的核心差别是事件模型在什么地方。JSF/ASP.NET的事件模型位于服务器端，大部分用户事件都要到服务器端打一个来回，由此带来的延迟毁掉了软件的可用性。Ajax框架则可以在客户端处理大量的用户事件，并且主要以异步的方式来处理，这样相应性更加灵敏，对于用户工作流程的侵入就更小。所以Ajax这种基于组件的架构才是真正效仿VB和Delphi，而JSF的架构其实和VB/Delphi有着本质区别，不过是挂羊头狗肉罢了。我们什么时候可以把网络延迟完全忽略不计，那个时候估计共产主义也已经实现了。

to David
Lee，说得非常详细。ajax的思路已经超越了MVC框架，而且正中目前B/S模式的弊端——ajax对异步通讯的支持，使其可以将N个xmlHttpRequest同时发出，这样节省了没有必要的网络开销，而在接收到response后可以异步处理。我在这里将其暗喻为“http中的UDP协议“，而从前的非异步处理方式极为类似TCP协议模式——虽然很稳定，但是对网络资源的霸占可非同小可。

真如David所言：”我们什么时候可以把网络延迟完全忽略不计，那个时候估计共产主义也已经实现了。
“，Ajax在某些程度上速度是飞快的。这也是其对老式B/S框架的一大挑战。

而Ajax同时又采取了比较松散的形式很好的继承了原B/S结构中的servlet/service，摒弃了在页面之间冗余的post/get操作，我认为ajax正如一颗绚丽的钻石镶嵌在rich
client中。

回过头来再考虑一下mvc吧，很好的解决了应用模块的分割问题，让模块之间明显解耦。这终结了web项目难以维护/重构的顽症，但仍然是在不断的重新发明轮子。虽然有了模板的介入，但是还是存在在网络上的资源浪费。而且view层的tag也是根据各个开源产品的不同而五花八门，开发者在spring与struts之间移植view层几乎就是一次重写灾难。DRY思想就是不要自己重复做事，但往往事与愿违。

”web
Service“就成为了救 命稻草，无论我们的web框架是spring还是struts，只要提供遵循jsr的web
service，数据交换就不存在障碍。而view层可以使用灵活方便的ajax展现，并在使用中采用重构和模式的思路，这才是DRY。

远程数据交换使用直接的web request方式即可。webwork面向action和push mode的方式使得页面复杂的情况下，需要编写的文件数量和配置量很多， 也很难实现页面组件的重用

关于这些问题，我们都需要不断地思考。我不大赞成在现在就过早地给某些人的想法冠以"激进"的帽子，让我们联想到很多年前某论坛坛主把持J2EE舆论的时代。实际上，对于某些开发者"激进"的想法，可能早已是另外一些人应用了很多年的开发模式。

大家是否注意到我经常把Ajax和Flash、XUL、XAML等技术相提并论，有人可能觉得是在拉大旗做虎皮，但是仔细想想，其实这些技术的架构有非常大的相似性。同时这些新的RIA应用、Rich Client应用对于传统服务器端架构/框架所提出的新的需求，有些相当复杂的需求是原有架构无法满足要求的。WebWork能够处理的一类应用也仅仅限于以内容为中心的应用而已，而这仅仅是Ajax全部可能性的很小一部分。

话说白了吧：其实我想说的就是，Struts/WebWork/JSF对于精通Ajax技术的开发者来说都是鸡肋。Sun的那个所谓的blueprint纳入Ajax的目的，也仅仅是为了使得Ajax成为J2EE世界的顺民，很好地融合进传统的Struts/WebWork/JSF架构中。
Ajax是二等公民吗？当然不是，市场和最终用户何时如此热烈地追捧过Struts/WebWork/JSF？IBM、Oracle、BEA一旦发现Struts/JSF已经没有市场，就会果断地抛弃这些东西。

服务器端校验肯定是需要的，这些逻辑不能被看作是纯粹的表现逻辑。大部分表现逻辑在有成熟的Ajax框架的情况下，确实完全都可以用Ajax来做，这个和基于Flash做UI差不多是一个道理。甚至一些安全性要求不高的简单业务逻辑也可以在客户端做。服务器现在所做的就是应客户端的请求，在完成了身份鉴别后，为客户端提供它们所需要的数据，而客户端如何呈现这些数据，由客户端的脚本来决定。
robbin说的一些问题，在我看来并不是非常困难的问题。这类新的架构的安全性也完全有相应的解决方案。Ajax in Action其中有一章专门讨论安全问题。Ajax技术的发展甚至超过了我们学习的速度，很有可能我们现在的讨论对于某种框架来说，早已经解决了。这种状况有点像前年n多人争论EJB的问题的时候，其实J2EE without EJB已经成为国外的主流开发思想一样。

今年我们将会看到Ajax框架非常快速的进步，很多新的可能性都会发生。所以大家如果现在确实感觉接受起来比较痛苦，可以暂时先把这些讨论看作一个即将发生的一些变化的预言。