|
改变Web应用的开发方式（一）
----由Ajax引起的思考
引子
如果让你说出在最近在Web开发领域中被炒得最火的一个词，八九不离十将会是Ajax。套用鲁迅先生说过的一句话:“世上本没有概念，炒的人多了，便成了概念”。其实这个概念之所以能够被炒起来，除了Google等公司给我们炫了几个很Cool的Ajax应用之外(Gmail, Google Suggest, Google Maps)，更关键在于它为我们提供了一种Web开发的新思路 (Ajax: A New Approach to Web Applications )。看完这篇给Ajax命名的文章，首当其冲的是异步调用，通过XMLHttpRequest这一手段，我们可以使用户不用在进行每一个操作后干等Web的响应，从而提升了用户流畅的体验。
这个是这篇文章的核心，也是Ajax吸引人的一个亮点。但是今天我们要讨论的，却是文中提出的另一张图（图1），虽然Jesse James Garrett没有对其进行详尽的描述，但是它同样能给我们带来一定的思考空间。
传统的Web开发方式及其发展历程
如图1所示，左边是传统的Web开发方式：Web Server接受客户端传送过来的HTTP请求，进行解析，与后台交互进行业务处理，再把结果渲染成HTML，最后将其传到浏览器。虽然这种方式历经了多年的发展，我们也有不少的开发框架和工具可以使用，但是Web应用的开发仍显得比较复杂低效。我们通过回顾Java Web开发的发展历程来分析一下这个问题。
Sevlet为Java Web编程的早期规范，把Http请求与响应被封装成Java对象。在这段时期，整个Web应用基本仅由程序员来完成，他们在Servlet程序中从Request中取得客户端传送过来的参数，进行处理后将结果写回到Response对象的输出流中，这种方式无论对开发人员或是用户来说都是比较痛苦的，程序员需要在程序中写入大量重复枯燥的HTML输出语句，而且这种方式也很难在HTML的美工方面做得很好，所以对于用户来说，他们只能看到一些粗糙简陋的页面。
为了解决这个问题，JSP等动态网页技术出台了，首次在页面与程序分离方面迈出了一步，程序员可以在美工人员完成的HTML页面中嵌入程序代码，用来控制页面中动态部分。但是由于JSP规范对页面中Java程序没有太大的限制，对哪一些程序应该放在动态页面中，哪一些程序需要放在后台程序中处理也没有一定的规范。导致了在很多的Web项目中，大量的Java代码充彻于HTML Tag的字里行间，给美工与程序员都带来了不少痛苦。
为此，Craig R. McClanahan等一些有见解的开发人员开始提出了Web开发的model2，将经典的MVC模式导入到Web开发中，出现了Struts这个至今仍非常流行的Web框架，在架构上，它把浏览器提交的请求交给一个统一的Servlet控制器，由控制器通过读取控制文件将事件分配到相应对象模型(Actions)中，实现了对Request事件响应的对象封装。而在页面渲染方面，提供了一套与HTML形式类似的Taglib库，意图于减少HTML与Java程序间的异构性，更好地实现页面与逻辑分离。后来的出现的WebWork, Spring MVC基本上继承了Struts中的MVC思路，只是在事件分派，页面渲染的灵活性上进行了提高。但是这种所谓Web MVC的方式并不能彻底解决Web开发中的痛苦，由于Action的激活基于每一个页面跳转产生的Request请求，对于复杂的页面事件交互，Action的粒度与页面中状态的保持都是比较麻烦的问题。而且由于TagLib没有一个统一的规范，自定义性太强，使得嵌入它的页面很难被主流的HTML编辑器支持,始终不能摆脱页面与程序分离的问题。
在基于Request，对Action进行封装的框架之外，还有另一个Web框架的分支，那便是JSF等以对可视化组件进行封装为基础的架构。它力图将HTML元素的属性和事件的监听都封装在后台的对象中，为开发者屏蔽掉处理HTTP Request/Response方式带来的事件分派，状态保存等麻烦。这种方式在MS的.net开发中一直被提倡，希望Web程序的开发能像VB中的一样，利用强大的IDE,制作布局，画出控件,为控件指定监听器并书写响应程序。但是这种方式也存在一定的问题，因为B/S的Web架构毕竟与单机或是胖客户端不同，如果连结到服务器的并发用户较多时，这种将组件的事件监听，状态保持和渲染的工作都交由后台程序的方式必将对服务器资源提出更大的挑战。
总结以上各种Web开发方式所面临的问题，其根本症结可归于以下三点：
一是由于HTTP基于请求／响应范式。传统应用中浏览器发出请求，服务器针对每一个请求返回一个HTML页面。
二是由于HTML作为一个用于内容布局的结构化标志语言，与进行数据/逻辑处理的编程语言存在异构性。
三是由于Web应用以服务器为中心，Web开发需要考虑服务器端的负载问题。
Ajax能给我们带来什么？
对于这三大难题，Ajax方式能给我们带来解决的途径吗？
我们回头看看图1的右边。与传统的Web应用开发方式比较，它在浏览器端添加了一个层----Ajax engine，由用户产生的页面事件交由这个引擎处理，它负责向服务器发送请求，服务器传回的是业务数据而非HTML，引擎接受之后，进行渲染，通过浏览器的解析在页面上显示出来。说白了，就是将事件监听与页面渲染的工作交给了浏览器，而后台服务器只负责业务逻辑的处理。
在Ajax方式下，HTTP基于请求/响应的范式仍然没有变化，但是由于有XmlHttpRequest对象(Ajax engine的核心)的支持，我们不需要像以前那样将每一次请求发到服务器后，由服务器解析请求再进行事件发配，之后返回刷新用的HTML页面。在新的方式下，由于事件的监听和处理在浏览器内部实现，它的反应周期可以被缩短，事件的处理粒度可以更方便的做到更细，而且由于支持异步方式发送Request请求和接受Response响应，用户事件的控制有了更大的灵活性。
在Ajax方式下，HTML与程序的异构性仍然存在。但是由于把页面渲染放到浏览器中，使得我们可以通过HTML DOM对HTML的各个组件以对象的方式进行访问与控制而不是刷新整个页面，使得页面的渲染变得更加灵活，简便，丰富多彩。想想别扭的JSP Tag或是与HTML似近实疏的TagLib，还有Velocity等模版语言，他们的Tag被插入到HTML原本的Tag中，指挥服务器程序对被他包容的HTML进行逻辑操作从而来达到动态渲染页面的目的,不可避免的存在页面结构与程序逻辑混杂的问题。
在Ajax方式下，Web程序仍然以服务器为中心，但是由于事件处理与页面渲染的工作可以由浏览器来担当，从而减轻了服务器的负担。
Ajax开发方式存在的问题
既然Ajax方式存在以上优点，XmlHttpRequest，HTML DOM也不是最近才浮现的，为何这种方式到如今才进入我们的视野，而未能成为Web开发的主流呢？原因有以下几点：
1. 它依赖于浏览器。而至今各不同厂商的浏览器，甚至同一厂商浏览器的不同版本，对XmlHttpRequest与HTML DOM的使用方式皆有所区别。
2. 它依赖于JavaScript。从而有带来了以下问题：
Ø 用户可以很方便地关掉浏览器的JavaScript支持。从而使Ajax无用武之地。
Ø JavaScript本身的语法要求过于灵活松散，降低了它的可读性
Ø 没有强大好用的IDE与Debug工具
Ø 对于开发人员来说，在习惯于传统的Web应用开发之后，大部分人对其不重视，认为它只是做页面即时校验或一些页面效果的小伎俩
问题的解决
虽然Ajax存在着这样的问题，有些看起来甚至是致命的，但毕竟它还是被炒起来了，火起来了。基于Ajax的网站春笋般涌现，用于Ajax开发的框架与工具也崭露头角（Google开放了AjaXslt，微软推出了Atlas，JSF中加入队Ajax的支持）。这些都给我们一个信号，会有越来越多的网站与应用倾向于这种方式。为此，浏览器厂商会考虑到这个问题，虽说标准化不是一朝一夕的事情，但是大家会朝这个方向走得更近而非更远。随着Ajax应用越来越多的闪亮登场，用户关掉JavaScript的可能性进一步降低。这是发展的趋势，但就目前的现状来说，支持XmlHttpRequest, HTML DOM, JavaScript的浏览器也已是Web程序客户端的最大平台，而且将各浏览器间使用差别封装起来的Ajax engine也已经出现。从外部环境来讲，Ajax的推广应用已经不成大的问题。
剩下的就是开发人员的问题了。对于JavaScript，它能做到什么，能从何种程度上改变我们开发Web应用的方式？JavaScript有其先天不足，但是如果我们以OO的思想来看待它，利用并编写可重用度高的JavaScript组件，把前后台组织成一个新的框架，你会发现，比较起以往的方式，Web开发确实变得简单了。我将在本文的第二篇中介绍对这样框架的特性要求和实现手段。而至此，需要我们做的只是一点：观念的转变。 | 
