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一般可用來傳遞需要在客戶端的返回數據處理函數中用來調用的腳本代碼，不過實際上，你傳什麼都可以，把它看成一種從客戶端回調的的激發端，到處理返回數據的接收段之間的參數傳遞通道就行了。
