同时不要盲目崇拜ajax，他有好的也有不好的一面，小规模使用是可以提高表现层的客户体验，但是如果拿来做一个非常复杂的业务系统，那就有的苦头吃了，国内这方面具我所知"锐道"比较强，号称胖B/S架构，采用了大量的ajax，结果用他们做出来的业务系统，共同反映很慢，同时对于ie来说这个东西也不稳定，升级是一个很大的问题。

所以只能说各有千秋罢了，不然微软的.net也不要搞什么win form了。呵呵。

听了以上二位的意思我觉得应该是这样用ajax技术。我们可以用但是要建立在一个良好的系统架构上用这个东西，显示一些大家所期望的效果。但不能完全的做成纯ajax系统如果html+js+业务。原因可能有很多。技术、维护、安全、速度。

谈谈ajax实质！

客户端首先从服务器请求页面。服务器返回内嵌 JavaScript 代码的 HTML 页面。然后 JavaScript 代码从服务器请求更多的数据（通常使用 XML）并动态地更新页面。

我们可否在中间做些手脚来均衡一下。客户必然还会请求服务器。服务器返回的页面是由现有的传统框架所生成。（而不是静态的Html+js)然后js代码可以从服务器请求数据（xml格式可实现页面节点动态刷新）跳转页面工作由传统框控制层处理并且搞定权限安全等一些拦截工作。这样是否是当前web的需求那？

是这样，ajax与控制层的关系，在scope粒度上不同的，也是事件模式的不同，事件模式中常有主动触发调用和reaction自我触发两种，控制层是为了应付主动触发调用，进行一些大scope范围内大的主要页面流程跳转；而ajax是一种reaction自我触发为主的模式，通常可用在一个大的主要页面范围内自我激活其他小页面的调用。

从事件模式角度看，主动触发调用和自我触发这两种模式都有应用范围，没有随替代随的问题，具体技术总是服从应用模式的。

当然，ajax也可能发展出响应主动触发调用模式，但是安全性等问题这时就是首要问题，安全验证一定需要服务器端实现，包括控制层Web资源验证，以及业务层的组件构件方法调用验证等。

btw: 当出现一个新技术时，我们在激动之余，就要以模式观点来看待，就不会走极端，泰然处之，也不会有压力紧张感，感觉那么多技术要掌握，知道某个新技术是哪种解决方案，哪种模式，以后在遇到相应场景问题时，再进行具体研究也不迟。