关于ajax的一些随笔
摘自：我的CRC卡片盒
@H_403_3@
@H_403_3@
1、 @H_403_3@Ajax 必然会带来 @H_403_3@Web 开发 @H_403_3@Model2 模型的变革。
a) @H_403_3@MVC 的角色由服务器端向客户端靠拢，或者，干脆转为其他更合适的形式，
b) @H_403_3@V(View) 的角色将不再仅仅是不起眼的 @H_403_3@jsp ，在 @H_403_3@Web2.0 的时代，它将拥有自己独立的一套体系结构。即行为 @H_403_3@(Java Script/ECMAScript) ，结构 @H_403_3@(XHTML) 和样式 @H_403_3@(CSS) 。
c) @H_403_3@M 的角色将更像 @H_403_3@DTO ，它的形式可以由多种，比如：
i. 字符串
ii. @H_403_3@JS 对象
iii. 应用更为广泛的 @H_403_3@XML
对应的，他们的传输协议也有多种（当然，都是基于 @H_403_3@HTTP ）：
i. @H_403_3@JSON-RPC （ @H_403_3@JS 对象）
ii. @H_403_3@Burlap( 基于 @H_403_3@XML 的 @H_403_3@Java 对象 @H_403_3@)
同时，客户端 @H_403_3@- 服务器端对象之间的转化也将成为一个必须解决的问题。目前， @H_403_3@JSON ， @H_403_3@Buffalo 已经比较好的做到了这一点。
d) @H_403_3@C 的角色将更为靠近客户端，它将利用 @H_403_3@Js 的特点，发挥其快速、灵活的特点。它将取代大部分原服务器端控制器的作用。从而使服务器端的编程更加专注与业务逻辑。
服务器端的控制器层则会变得更薄，它将专注于：
iii. 服务器端数据验证与安全保护
iv. 与业务逻辑层之间联结的纽带
但是，这一层的功能一旦集成到业务逻辑层，它将失去主要的作用，很可能退出服务器端的领域。
@H_403_3@
@H_403_3@
2、 传统的 @H_403_3@MVC 框架 @H_403_3@( 比如 @H_403_3@Struts ， @H_403_3@WebWork) 与 @H_403_3@Ajax 之间应该是竞争的关系，因为：
a) 传统的 @H_403_3@MVC 框架在本质上，都是同步调用，而非 @H_403_3@Ajax 提倡的异步调用。
b) 传统的 @H_403_3@MVC 框架试图用标签来集成一部分 @H_403_3@Ajax 应用。但这注定只能是一种过渡行为，因为：
i. 传统的 @H_403_3@Tag 带来的不便正逐渐显现出来。 @H_403_3@( 学习成本、不利于编辑、客户端与服务器端代码的夹杂等 @H_403_3@)
ii. @H_403_3@Tag 对 @H_403_3@Js 的封装有限，无法发挥 @H_403_3@Js 强大灵活的功能
iii. @H_403_3@Tag 是服务器端生成的代码，过多的参与客户端的行为，不利于程序的分层实现。
iv. 使用 @H_403_3@Tag 使得页面展现逻辑的控制变得复杂和难于理解。它将使动作与表现的分离变得困难。也使得客户端与服务器端逻辑的分离变得不可能。试想用一段代码来控制一个自己也不知道会不会生成，能生成什么样 @H_403_3@HTML 的 @H_403_3@Tag ？
c) 基于第一部分提出的原因， @H_403_3@Ajax 所提倡的新的 @H_403_3@MVC 方式与传统的 @H_403_3@MVC 框架所实现的方式已经有本质的区别，它们之间的竞争也就不可避免了。
3、 传统的 @H_403_3@MVC 框架适用的地方（ @H_403_3@Web Request 适用）：
a) 重视 @H_403_3@URL 的应用，如新闻、论坛等
b) 重视搜索引擎优化
c) 重视用户传统习惯（后退键问题等）
实际上，上边所说的问题 @H_403_3@Ajax 都可具有相应的解决方案，但是由于并不能显示出更多的优势。所以传统的 @H_403_3@MVC 应用框架仍然有存在的空间。
@H_403_3@
另外，强烈推荐的两个 @H_403_3@PPT
庄表伟：
http://www.ajaxcn.org/space/start/2006-03-13/1/Ajax%E6%8A%80%E6%9C%AF%E5%9C%B0%E5%9B%BE.pps
曹晓刚：
@H_403_3@http://www.redsaga.com/down/Use-RIA-And-Metadata-In-J2EE-Enterprise-Dev.ppt
@H_403_3@
这个也不错，不过没完全看懂：
@H_403_3@http://alex.dojotoolkit.org/wp-content/LowLatencyData.pdf
@H_403_3@
@H_403_3@
@H_403_3@
1、 更佳的用户体验是 @H_403_3@Ajax 应用推广的原动力
a) @H_403_3@2006 年的 @H_403_3@Web 开发将是注重用户体验的一年
b) 基于异步的 @H_403_3@Web Remote 调用将给用户带来更好的用户体验
2、 交互式设计
a) 传统的设计令人恼怒，也不能提高生产率
b) 基于目标导向的交互式设计
c) @H_403_3@http://www.dedream.com
@H_403_3@
关于 @H_403_3@Web 标准和 @H_403_3@Web2.0
@H_403_3@
1、 @H_403_3@Ajax 需要建立在 @H_403_3@Web 标准之上，因此，学习 @H_403_3@Ajax 必须学习 @H_403_3@Web 标准。
2、 使用 @H_403_3@Web 标准能给 @H_403_3@Web 应用带来更多的好处 @H_403_3@. 。
a) 具体的可以参见《网站重构》一书。 @H_403_3@http://www.china-pub.com/computers/common/info.asp?id=18781
3、 使用 @H_403_3@Ajax 可以实现 @H_403_3@Web2.0 的一堆概念
@H_403_3@
关于 @H_403_3@RIA （胖客户端）： @H_403_3@
1、 @H_403_3@Ajax 是否属于 @H_403_3@RIA 方案？
这种争论意义不大，但是 @H_403_3@Ajax 确实带来了与其他 @H_403_3@RIA 方案相似的用户体验。在 @H_403_3@RIA 重新引起人们重视的今天。
2、 比较其他的 @H_403_3@RIA 方案， @H_403_3@(FlashFlex ， @H_403_3@Java Web Start ， @H_403_3@Applet ， @H_403_3@Eclipse Remote ， @H_403_3@ActiveX) ， @H_403_3@Ajax 更容易被 @H_403_3@Web 开发人员所接受
3、 使用 @H_403_3@XML 做 @H_403_3@Web Remote 数据传输体，可以使 @H_403_3@Ajax 应用方便的迁徙到其他 @H_403_3@RIA 方案。
@H_403_3@
其他： @H_403_3@
@H_403_3@
挑战与思考： @H_403_3@
1、 @H_403_3@Ajax 推动的困难之一在于开发人员对 @H_403_3@Js 、 @H_403_3@CSS 等表现层技术的轻视。
a) 业界需要 @H_403_3@Web 标准、 @H_403_3@Web 2.0 等相关技术，加强对此的研究工作
2、 相对不成熟的 @H_403_3@Ajax 开源框架，目前 @H_403_3@Ajax 开发尚没有类似 @H_403_3@Struts 、 @H_403_3@WebWork 等经过多年考验成熟框架，多数 @H_403_3@Ajax 框架还不存在 @H_403_3@2.0 以上的发布版。而且 @H_403_3@Ajax 开源框架质量的良莠不齐也给开发人员的选择带来困难。
a) 部分精品的 @H_403_3@Ajax 框架（ @H_403_3@DWR 、 @H_403_3@Buffalo 、 @H_403_3@JSON 等）已经将逐步走向成熟，虽然尚缺乏大型应用的考验，但也有了长足的进步。
b) 国内优秀的 @H_403_3@Ajax 框架 @H_403_3@Buffalo 正逐步得到多方面的应用。
a) @H_403_3@Ajax 使用的 @H_403_3@XMLHttp 技术不能跨域访问 @H_403_3@url, 也不能在 @H_403_3@HTTP 协议的页面访问 @H_403_3@HTTPS 的请求。
i. 对于安全性不高的应用，可以使用服务器端中间页面（服务器段代理）解决此问题。
ii. 对于确实需要加密的应用，可以使用嵌入 @H_403_3@HTTPS 协议的 @H_403_3@IFrame 页面来访问 @H_403_3@HTTPS 请求。
b) @H_403_3@DoS 攻击。 @H_403_3@Ajax 使用的 @H_403_3@XMLHttp 使用类似 @H_403_3@POST 的方式提交数据。使得客户端可以无限制的提交大量攻击性数据。一旦攻击者采用分布式拒绝服务攻击 @H_403_3@(DDoS) ，将对系统带来很大影响。
i. 除加强服务器段验证外，目前软件方面无太好的解决办法。实际上，使用 @H_403_3@POST 方式的表单提交同样存在此问题，但是 @H_403_3@Ajax 的应用使得服务器端的服务地址变得更易被发现。
ii. 使用硬件防火墙。
c) 传输数据减少，使得数据被截获后分析变得容易。
i. 使用数据加密技术
ii. 使用安全套接字层传输数据
d) 客户端代码展现在用户面前，难以保证商业项目源代码的版权。
i. 对 @H_403_3@JavaScript 脚本进行加密（ @H_403_3@Google ）。
@H_403_3@
4、 其他问题：
a) 缓存问题， @H_403_3@XMLHttp 的缓存使得服务器端数据更新后，客户端不一定能立即展现出来
i. 使用随机码访问服务器端地址
ii. 通过对 @H_403_3@XMLHttp 缓存性质的设置，牺牲部分性能来解决此问题
b) 浏览器兼容性问题：
i. 目前流行的 @H_403_3@Ajax 框架均可支持大部分的浏览器
ii. 对于比较古老的浏览器（不支持 @H_403_3@XMLHttp ）尚没有解决的办法，但是使用这部分浏览器的访问者数量已经接近于 @H_403_3@0 。
