Hello World
Spiga

深入Atlas系列:Web Sevices Access in Atlas(7) - RTM中的客户端支持

2006-10-30 16:46 by 老赵, 3548 visits
  本片文章部分内容会基于我之前的文章:《深入Atlas系列:Web Sevices Access in Atlas(1) - 客户端支持》。

在RTM版本中,客户端访问Web Services的方法发生了改变。在《深入Atlas系列:Web Sevices Access in Atlas(1) - 客户端支持》和它对应的示例《深入Atlas系列:Web Sevices Access in Atlas示例(1) - 特别的访问方式》中我们知道了从客户端访问Web Services的基础类库以及方法。它们是:
  • Sys.Net.ServiceMethod类。
  • Sys.Net.ServiceMethod.invoke方法的两个重载。
  在RTM版本中,客户端访问Web Services的基础类库发生了一些改变,并直接影响到了它们的使用方式。对于自己写ASP.NET AJAX组件(例如ExtenderControl)的朋友们来说,了解这部分改变是非常重要的。


一、Sys.Net.ServiceMethod -> Sys.Net._WebMethod

在CTP版本中,Sys.Net.ServiceMethod是客户端访问Web Services的基础类,它继承于Sys.Net.WebMethod。同样继承于Sys.Net.WebMethod的还有Sys.Net.PageMethod,它用于访问PageMethod,这个类在RTM版本中被取消了。现在,客户端用于访问Web Service的类已经变成了Sys.Net._WebMethod(从命名上来看,很明显它不希望用户直接使用这个类),而且在使用上也有了很大的变化。

我们先来回忆一下CTP中Sys.Net.ServiceMethod的使用方式。如下:
var serviceMethod = new Sys.Net.ServiceMethod(url, methodName, appUrl);

serviceMethod.invoke(
    parameters,
    onMethodComplete,
    onMethodTimeout, 
    onMethodError,
    onMethodAborted,
    userContext,
    timeoutInterval,
    priority);

而在RTM版本中,Sys.Net._WebMethod的使用方式如下:
var method = new Sys.Net._WebMethod(proxy, methodName, fullName, useGet);
method._execute(params, onSuccess, onFailure, userContext);

CTP版本中Sys.Net.ServiceMethod中的invoke方法还有一个重载,在RTM版本中就不存在了。在Sys.Net._WebMethod的构造函数中,出现了一个“proxy”参数,这是什么呢?我们来看一下method._execute方法的代码。如下:
function Sys$Net$_WebMethod$_execute(params) {
    
return this._invokeInternal.apply(this, arguments);
}

不知道各位朋友看到这段代码的时候感觉如何?真正工作的代码其实是_invokeInternal方法,_execute方法在这里根本没有起什么作用。其实它们两个的关系似乎就相当于CTP版本中Sys.Net.WebMethod类中的invoke和_invoke方法,只是_execute并没有起到一个“调整参数”的作用,因此CTP里的“重载”也就不复存在了。莫非在以后的版本中,_execute方法真的也会提供一个方法重载?

既然真正工作的代码是_invokeInternal,我们就来看一下它的代码。如下:
_invokeInternal方法

上面代码中onComplete的逻辑和《深入Atlas系列:客户端网络访问基础结构(上) - WebRequest的工作流程与生命周期》中的模版代码非常的相似。可以看出,只有在得到结果时,才会使用onSuccess回调函数,否则无论Timeout,Error还是Abort都会使用onFailure回调函数。其实这段代码在处理错误时有个问题:请注意代码的第84-90行,这是用户没有提供onFailure回调函数时response出错时的处理。在这段代码里,默认了result是Error对象。这是一个一点道理也没有的假设。试想,如果服务器返回了503 Service Unavailable,目前的逻辑会使用户得到一个Javascript错误。按理应该给用户一个正确的提示,那么我们该怎么办?

由于这段代码被写死在类库里,我们无法轻易修改,目前我只想到一个颇为复杂的方法:重新定义一个WebRequestExecutor,如果遇到了“(statusCode < 200) || (statusCode >= 300)”并且contentType不是“application/json”的时候,则构造一个假的response对象,设定其contentType为“application/json”,并使其body为一个能够构造出Sys.Net.WebServiceError对象的JSON字符串。不得不感叹,这真是一个“令人发指”的错误。

万幸的是,如果我们提供了onFailure回调函数,就不会执行这段逻辑了,这才是最方便而且最正确的做法。

在上面的代码中使用了RTM中新增的proxy,关于它的使用还需要再看一个方法。细心的朋友应该发现了RTM中的WebMethod构造函数并没有接受一个url作为参数,因为它会从proxy中获得。我们来看一下Sys.Net._WebMethod的getUrl方法。代码如下:
function Sys$Net$_WebMethod$getUrl(params) {
    
/// <param name="params"></param>
    /// <returns type="String"></returns>
    var e = Function._validateParams(arguments, [
        {name: 
"params"}
    ]);
    
if (e) throw e;

    
if (!this._useGet || !params) params = {};

    
return Sys.Net.WebRequest._createUrl(this._proxy._get_path() + "/js/" + this._methodName, params );
}

Sys.Net.WebRequest._createUrl静态方法的作用是构造一个url,它会根据第二个参数声称Query String,并拼接在第一个参数上。


二、Sys.Net.ServiceMethod.invoke -> Sys.Net._WebMethod._invoke

很显然,以前的Sys.Net.ServiceMethod.invoke静态方法也会发生改变。在RTM中,与之对应的方法变成了Sys.Net._WebMethod._invoke,使用方法如下:
Sys.Net._WebMethod._invoke(
    proxy, 
    methodName, 
    fullName,
    useGet,
    params
    onSuccess,
    onFailure,
    userContext);

与CTP中的实现类似,它会构造一个Sys.Net._WebMethod对象,并调用它的_execute方法。代码非常短也非常简单,在这里就不进行“分析”了。需要注意的是,由于Sys.Net._WebMethod._execute方法取消了“重载”,因此Sys.Net._WebMethod._invoke方法也只有一种使用方法了。



最后,我们再来总结一下一些参数的定义。

首先是proxy,它提供了默认的onSuccess回调函数、onFailure回调函数以及userContext和timeout的定义,另外也需要提供Web Services的路径:
proxy = 
{
    get_defaultSuccessedCallback: 
function() // optional
    {
        
return function() { ... }
    },
    get_defaultFailedCallback: 
function() // optional
    {
        
return function() { ... }
    },
    get_defaultUserContext: 
function() // optional
    {
        
return ...
    },
    get_timeout: function() // optional
    {
        
return ...
    },

    _get_path: 
function() // required
    {
        
return ...
    }
}

另外还有onSuccess和onFailure两个回调函数的签名:
function onSuccess(result, userContext, fullMethodName)
{
    ...
}

function onFailure(errorObj, userContext, fullMethodName)
{
    ...
}

Creative Commons License

本文基于署名 2.5 中国大陆许可协议发布,欢迎转载,演绎或用于商业目的,但是必须保留本文的署名赵劼(包含链接),具体操作方式可参考此处。如您有任何疑问或者授权方面的协商,请给我留言

Add your comment

12 条回复

  1. Cat Chen
    *.*.*.*
    链接

    Cat Chen 2006-10-30 20:29:00

    我用ProfileService,那个Error连alert提示都没有,不开fiddler根本看不到,实在让人无奈。为了调试ProfileService什么情况下能用,什么情况下会有存取问题,明明是普通的服务器端错误,也不惜用fiddler来看。

  2. 老赵
    admin
    链接

    老赵 2006-10-30 21:05:00

    @Cat Chen
    这是因为ProfileService的实现所致,它并不会把您提供的onFailureCallback直接交给Sys.Net._WebMethod._invoke,而是使用了自己的_onLoadFailed,在这个方法里它设法察看您传入的onFailureCallback和它的defaultFailureCallback,只有当其中一个不为null时才会执行,否则就会“无声无息”。:)
    //其实Fiddler应该已经是必备工具了。:)

  3. THIN
    *.*.*.*
    链接

    THIN 2006-10-31 13:48:00

    花太多时间在源代码上没有太大价值吧,这个框架的代码不像当初prototype.js那样让人耳目一新,学着怎么用就行了,要不是它将成为ASP.NET的内部成员,都没有太大的用处,做做内部网还好,真做对外的public的网站,这么臃肿的一个东西,会让你死得很难看的。
    呵呵,一点小看法,其实是希望看到一些使用上,扩展上的例子

  4. 老赵
    admin
    链接

    老赵 2006-10-31 14:44:00

    @THIN
    其实这些是扩展的基础,我不会把所有的代码都分析一遍的啊。
    另外我不认为现在的ASP.NET很臃肿,现在的MicrosoftAjax.js的Release版本只有67K,MicrosoftAjaxWebForms.js也只有32K。这个体积对于一个AJAX应用来说不算什么吧,还没有包括Cache。另外运行效率现在也已经有了很显著的提高了,因此您说的“只能做做内部应用”也不甚妥当。您说的可能是对以前的ATLAS的评价,现在的ASP.NET AJAX已经变了。

  5. THIN
    *.*.*.*
    链接

    THIN 2006-10-31 18:47:00

    @Jeffrey Zhao
    我做了一个Extender,打开有六个资源文件,
    不过对它的Animation的模式很喜欢

  6. THIN
    *.*.*.*
    链接

    THIN 2006-10-31 18:49:00

    js那么有个性的语言,弄得跟别的语言一样,实在不爽,呵呵,期待你多写些应用和扩展上的文章

  7. 老赵
    admin
    链接

    老赵 2006-10-31 20:11:00

    @THIN
    怎么会有那么多的资源文件?
    其实ASP.NET AJAX是创造出了一个功能强大的模型,并没有对JS的特性作任何的限制。我也喜欢无谓的封装,但是不觉得现在的模型很好用吗?ASP.NET AJAX铺了一条路,但是没有设置栏杆。
    其实我一直在写一些基础,然后步步深入,您觉得在我这个系列里应该写什么样的应用和扩展上的文章呢?:)

  8. 小蜗牛
    *.*.*.*
    链接

    小蜗牛 2006-10-31 22:59:00

    慢慢来。

  9. 蛙蛙池塘
    *.*.*.*
    链接

    蛙蛙池塘 2006-12-03 11:29:00

    /// <param name="params"></param>这样的注释你怎么加上去的,难道还能用NDOC生成文档?
    arguments是全局变量?从哪儿来的呀?
    atlas调用web服务使用了队列没有?你页面上发送了100多个请求,它给你排队,然后哪个请求回来了,也放到一个接收队列里,然后有个线程读取接收队列并给出提示?
    proxy是啥意思?
    Animation是啥?

    太厉害了你,啥都知道,我回头再从头看一遍你的文章,估计每次看都会有新的收获,也就是有新的问题,哈哈

  10. 老赵
    admin
    链接

    老赵 2006-12-03 12:48:00

    @蛙蛙池塘
    这些是Beta2的标准,不能用NDoc,不过可以在下一代的VS里支持。
    arguments是JS的方法被调用时,可以得到的“真实”参数的数组。
    Atlas发出请求没有使用队列,要有的话也是浏览器自动作的,浏览器限制了对于每个Domain只能有2个连接同时传输数据。
    Proxy就是代理,不过这里是作为Web Service访问的辅助对象用的。Extender里的Animation是指它提供的动画效果。:)

  11. 蛙蛙池塘
    *.*.*.*
    链接

    蛙蛙池塘 2006-12-03 13:48:00

    谢谢,明白了。

  12. 老赵
    admin
    链接

    老赵 2006-12-03 14:57:00

    @蛙蛙池塘
    从这里开始,就是RTM的东西,和正式版会非常接近。:)

发表回复

登录 / 登录并记住我 ,登陆后便可删除或修改已发表的评论 (请注意保留评论内容)

昵称:(必填)

邮箱:(必填,仅用于Gavatar

主页:(可选)

评论内容(大于5个字符):

  1. Your Name yyyy-MM-dd HH:mm:ss

使用Live Messenger联系我