以伺服器端為中心的ASP.NET AJAX模式 (Part 2

在上一篇文章當中，也就是《以伺服器端為中心的 ASP.NET AJAX 模式 (Part 1 - Behavior)》，我們探討了較為易用的Behavior模式。之所以說它較為易用，是因為它 不涉及和原有Page處理流程的互動，即使訪問網路也是訪問獨立的Web Service（包括Page上的[WebMethod]），因此和Page處理流程的設計絕對是正交的。但有時候我們需 要的就是與Page處理流程的互動，這時我們不得不使用與伺服器端邏輯緊耦合的Control了，這正是本次文章要討論的內容。

在基本的ASP.NET AJAX架構下，我們有 三種方法來做基於Control的Ajax操作，它們分別是UpdatePanel、ICallbackEventHandler和IScriptControl，下面我們就分別看看它們的特點和使用情境。

UpdatePanel

UpdatePanel是與伺服器端邏輯進行互動的多種方案中最易用的一個，甚至就不能稱之為互動——你根本就不需要觸及任何用戶端邏輯。 一個伺服器端操作，經過UpdatePanel的“劫持”，變成了一個用戶端操作，而這個用戶端操作又直接調用對應的伺服器端操作，就這麼簡單。

如果用 UpdatePanel來做一個帶分支的選擇對話方塊，那應該如何設計？思路可別跑到用戶端的confirm方法上去，那可太繞了，或者說太不ASP.NET AJAX了。用UpdatePanel，就應該 堅持它的理念，一切用戶端操作都是幻象，所有操作其實都是在伺服器端進行的，包括選擇對話方塊。要按ASP.NET的思路來做，我會做一個選擇對話方塊控制項，它的實質可能是 一個浮動層類比的對話方塊，這屬於實現細節，我們不用太關注。重點是，這個選擇對話方塊的分支邏輯是完全在伺服器端進行的，Async PostBack之後伺服器端根據提交回來 的資料決定如何觸發事件。這樣做整個分支選擇的邏輯就是內嵌在Page處理流程當中的，不需要通過Cookies或者Session來做資料的中轉媒介，避免了Page處理流程與更大 範圍中的資料的緊耦合。

UpdatePanel適用於邏輯完全在伺服器端的開發，並且我建議使用UpdatePanel時也就把所有邏輯放在伺服器端，不要去寫一些混合伺服器 端邏輯與用戶端邏輯的代碼。有人會說，你看老趙就很喜歡去動那個Sys.Net.WebRequestExecutor來改變UpdatePanel的行為啊，但其實這屬於分層設計思想中的一部分，他 去動那個東西改變的也就是一個分層內的邏輯，只要層與層之間的介面不變，具體實現是可以按需設計的。但如果你用了UpdatePanel，同時又用Cookies或者Session來傳值 ，這就跨越了n個層，增加了不少耦合度。

ICallbackEventHandler

關於ICallbackEventHandler，我已經說過無數次了，重點還是你必須用Page處理流程來思考， 只要你理解了Page處理流程，你就明白為什麼ICallbackEventHandler在.NET Framework 2.0 Beta2中只有一個方法，而到了RTM要分拆成兩個方法。具體可以參考《ASP.NET 2.0 ClientScript Callback》，我就不再重複了。

如果用ICallbackEventHandler實現一個帶分支的選擇對話方塊，又如何做？和使用UpdatePanel的做法類似，我還 是會做一個選擇對話方塊控制項，並且這個控制項繼承自ICallbackEventHandler。為這個控制項編寫JavaScript並實現ICallbackEventHandler介面時，我會確保JavaScript對 Callback給出正確的調用參數，並在介面方法的實現中接收這些參數然後觸發正確的事件，就這麼簡單。和UpdatePanel一樣，不要偏離了ICallbackEventHandler的設計思 想，它的處理流程必須是合并到Page處理流程中的，你的控制項也就必須這樣設計。

至於在什麼情況下選擇ICallbackEventHandler？如果你有一個輕量級的Ajax操作 ，但使用UpdatePanel更新整個地區的HTML開銷很大的話，那麼你可以考慮使用ICallbackEventHandler。當然，前提是你懂得控制項開發和JavaScript。