【总结】Ajax Asp.Net 交互处理方式（一）

前言：本文并非说明如何使用Ajax，如何和后台进行交互。本文是作者（也就是我啦）在以往操作Ajax与后台交互时而产生的一种处理思维。也因为是自己的思维所以在某种程度上说不一定能符合大众口味，因此您如果有心想读下去，请先保留您自己的想法，看看后大家一起交流。我所说的这个方式是在我做毕业设计时而产生的（由于毕业设计时间紧我美工又不是很好，所以我放弃了做页面，copy了一个外国网站首页然后就一堆Ajax和模态窗口搞定了设计）。随后在工作中对以前的这个设计模式进行了修正调整，近几日闲来无事把这个东东再次整理优化了一下。全文如果不出意外打算写4个部分
     一：处理方式介绍
     二：前台Javascript实现
     三：后台代码实现
     四：调用例子

提醒：本文提到的处理方式是架构在 Asp.Net + Jquery + Json 条件下，总体很简单，如果您觉得不错也可以迁移。

下面进入正文了。

在以往的Ajax中，我们通常是用户一但有请求就产生一个Ajax请求体，同时在这个请求体中定义将要进行的callback处理函数（通常通过匿名函数的形式定义）。后台在处理完毕后就会进入定义好的callback处理块中。如下图：

我们从图中可以看到，如果用户访问的页面产生了N个Ajax动作请求，就会出现N个请求体（蓝色方框中的内容），请求体中定义了回调的实现。这就是通常的处理方式。仔细分析我们可以发现其中会有几个可以考虑优化的问题：1、后台和前台信息怎样表示？2、是否需要再次优化？3、能否改变这种或是兼容这种回调的决定权？

问题一：我们毫无疑问，通过Json来表示传递的数据，虽然Json字串具有不易读的特性，但是他却具有很好的书写（.语法）和解析能力。

问题二：显然需要优化，当一个有很多Ajax请求的项目中如果按照这种方式，就会出现很多蓝色框所标示的请求体。这样会给阅读带来麻烦，同时也会增加代码体积，不便于日后的维护和管理。

问题三：我们可以改变回调的决定权。

根据以上三点修改模型为：

表面上看似乎多了N个 Js Function的块，但是实质上这种模型能够使得页面具有很好阅读，而且可以解决上面提出的问题。下面我来分析一下这种模式的特点（一个请求体，N个动作体，相互无直接联系）：

我们从以往的ajax请求可以看出，所有的请求都有其共同的特点，我们可以尽可能的抽象提取这种请求的特点然后将其封装。这样就形成了模型中蓝色框所示的区域，我将其视为中间件，所有的请求都将通过其代理和解析，他一方面负责收集用户的请求，一方面负责对后台反馈的信息进行解析最终确定如何执行下一步。这样就是将请求和具体的动作（JS Function）进行了分离。从模型中可以看出这种动作（JS Function）已经不再是Ajax请求体中的callback，他实际上是一个页面级的JS函数，通过这种分离就可以将问题三中的决定权进行移交，从而具有更好的扩展性和操控性。

为什么我要移交决定权？我们可以这样设想：一个页面需要实现修改、删除、增加……等ajax操作，如果按照原始模型（N个请求体，N个动作体，且一一对应）每一个操作的ajax处理块都需要定义一个相对应此操作的回调函数块，在这个函数块中是对此操作各种情况的处理。如果这些操作需要建立在用户已经登录的情况下，那么每个回调块中就必须实现对未登录的处理，实际上就造成了代码的重复定义。简单点说 原始模型下程序员必须事先知道后续所有的可能，并对各种可能进行编码。也就是说如何解析的决定权是在发起请求的前台请求体上就已经定义完毕了。相反如果通过新的这种统一解析模型，我们可以将这种决定权交给后台，后台可以根据具体情况随意的调用前台的任何JS函数来作为回调，这样对于上面的那个需要登录的例子就显得很容易了。首先我们在页面上定义 修改、删除……的后续函数 再定义一个引导用户登录的JS函数块，后台如果发现用户未登录就直接根据约定的“消息协议”来调用登录的js，否则调用对应的js即可。

“消息协议”：是指在此模式下后台与前台进行交互的一种消息规则。实际上是一个对象被序列化后的json字符串。我们知道每个请求都是需要返回结果的，在总结了以往的ajax请求实现后，我对这种消息进行了抽象表示。在我看来这种消息应该具有以下特点：有一个“头信息（包含一些必须的属性值）”，然后就是“自定义消息”（需要传递给前台的所有信息）。

“头信息”：在我的方案中，我将其定义为以下三个特征值，这些特征是会永远存在（默认为空），他们分别是：“成功信息”、“失败信息”、“动作（后续动作）”。这样一来在Common Callback中我就可以根据这些头信息进行分析和简单的动作处理，再通过“动作（后续动作）”这个属性中的值便可以引导到正确的JS Function中进行更为复杂的信息处理。

“自定义消息”：其实他是一种字典或者说是哈希表，他是一串Key/Value的形式，这些需要传递给前台的信息最终会被序列化为字串。

下面是一个 消息协议对象的表示形式图（最终给前台的是此对象序列化后的字串）：

这样我就可以在回调函数Del中获得 删除ID、操作者 的值，例如

function Del (JsonObject){

        alert(JsonObject.操作者+"删除了 ID为："+JsonObject.删除ID+”的记录”)

}

通过约定ALL关键字（详见后续文章），便可以在回调函数中通过"."访问到所有的传回信息（包括头信息和自定义信息）

总之，提出此模型的原因就是为了尽可能的将原本重复的工作精简化统一化，将整体的可控性更加灵活化。但是这个模型也有不太适应的地方。如果项目中ajax情况很少，且ajax请求传递的信息层级小（例如：只需要通过0，1即可标示后台的所有情况，甚至无需用到Json）。这种情况下这个模型就显得过大了，同样的如果传递的信息复杂（数组，自定义对象，DataSet），交互频繁，使用此模型后会发现代码的阅读和处理上会有很大的便捷。

接下来将要开始根据这个模型对前台的统一解析“中间件”进行设计，并按照”消息协议”的约定来构建后台对象。

[Come From: http://foxhunter.yo2.cn/articles/ajax-aspnet-01.html ]

转载于:https://www.cnblogs.com/foxhunter/archive/2009/07/29/ajax-aspnet-01.html