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