一篇关于Ajax的文章，也许会让你的理念彻底改变！(转)

有朋友发了一些关于Ajax的帖子，普遍的观点都是UI始终是UI，配角依旧是配角。不过下面的帖子让人有一个新的认识……
转贴如下：

一直以来，表现层的开发在Web应用的讨论中似乎总是一个小角色。Java的开发者们热烈讨论的 Spring，Hibernate，Struts，WorkWeb 也都跟它没有什么关系。技术专家们甚至理直气壮的喊出了Web表现层应当“As thin as possible”的口号，于是越来越多的人们开始深信有关业务逻辑的开发技术是武学之正宗，而表现层的开发技术只不过是些旁门左道，花拳绣腿。直到 2005年初，伴随着 Ajax 的出现，Google Map 等一批样板工程摆到了我们的面前，大家才猛然发现原来Web应用还可以做成这样!在这股冲击下越来越多的人开始考虑表现层的真正价值了。于是 Ajax 迅速的窜红起来，成为这两年Web技术发展道路上的标志性名词。其实 Ajax 即不是新技术也不是很复杂的技术，它不过是基于Web的RIA应用中的一个操作特性（或技术特性）而已。Ajax 只有结合了 Widget （指各种各样的界面组件）之后才能真正的发挥威力。尽管如此 Ajax 的诞生仍然谓革命性的。说道 Ajax 的革命性，可能很多人会大吃一惊：Ajax 不就是 XMLHttp 吗？这种技术早在1999年就出现在浏览器当中了，它不过是一种新瓶装旧酒的噱头！ 其实我所说的革命性，并不是指Ajax在技术上是革命性的，而是说 Ajax 的出现对传统 Web 应用的开发模式的冲击是革命性的。

冲击 － 尴尬的 Struts 和 WebWork

说到这一点，让我们先来看一下目前流行的开发模式，即基于 Model2 的 MVC 开发模式。在 Model2 的眼里存在着这样一个基本的假设，哪就是 Web 应用的运行逻辑是由一系列的页面切换构成的，这里的每一个页面一般来讲都不是特别复杂，往往有着非常特定的功能和目的。同时页面对于浏览器来说又是不可分 割的最小单元，要更新页面中的数据必须对页面进行整体刷新。让我们先啦看一个“产品信息维护功能”的例子，现在我们需要维护一个产品信息的列表，用户可以 在这里完成对产品信息的CRUD四种操作。在 Model2 中通常的设计方式是这样，我们至少需要编写两个页面，一个用来根据查询条件列出产品列表，另一个用于对单个产品的详细信息进行维护。最终通过这两个页面的 交替协作完成所有的功能。假设用户今天要进行如下的操作：输入查询条件查询他所关心的产品，然后修改其中的两个产品，新增一个，最后删除一个。基于上面的 设计最终要走完这个流程我们的系统做了些什么呢？ 在这一系列并不复杂的操作中，用户界面却足足的刷新了8次！每一次刷新都一位着用户需要等待和重新适应新出现的页面，思维和操作至少会被刷新打断2秒！不 难想象一个原本正心情愉悦的打算开始一天工作的用户在经历了这8次的打断之后肯定会倍感挫折。而这只是他一天工作的开始，更复杂的还在后面呢!

那么结合了 Ajax 的表现层又会如何来处理这个问题呢？利用 Ajax 的通信机制结合一套好的 Widget （UI组件），我们完全可以吧上面所有的这些操作都合并到一个界面当中。如果产品信息并不复杂，我们可以使用一个可编辑的 Grid 组件，让用户直接在 Grid 中进行产品信息的维护。如果产品信息比较复杂，那么我们可以在界面上再放置一个产品信息的维护清单，用户可以直接在 Grid 中选择要编辑的产品。所有这些编辑操作的结果都会暂时的缓存在客户端，直到用户完成了上面的各个步骤再一次性的利用 Ajax 技术提交到后台。这样，再整个操作过程中用户始终不需要离开这个界面。
用户的操作体验已经不再由一系列的页面切换所组成了。因此表现层的开发技术的升级必须导致对 MVC 设计模式的重新思考和定位。
ajax是多种技术的组成，虽不是新技术的产生，但却是技术的更好的应用！…… 并且越来越发挥着巨大滴作用！……