关于ajax的一些随笔

关于ajax的一些随笔


 

关于 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 应用框架仍然有存在的空间。