原文：http://dev.firnow.com/course/1_web/webjs/200877/131843.html

ZK架構一覽

前言

經過這十幾年的發展演變，Web應用從靜態的HTML頁面演化成動態HTML頁面，然后是Applet和Flash，最終到了Ajax技術。

Ajax面臨的挑戰

在滿足用戶需求而提供的交互性活動時，Ajax增加了應用的復雜度和本就費用高昂的web應用開發所必需的技能。

• 在不同瀏覽器間不可共存且容易產生bug的Javascript API
  
• 對于用戶來說重復業務邏輯產生的維護開銷，尤其是在不同的編程語言情況下
• 經應用數據模型和業務邏輯暴露給用戶的危險
• 令人頭疼的使客戶端和服務器端保持一致的異步通信。
  

當前解決方案

為了提供一個可管理的Ajax解決方案，目前已經有許多的框架或者類庫。最直接的方式是提供立即可用的Javascript控件。然而，應用程序開 發人員必須生成這些控件，在客戶端中加入業務邏輯，并且開發一個應用特定的方式來與服務器端交互數據。

簡而言之，這里只解決了前面提到過的Ajax面臨的挑戰中的第一個。其他的挑戰，或多或少還是會繼續不斷地騷擾我們的應用開發人員。難道這就是 Web應用程序開發的本質么？或者只是傳統的Web應用編程模型已經不適用了呢?

ZK架構

為了解決這些挑戰，ZK給Web應用提 供了桌面應用編程模型天生就具備的事件驅動、基于組件以及以服務器為中心的架構。此外，ZK提供了當前流行的UI開發技術，例如通過標志語言而不是編程來 設計UI，通過腳本語言動態地改變應用，不需要編程就可以訪問數據庫和Web服務的注解和數據綁定。

正如上圖所描述的，ZK是由運行在瀏覽器上的客戶端引擎組成的，而更新引擎則位于服務端。他們就像是棒球里的投手和捕手。他們一起配合，將瀏覽器上 發生的事件提交給運行在服務器端的應用，同時根據如何在服務器端生成組件的方式，來更新瀏覽器的DOM樹。

作為核心，所有的應用代碼都運行在服務器端。任何時候被用戶出發的時間都會被自動地發送到運行在服務器端的應用程序。在服務器端的組件發生的任何改 變，都以可視化的方式顯示在瀏覽器上。瀏覽器只是應用的表現層，沒有數據模型，也沒有業務邏輯會被暴露出來。

因為應用程序是運行在服務器端，所以它可以直接地訪問后端的資源，例如數據庫或者Web服務。在Internet上訪問它們時毫無通信上的麻煩和安 全隱患。

在不知道其存在的時候， 才使用Ajax最好的方式 。

執行流程

• ZK客戶端引用位于瀏覽器中，用于查探任何有用戶活動驅動的事件，例如鼠標的移動或者修改了某個值。一旦探測到事件，它便會通知ZK更新 引擎。
  
• 從客戶端引擎接收到請求后，如果必要，ZK更新引擎便會更新對應組件的內容。然后，如果有事件處理器，更新引擎就會通過他們來通知應用。
  
• 如果應用選擇改變組件的內容，刪除、增加或者移動了組件，更新引擎將會發送新的、改變了的組件到客戶端引擎上。然后，客戶端引擎便會相應 地更新DOM樹。
  

• 為了減少客戶端和服務器端的訪問，如果事件可以延時，那么會把多個時間發送回服務器端。
  
• 為了最大化視覺效果和響應能力，ZK提供了一個所謂的客戶端動作，讓你可以（可選的）在客戶端執行你擁有的Javascript代碼。