callback的一般使用方法還算簡單，直接參考msdn的幫助和範例就足夠了。但想要真正用好、用精，或是想開發一些基於callback機制的WEB元件，那麼，就要先深入了解callback的實作機制了。在本文中，Teddy將和您一起解析callback的整個呼叫、回饋機制，相信對於幫助您更好的使用callback，將能有一定的益處。
Callback vs Atlas
首先，談談Atlas。很多朋友可能會覺得奇怪，已經有了Callback，為什麼又要出Atlas呢？關於這個問題，Atlas的作者怎麼解釋，我倒沒有去調查。只不過從我個人對callback和atlas的使用感受來講，覺得，callback作為一個介面和postback非常類似的實現，肯定是為了讓使用者類似使用postback來使用它。但是，它的這個類似postback的機制，應該說使用上還不是特別方便，也不易擴展，當然這是相比於其他的AJAX框架實現來說的。因此，微軟方面藉鑒了許多已有的AJAX實現，如Prototype，Backbase以及AJAX.NET，並結合ASP.NET2.0的部分特有功能，發明了這樣一個博採眾長的AJAX框架。基於Atlas來開發AJAX應用有多好，很難量化的來說，但至少不比其他的這些AJAX框架來的差是肯定的，加上微軟這個後台，以及像live.com這樣的重量級站點的應用推廣，其影響當然是值得期待的。
不過，這也不是說callback實作沒一無是處了，身為程式設計師，我們需要有正確的態度，在正確的使用情形，使用最正確的技術。沒有哪一個框架是萬能的，是適合任何使用環境的；就像大家都在爭論那個軟體開發方法最好，CMMi，RUP，XP，AGILE~~，其實，沒有最好，最合適的才是最好的。我們最應該做的，是了解各種方案的原理和優缺點，從而，合理的使用正確的工具來解決實際問題。
Begin from Client Script
我們都知道，凡是AJAX，從底層來講，無外乎兩種實作機制：XMLHTTP以及IFRAME。在AJAX這個詞獲得廣泛關注之前，其實，基於這兩種底層實現的功能框架，或者基於這兩種技術的無刷新效果實現就已經被廣泛的使用了。當然，發展到今天，在使用接口方面，這些底層機制的細節往往被框架給隱藏了，使用接口變得越來越簡單，用戶只要調用這些簡單接口，沒有必要知道具體是怎麼實現效果的了。
不過，這裡我們既然是要解析callback的實作機制，那還是讓我們從一個callback呼叫的客戶端腳本呼叫開始，看看，微軟是怎麼實作這個callback機制的。
1.ClientScript.GetCallbackEventReference(...)
要激發一個callback，首先，當然需要在客戶端本中發出一個呼叫。典型的呼叫語法如下：
＜script language="javascript" type="text/javascript"＞
function any_script_function(arg, context)
{
＜%= ClientScript.GetCallbackEventReference(this, "arg", "ReceiveServerData", "context")%＞;
}
＜/script＞
ClientScript.GetCallbackEventReference(...)將根據傳入的參數傳回實際的回呼腳本。這個函數有多個重載版本，因此，這些參數的意義，大家可以參考MSDN。以具體的上面這段範例程式碼中的參數來說：
- this表示執行回呼的的服務端控制項是目前這個Page，目前的Page必須實作ICallbackEventHandler接口，包括必須實作string GetCallbackResult()和void RaiseCallbackEvent(eventArgument)這兩個介面函數，這個參數也可以是指向某個WEB控制項的引用，當然，這個空間也必須實作ICallbackEventHandler介面；
- "arg"是將被傳給RaiseCallbackEvent的參數eventArgument的值，可以使人自定義格式的字串；
- "ReceiveServerData" 是當回呼成功之後，處理返回內容的客戶端腳本函數的名稱，這個函數必須存在於執行回調的頁面，並且這個函數可以包含兩個參數，例如：
＜script type="text/javascript"＞
function ReceiveServerData(result, context)
{}
＜/script＞
這兩個參數，分別是回呼的回傳資料result，和原封不動被傳回的我們激發回呼時的這個context參數，當然，這兩個參數都是字串類型的。
- "context"就不用多解釋了，記得這個參數會被原封不動的傳給指定的回傳資料處理函數就行了。 MSDN的官方文件說，context一般可用來傳遞需要在客戶端的回傳資料處理函數中用來呼叫的腳本程式碼，不過實際上，你傳什麼都可以，把它看成一種從客戶端回呼的的激發端，到處理回傳資料的接收段之間的參數傳遞通道就行了。