原文：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代码。