技术评论与随想——AJAX、Rails、WebFramework

　　最近思考的问题，其实都是围绕着Web2.0的。Web2.0是什么呢？无数的人可以有无数的回答，我的理解是：Web2.0意味着用户体验更好的Web应用。最近业界也颇发生了几件大事，我来随手点评一下。

　　1、WebWork与Struts合并了。





　　为什么有这么大的反差？其实是在对WebWork的AJAX扩展上，有了分歧。robbin对于WebWork的这一进步同样评价很高。而Michael Chen和DLEE这些原本就做过不少AJAX应用的朋友就觉得是丑陋的。对于 WebWork Ajax 支持的失望(dlee)，而Michael Chen则附议到：“深有同感。不过我的观点在美感方面。前些日子scud在BJUG的聚会上做了一个关于Webwork2.2的topic，其中谈到webwork的ajax的支持。在我看来，那些remoteDiv, a, form的ajax标签，使用起来实在是丑陋不堪。当时跟冰云说，webwork现在的team leader一定不是 Richard Oberg了，否则他怎么能容忍这么丑陋的设计呢？”

　　再进一步问：“为什么对于WebWork的AJAX支持的评价上，有这么大的差别呢？”我的看法是：这就是立场不同所导致的了。究竟是站在传统Web框架的立场来看待AJAX呢？还是站在AJAX的立场来看待传统的Web开发。

　　站在传统Web框架的角度，“Ajax 其实不过是一堆 JavaScript、HTML 和膨胀的逻辑混合在一辆巨大的失事火车里面。”(dlee翻译的WebWork作者的一段话。)对于他们来说，AJAX就是一个必须闭着眼睛吞下去的一个苍蝇。以这样的态度弄出来的东西，能不丑陋吗？

　　站在AJAX的角度，来看传统Web开发，这个方面目前的确还不够明朗。打个比方，企业应用架构模式(PoEAA)由Martin Folwer总结出来以后，大家都觉得心里有底，脚下有根了。而现在呢？Web应用架构模式(PoWAA)呢？这个东西大家原来是有一套的，当AJAX出现之后，成熟之后，普及之后，我们也同样期待这有人来总结出新一代的，Web应用架构模式。注意是架构模式而非设计模式。这样的模式，现在似乎还没有出现。只不过站在AJAX开发者的立场来看，总结出这样的新模式，才是正途。

　　我现在因为要准备写一本AJAX方面的书，自然也就开始思考这方面的问题，在和李锟、泽欣等朋友的讨论中，也在思考这样的问题，举个例子，AJAX之后的MVC，控制层是不是可以完全放在客户端，而服务器端仅仅是一个模型层。说实话，还没有想清楚......

　　2、Java Web Alignment Group成立
　　这件事情让江南白衣相当的兴奋。在他的N个blog里都发布了这个Good News。据说有一堆大佬(达到36个之多)是这个Group的成员。我在白衣的blog下留了一句话： 突然想到一个场景，鹿鼎记里的江湖群豪，前明志士们聚在一起开的那个“杀龟大会”。为什么会有这样的联想呢？因为我从来对于这种所谓的大联合不抱幻想。

　　根本的原因在于，技术的事情，不是人多力量就大的，不是联合了就能够统一的，小舢板不是捆在一起就成立“航空母舰”的。为什么现在Java Web Framework如此分裂？为什么几十个框架斗不过一个Ruby on Rails？RoR的胜利，不是丰富的胜利，不是强壮的胜利，而是简单性的胜利。你几十个框架合在一起，只会更加复杂，更加烦琐，更加丑陋。这样的联合，根本就是连失败的原因都没想清楚。36个大佬，能在一起设计出一个框架来？Java界的权威们，谁服过谁了？

　　现在传统的Java Web Framework，一方面在面对各系其它语言的Rails的框架冲击，一方面又面对着AJAX新思维的冲击，新的架构模式尚未出现...。要搞出一个新的、Java的、快捷的、Web开发框架，任重而道远啊！

　　在QQ群里，江南白衣也颇有些想拉起大旗做一个框架的意思，现在还在七嘴八舌的阶段，嗯，我还是很期待的！

原文：
http://spaces.msn.com/members/zbw25/Blog/cns!1pA6-3FOo9yNp_4lmEHxdDqA!762.entry

“控制层是不是可以完全放在客户端，而服务器端仅仅是一个模型层。”

这个不大可能，起码在AJAX来说可能性不大，即使能够做到，从安全、性能等方面考虑也会在服务端实现一部分的控制。

问题在于要定出用户控制、业务逻辑如何在客户端和服务段之间分工的模式。

这个，臆测的成分太过了，而且我非常不喜欢动辄阶级分析论。Webwork的AJAX支持还比较原始，况且还在开发当中，退一步来说，AJAX世界现在本来就很混乱，没有什么非常主流和统一的东西强势出现，那么怎么指望能Webwork出来一统AJAX的江湖呢？

我之所以肯定webwork的AJAX封装的方向，和我究竟是Web派还是AJAX派无关，什么好用就用什么，我是实用派。

我前面一个帖子分析过了，在Flash RIA领域里面我们在实际项目中对两种方式都进行了尝试：一是完全服务器端封装……laszlo；一是客户端控制，服务器端只暴露业务bean和domain object，完全由客户端做为controller。

最后做下来的结果，客户端控制方案基本上放弃了，原因就是这样做太复杂，成本比想像的要高很多！当然AJAX和Flash RIA是有些区别的，不过类似的实践经验可以借鉴。

对于AJAX来说，一种是服务器端封装，由服务器端生成客户端需要的JS，目前Webwork是这样做的，rails好像也是这样做的（你不是很推崇rails吗？)；另一种方式就是dlee推崇的由客户端JS来做controller，完全放弃服务器端控制。

我是支持服务器端封装的，主要原因有二：1、基于我们对Flash RIA实践经验的结果，证明这种方式比较可行一些，而纯客户端控制的实施成本太高，难度太大；2、服务器端控制易学易用（虽然灵活性差，能力比较差），这是一个很大的优势。

而客户端JS做controller，显然可以实现更炫的效果和更好的体验，但是开发的成本和难度不是一般的高，是非常高。很多本来用服务器端很容易解决的事情，并且客户也接受这种操作方式，但是非要用JS去做，会让开发难度高很多，而且开发的门槛过高了，后续的软件可维护性都是很大的问题。

dlee他原来所在公司的确是采用这种方式，所有的web页面全部都是*.html，没有任何动态页面。页面和服务器交互全靠页面里面的JS访问服务器端获取数据，纯靠JS来驱动，整个web层完全推到客户端来做，这种方式开发上的难度和软件运行的稳定性都不是很好。当然如果采用这种方式，那么现在的Java web框架肯定都被淘汰了。

再有一种过渡方式就是controller仍然是服务器端，但是服务器端不封装AJAX，客户端编程根据情况自由选择组合一些AJAX框架，应该说这是目前比较普遍的情况。

关于controller究竟在服务器端还是客户端，实际上JavaEye原来已经充分讨论过了，一种观点认为应该坚持服务器端controller，客户端的AJAX是有益的补充，我持这样的观点；另一种观点则认为完全抛弃在服务器端做Web层，服务器端只做业务层，把整个web层推到客户端来做，dlee持这样的观点。

另外这两种方式也不完全对立，potian采用了一种更独特的方式，服务器端仍然是webwork，只不过view不生成HTML了，改成Webwork的View生成纯JS，该JS再在客户端进行render。

其实方式没有对错，主要是看成本：开发成本和学习成本，以及维护成本。总体来说成本应该是这样的：

服务器端封装AJAX(我比较推崇的方式) < 服务器端＋客户端AJAX(当前比较普遍的方式) < 服务器端 + 服务器端生成客户端AJAX混合(potian的方案) < 纯客户端AJAX(dlee的方式)

前两种方式controller都在服务器端，第三种方式客户端也有少部分controller，第四种方式controller完全在客户端。

而从客户端交互的灵活性上来说，则正好倒过来。dlee的方式最好，我推崇的方式最差，具体采用那种方式，我看还是大家自己权衡吧。



Struts Ti就是这个Goup的成果，如果真的完全融合成为一个框架，那么反而很不好，留下来两到三个选择是最好的，有竞争。

听robbin这么一讲，真是很向望dlee他们公司的开发方式啊，
,页面都是*.html，这不正是我理想中的系统吗，呵呵^_^。
我比较倾向于客户端JS来做controller，如果放在服务器端来封装，肯定要牺牲非常多的自由。我觉得WEBWORK2.2对AJAX的支持不漂亮，原因是我根本就认为tags这东西就是丑陋无比的^_^,不过WebWork如果要提供对AJAX的支持，用tags应该是最优雅的方式了。

在 WebWork 对于 Ajax 支持的 presentation 中，作者说了这么一句耐人寻味的话：

AJAX is really just a bunch of JavaScript, HTML, and sloppy logic smashed together in a big train wreck!
并且作者还用粗体加重。
看不懂吗？我来翻译一下：
Ajax 其实不过是一堆 JavaScript、HTML 和膨胀的逻辑混合在一辆巨大的失事火车里面。

这是dlee的翻译，不是我的臆测。

http://www.blogjava.net/dlee/archive/2005/11/21/20815.html

我觉得没有必要非要揪住人家的一句话揣测半天，然后推测人家背后的动机，人的观点都是会变的。我过去也不看好JS，现在不一样转变了吗？

你去判断一个框架对AJAX的支持程度应该是从他的代码来看，去看封装的方向对不对，支持程度成熟不成熟，而不是完全忽略他的代码，仅仅根据作者的某句话来推测他做出来的东西好还是不好。


按照dlee的逻辑，如果传统的J2EE开发者对JS不轻视的话，那就应该完全抛弃Java Web框架，大家都去客户端写JS来做Web层了。




我来模仿一下：
现在我要问的问题是，我们是否应该依赖rails这么多自动生成的对象映射？万一遇到了复杂的情况，这些rails的自动对象映射不适用，我们是不是还是要去找到rails的源头，修改生成对象映射的rails的源代码。
更进一步，过于依赖这些自动生成的代码可能会阻碍我们采用更先进的 O/R Mapping 技术。例如完全面向对象的领域模型以完全的分离业务逻辑，以实现最大限度的领域模型重用。

其实我上面已经非常详细的谈各种方式的优缺点了，并且很多东西都是从实践经验总结出来的。很多东西理论上说的有多好，真正去用，你就会发现蛮不是那么回事。关于把整个Web层放在客户端用JS去实现，反正有兴趣的，自己去用这种方式做一个项目就冷暖自知了(没有项目机会的话，可以自己练手做一个论坛软件去尝试一下)。

今年上半年我在看Flash RIA，对Flash有一个叫做AMF的协议非常感兴趣，这是Flash的Remoting协议，基于HTTP，Flash7已经内置非常强的Remoting功能了，而且ActionScript2.0是一个面向对象的脚本语言。对于RIA来说，Flash看起来比AJAX优势多好多：
1、JS无法和HTML分离，而AS可以和SWF良好的分离
2、JS的面向对象很弱，而AS的面向对象功能很强
3、JS的Remoting功能完全要自己实现(DWR，Buffalo)，而AS内置强大而且多种多样的Remoting方式
4、JS的调试工具比较原始，而AS的调试工具要很先进

并且我也找到了一个成熟的AMF的Java服务器端实现，OpenAMF，这个时候整个程序的架构是：
服务器端：Spring＋Hibernate，OpenAMF可以直接调用Spring的bean
客户端：AS编程，AS声明一个domain对象（对于Java的domain对象），然后用自己的Remoting API直接就可以调用服务器端的Spring bean，获得服务器端的domain对象，该对象序列化到Flash里面的AS domain对象。

看看吧，多么OO，多么透明的访问方式，AS可以直接调用spring bean，而且是domain对象跨越服务器端和客户端全程运算。

从技术上来说真的非常完美，从理论上来说真的令人激动，可是软件做下来，最后基本上不用这种方式了，真正去做的时候会面临很多很难解决的困难，而这些困难在传统的Java Web编程方式下却很容易搞定。

我这种方式就是把整个Web层取消掉，完全推到Flash端来实现，和你们主张的完全推到JS端来实现，本质上没有什么不同。但是要看到JS对于这种方式的支持还远远没有Flash来得好，Flash有强大的面向对象语言AS，有强大的Remoting能力，有成熟的通讯协议和通讯方式；而JS呢，在面向对象方面差得很远，Remoting能力要自己去开发，通讯协议现在也是各干各的，而客户端的驱动能力也不如Flash。

既然Flash采用这种方式都有很大问题，不如laszlo这种在服务器端编程来封装Flash来得更加切合实际，用JS还不是更加碰钉子？这还主要不是客户端编程的学习成本的问题，而是一旦采用这种完全推到客户端的方案，整个编程的方式都改变了，很多本来服务器端做起来很简单的事情现在实现起来都很困难。

反正我多说也没有用，大家自己去做一个都是*.html的论坛出来，就知道这种方式行不行得通了。记得我那时候钻研Flash RIA，也挺豪气干云的，梦想着推出一种革命性的Flash + Spring + Hibernate的架构，彻底淘汰Java Web层，从此改变一代软件开发架构。现在你们无非就是把Flash换成AJAX，改成了 AJAX + Spring + Hibernate罢了，而且好像也在做着这种架构可以淘汰Java Web层的梦想。嘿嘿，我是过来人，现实等着你们呐。

对于AJAX，我认为它是Java Web编程方式的一种很好的补充，而不是全面取代Java Web层，他们是互补关系，不是取代关系。

这个是一种很经典的方式，webwork2.2基本采用这种方式。不过 大部分的工作都由dojo来做了，dojo也是以服务端返回js，在客户端执行为实现ajax的基础构件。
说到底，dwr也是如此来做callback .
赫赫，完美的客户端异步和服务端同步的结合。 几乎现在所有的服务器端生成js的都是这种模式。

flash 有两个目前来说我不能接受的弱点:
1. 二进制代码运行, 导致页面不可检索
2. 还是比较慢的.

检索人家网站页面的事情是搜索引擎的事情，如果给自己的网站做检索，直接去数据库里面search了，所以这个问题其实并不是问题。

速度问题来说确实比较慢，不过如果高手优化的比较好，速度倒也不算慢。

Flash做RIA其实最大的问题在于和HTML交互比较困难，例如你如何在Flash里面驱动嵌入该Flash的父网页里面的HTML元素，而这些功能又需要。这一点Flash RIA是不如AJAX的。AJAX在驱动网页方面比Flash RIA强太多了，这也是我现在也不怎么再提Flash RIA的原因，只要HTML不被淘汰，那么驱动HTML的需求就存在，这方面要么你完全抛弃HTML做纯Flash的客户端，要么就干脆别用Flash RIA。Flash嵌入在HTML里面做RIA感觉比较尴尬。

AJAX现在算比较热门了，但是全部都用AJAX，完全抛弃Java Web层，也是不合适的。有些事情是适合用服务器端去解决的，有些事情是适合用客户端去解决的，如果完全抛弃服务器端，采用纯客户端，那么本来那些在服务器端解决起来很方便的功能现在就会变得很困难。所以这是一个权衡的结果，主要的controller仍然放在服务器端Web层，同时引入AJAX处理复杂的用户交互，才是最合适的方式。