DIV CSS 佈局教程網

 DIV+CSS佈局教程網 >> 網頁腳本 >> JavaScript入門知識 >> AJAX入門 >> AJAX詳解 >> 深入Atlas系列:WebSevicesAccessinAtlas(8)
深入Atlas系列:WebSevicesAccessinAtlas(8)
編輯:AJAX詳解     
在RTM Release之前,我已經差不多將Web Service Proxy的分析寫完了,可惜一個“驚天地泣鬼神”的RTM一出,這片文章的誕生晚了20多天。

  使用Web Service Proxy應該是使用ASP.NET AJax訪問Web Service最常用的方法了。服務器端會根據ScriptManager中添加的Service引用而對於Web Service類進行分析,並生成相應的客戶端腳本。這樣開發人員就能在客戶端方便而且直觀地訪問Web Services方法了。這是ASP.Net中很重要的功能。

  從官方文檔上看來,CTP和RTM似乎在腳本使用這方面沒有很大的改變,只要在服務器端將一些CustomAttribute改變一下就可以了。的確沒錯,在使用方式上只有這點細微改變,但是事實上,從生成腳本本身來說,CTP和RTM的做法大相徑庭。它們的之間的區別主要有兩點:
  1. 對於生成服務器端類型的腳本(例如您可以使用new Jeffz.WebServiceProxyDemo.Employee()來構造一個對象)來說,CTP中可以自定義,RTM則不可以。
  2. 對於生成WebService方法的代理來說,CTP生成的代碼很少,RTM生成的代碼很多,但是符合客戶端“類”的標准。也就是說,RTM版本完全將一個服務器端的類“映射”到了客戶端——當然只有需要生成代理的那些方法,也不包括其實現。另外,RTM中增加了Cache功能,這是通過返回status code為304實現的。
  我在標題中的“可歎”大都是指第1點。在RTM中,客戶端Serialize方法取消了對於自定義序列化的支持,這樣在服務器端也少了相應自定義服務器端類型腳本的功能。原本能夠使用自定義的辦法,“完美”地在服務器端和客戶端處理復雜對象中的“循環引用”問題,現在當然已經行不通了。從這一點上來說,真不知道算是進步了還是退步了,雖然依舊能夠使用JavaScriptConveter進行擴展,但是從“美學”上來說,現在的做法只能屬於“workaround”的范疇。而且,對於服務器端代碼的分析也沒有很大的價值了,因此在這片文中我只是對於客戶端的Proxy腳本進行一些分析和比較。

  至於第2點,個人認為是配合了目前的Web Serivce訪問方式而改變的。它遵守了以下的規范和特點:
  1. 使用ASP.Net AJax中定義“類”規范將服務器端Web Service類映射到了客戶端中。 
  2. 提供了客戶端訪問Web Service方法所需要的proxy。
  3. 支持defaultUserContext、defaultSucceededCallback和defaultFailedCallback。
  對了更清晰地理解CTP和RTM之間的區別,以及RTM中構造Proxy的形式,我們來分別看一下CTP和RTM中的proxy腳本(以下Proxy代碼均經過整理)。

  首先,我們在CTP和RTM中定義一個相同的復雜類型:Employee。代碼如下:
namespace Jeffz.WebServicesProxyDemo
{
    public class Employee
    {
        public string Name;

        public int Age;
    }
}
XML學習教程| jQuery入門知識| AJAX入門| Dreamweaver教程| Fireworks入門知識| SEO技巧| SEO優化集錦|
Copyright © DIV+CSS佈局教程網 All Rights Reserved