各种AJAX方法的使用.doc

各种AJAX方法的使用比较 阅读目录 开始 第一代技术：生成客户端代理脚本调用服务端 新技术的改进方向 第二代技术：jQuery直接调用WebService 第三代技术：更简单的数据格式 第四代技术：直接提交表单 多submit按钮的提交（用jQuery.form实现） 批量输入控件的提交（用jQuery.form实现） 提交复杂表单（用jQuery.form实现） 各种AJAX开发方法的对比与总结 相关链接 AJAX技术经过这么多年的发展，出现了一些框架或类库用于简化开发工作，不同的框架类库的使用方法也各不相同。 现在，再回头看看这些技术，看看这些框架类库，我们能感受到技术在不断地发展，AJAX开发越来越容易了。 本文收集了在ASP.NET平台上，一些具体代表性的AJAX开发方法，我将用实际的示例代码来演示如何使用它们， 让您感受AJAX的进化历程，同时也希望将一些优秀的AJAX开发方法介绍给您。 为了方便地介绍这些AJAX开发方法，我将它们划分为四代技术。注意：按代划分AJAX技术纯属我个人的观点，只为了更好了区分它们。此外，一些不借助任何框架类库的原始AJAX开发方法，本文将不讨论它们。 这类技术展示了第一代的AJAX框架的主要设计思想：在服务端为客户端生成代理脚本， 然后由这些代理脚本调用服务端，调用者可以不必知道整个调用过程是如何实现的， 而且在客户端的调用风格也基本与服务端的代码类似。 这类技术的代表作有：ASP.NET AJAX, AjaxPro 二个服务端框架。下面我将用ASP.NET AJAX框架来演示如何进行AJAX开发。 首先，我们可以创建一个WebService服务： 这段代码就是一个普通的WebService代码，唯独需要注意的是：在类的定义上加了一个ScriptService修饰特性。 接下来，我们还需要在一个ASPX页面中，用ScriptManager为它生成客户端的代理脚本： 说明：InlineScript=true的设置并不是必须的，只是为了让我们看到ScriptManager到底生成了什么代码。 从截图可以看到，除了引入了二个必要的AJAX客户端类库外，还在客户端为WebService1生成了代理脚本。 有了这些代码后，我们可以用下面的JavaScript代码调用服务端： 前面这个示例太简单了，再来个参数复杂的示例吧，还是从先服务端开始，先定义一个参数类型： WebSerice的代码： 仍然借用前面的ScriptManager设置，来看JavaScript的调用代码： 基本上还是与服务端的编码方式差不多，先创建一个customer对象，再传给调用方法。 在那个年代之前（2006年），原始的AJAX实现方式非常复杂，而这种方法让客户端代码风格看起来与服务端十分类似，这确实是个了不起的设计思路。 然而各种技术一直在改进中，现在，2013年，当我们再来回顾这种方法时，会发现它确实存在一些不完善的地方， 以至于现在使用这种方法的人很少了，这种技术被淘汰了！ 其实我们可以从另一外角度来思考：如果这种方法真的很优秀，它就不可能被淘汰，正是因为有更优秀的方法出现了，它才会遭到淘汰的命运。 前面介绍的那种AJAX方法能让客户端的调用代码与服务端的代码风格基本一致，看似很完美的方法为什么会被淘汰了呢？ 我来分析一下这种开发方法的缺陷：1. 前端代码不够独立，必须要在页面中添加引用之后才能调用服务端，这其实是一种强耦合。2. 出现了更优秀的前端框架能简少获取调用参数的代码量。 继续阅读本文，您会发现后面我将要介绍的新方法都朝着解决这些缺陷在努力， 这些缺陷也算是指出了新技术的改进方向。 由于前端在调用服务端时，需要事先生成代理脚本，这种设计会阻碍前端代码的封装性。 您可以想象一下：如果客户端需要一个【获取当前用户信息】的功能，而这个功能必须由服务端实现的， 此时，我们就只能指望服务端为客户端生成代理类来调用这个功能了。 但这个功能太有用，许多地方都需要使用，您是不是会想将它提取到一个公用的文件中？ 遗憾的是：就算您将这段调用代码提取到一个公共的public.js文件中，每个页面在引用public.js后， 并不能调用【获取当前用户信息】功能，因为代理脚本并不一定存在，public.js中的代码还不能运行起来。 怎么办？ 答：为每个引用public.js的页面，再添加ScriptManager引用那个服务吧。 共用性越高的功能，您会发现这种引用代码的重复度也就越高。简单说来，这种方法将WebService, aspx页面, js代码耦合在一起了。由于耦合，您越用越发现越麻烦。 这种生成代理脚本的开发方法虽然能让前端代码与后端代码的风格一致，然而， 前端与后端毕竟不是同一种开发语言，它们要关注的方向也