Asp.net Ajax 用戶端編程 – Ajax 原理

    在關於Ajax.net上一篇文章中我提及到一個概念-兩分化編程模式。我們從這個開始說起，傳統的web編程都是伺服器端編程，我們多和伺服器開發技術工作在一起。也許你會說不是這樣呀，我們都在使用javascript來完成一些必要的用戶端功能呀（ASP.NET中的用戶端驗證煙支援用戶端的很多功能）！但不是使用javascript並不表示它的地位和伺服器編程的地位是一樣的。伺服器端開發中我們會涉及到的概念在用戶端中都是沒有比如：Application的概念，通常只是為了彌補一些伺服器編程模式中無法很好完成的功能，我們分解到用戶端來完成而已。

    Ajax的出現改變了現有的認識。用戶端可以和伺服器端開發技術一樣的重要嗎？伺服器通常被稱為"程式"而用戶端被稱為"指令碼"。在Ajax出現前幾乎很少有人願意承認用戶端開發能當作"程式"來看待，現在事情已經發生了改變，Ajax使得我們認識到用戶端需要被提升為"程式"來看待，至少要作為web程式的一個組件，而不再是控制一下DOM元素，做個絢麗的介面操作而已。在利用ajax技術的基礎上它一樣可以和資料管理、介面操作、程式層級管理功能一樣。Ajax.net 的用戶端類庫（library）為我們做到上面描述的概念。

    "曾經的頁面現在的Application。"

我先來描述一下傳統的web開發模式中經典的過程（無論是什麼技術作為web開發基礎其實都一樣）。

1. 通常是發起一個請求，這個請求被瀏覽器發送到伺服器。
2. 伺服器接受到這個請求執行伺服器上的預先編寫的代碼。（它通常會啟動或複用一個伺服器端的"Application"）。
3. 最後將執行後的結果作為響應發送到用戶端，（通常響應的內容就是廣義的HTML）。
4. 瀏覽器在接收到響應後負責將其呈現出來（顯示）。此時我們就可以在瀏覽器中看見結果（頁面）。

在上面描述的模式中，你能體會到什麼嗎？如果是上面的那種模式我們確實只需要關心伺服器端發生了什麼，反正你給我請求我就給你一個響應。還需要我做什麼嗎？最多我在用戶端用JAVASCRIPT做一下滿足客戶視覺的功能。沒有什麼不妥的。Ajax改變了什嗎？在最初我接觸Ajax的時候我覺得它不過是JAVASCRIPT的一種極限用法，不會對Web編程產生什麼"深遠"的影響。然而事情卻不是我想的那樣簡單。

    再來看看Ajax工作方式吧。

1. 假設頁面已經載入，頁面中充滿了HTML代碼、javascript代碼、CSS樣式。
2. 使用者對頁面進行操作，不小心觸發了一個對伺服器的提交。
3. 在Ajax下，頁面不再被重新整理，也見不到瀏覽器的進度條的指示，Ajax悄然的發起一個請求（非同步）。
4. 伺服器接收到請求開始執行伺服器端代碼，產生結果發送回瀏覽器。發送的內容是什嗎？不再是HTML了，而是資料。
5. 資料返回到瀏覽器，瀏覽器只能自動呈現HTML，它不知道所謂的“資料”是什嗎？你說它怎麼知道如何呈現它呢。茫然的地方也許就在這裡。
6. 資料其實被javascript代碼接收並進行處理。記得DOM嗎？我們可以使用JAVASCRIPT來控制DOM對嗎？可以想象以下。javascript接收到資料同時操作DOM將資料呈現。這也是ajax和傳統的web不同的地方。瀏覽器在傳統的web下會自動的呈現HTML，而在AJAX的環境中不會這樣。所有呈現的工作只能依賴JAVASCRIPT來處理了。  
7. 然後我們神秘的發現內容被更新了。

如果你是個很細心的人，你就會從這兩種描述中得到一些關鍵性的東西。我來指明一下，請求都是一樣的（本質上是不是，當我們暫時認為他們是一樣的）然後是響應。兩者都會給出響應，但內容卻不同，前者給出的一定是瀏覽器可以解讀的內容如HTML文本，而後者得到的響應卻是所謂的"資料"，它不能被瀏覽器得到，只能依賴javascript來處理。

      兩個關鍵的不同：

1. 傳統方式中，發起請求就意味著瀏覽器的內容要被重新整理。而後者導致的請求是偷偷的。
2. 傳統模式中，接受到的響應會被瀏覽器自動呈現在介面中。而後者是不會的。因為他得到的只是資料，呈現功能不再由瀏覽器幫你完成而是自己。

以上的兩點導致了這兩種開發模式註定是不一樣的。雖然不是很不一樣但一定不能堅持原有的開發模式了。

    Ajax開發模式註定需要開發人員更多的關注用戶端的功能，甚至會將更多原本在伺服器做的事情移動到用戶端來做。如果你需要在用戶端開發可靠的、高效的、受控的代碼僅僅使用原有的javascript的編程方式（我們常使用的）能行的通嗎？