ZK 支援两种 pattern 来开发：

• MVC (Model View Controller)
• MVVM (Model View ViewModel)

两者各有其长处，你可以根据你的开发习惯与偏好选择，不过因为 MVVM 有许多行为发生在 ZK 框架内部，你需要花时间了解框架内部的运作才能正确使用它，学习曲线在一开始会有点陡，因此这系列文章只介绍比较简单易懂的 MVC 模式，让初学者比较好上手。

MVC 简介

MVC 其实是个通用的软件模式词汇，泛指一般把系统分成模型（Model）, 视图（View）, 控制器（Controller）三部分的架构。ZK 借用这个词来指称「直接透过元件 API 来控制元件」的设计模式，这个设计模式是ZK 从 3.6 就支援的。 在 ZK 的架构下:

• View 指得是元件所组成的画面，可以说是 .zul 档
• Model 代表你的应用程序逻辑
• Controller 介於 View 与 Model 之间，责任是控制 ZK 元件、接受并处理元件发出的事件、将後端资料送到画面上、呼叫 Model 层。

这种设计模式下，你必需实作一个继承一个 ZK 内建控制器类别(建议用SelectorComposer) 的 Controller，然後在 Controller 中实做你的应用程序逻辑。实现的方法就是透过实作 event listener method 倾听元件上发出的事件（如 button 会发出 onClick 事件)，再透过元件提供的 API 来控制画面，例如我要将文字内容改变，就呼叫 Label.setValue()。

优势

• 简单易懂
  基本上就是类似 Swing 的概念，以元件为基础（Component-based）, 事件驱动（event-driven）。要做什麽就呼叫对应的元件 API，写出来的程序码很容易了解，学习门槛较低。一但发生错误，基本上大部分的行为都已经呈现在你自己写的程序码中了，比较容易判断。
• 能直接、完全的控制元件
  因为可以直接呼叫元件 API，因此可以直接以 Java 语言层面来控制元件的产生、消灭或各种行为，不需要间接地透过 data binding 语法，拥有做大的控制权。data binding 语法毕竟不像程序语言那样的的有表达力，直接以 Java 程序控制是弹性最大的做法。而且控制的实作都是呈现在你写出来的程序码里，必较没有隐藏在框架中的部分。

劣势

• 不易自动化测试 Controller。
  为了要控制元件，Controller 中必须宣告多个 ZK 元件型态的变数，这样才可以透过变数来控制画面，但这些元件的物件是由 ZK 框架执行期塞入到你实作的 Controller 中的。因此若没有启动应用服务器的的环境跟浏览器，你很难测试你的 Controller。（因此你需要用到ZK 测试工具 ZATS）
• Controller 易受画面变化影响而修改。
  同样是因为 Controller 包含 ZK 元件的关系，因为元件一定跟 zul 上所写的元件有一对一对应关系，因此如果画面修改，更换了元件，通常 Controller 也一定得修改。

MVVM 简介

ZK 6.0 之後开始支援此开发模式，这个 pattern 也把系统分成3个角色：Model、View、 ViewModel，跟 MVC 就差别在 ViewModel，其他两个角色都相同。ViewModel 也可说是一种特别的控制器，它负责将後端 model 的部分资料透露给 View，也提供 View 所需要执行的应用逻辑，如同一个视图抽象层 (view abstration)，包含 View 的状态(property)与行为 (command)。ViewModel 不会直接参考任何 UI 元件，也不该直接呼叫任何元件 API。ViewModel 将页面资料存在 property 中，并提供 getter, setter 让 ZK 存取，将页面所需行为实作在 method 中，例如搜寻、新增，我们称之为命令(command)。

你透过在 View 上撰写资料系结语法 (data binding) 来将元件状态与 ViewModel 中的资料、将事件与命令绑定在一起，ZK 透过这些资料系结表达是来帮你完成 View 与 ViewModel 之间的互动。例如 onClick 事件绑定到 add()，因此按下按钮就会呼叫 add()。

优势

• 易於重用 ViewModel。
  因为 ViewModel 完全没有参照到任何UI 元件，因此画面有些许更改也不用调整 ViewModel，只需修改资料系结表达式。如果另一页面需要的资料与行为相同，则能绑定到同一个 ViewModel 上，对於 responsive web design 很有利。因为通常画面元件可能会变化，但是显示的内容或行为却差不多。
• 易於测试 ViewModel。
  因为 ViewModel 本质就是一个单纯的 Java 物件（POJO），不需要继承特定父类别，也不需要实作特定介面。因此也不需要在 ZK framework 运作下测试，可以轻易用 JUnit 等测试，不需要启动 server。

劣势

• 学习门槛较高，不易除错。
  资料系结大量依靠 ZK 框架内部的运作来达到自动与 ViewModel 沟通的效果，因此初期需要花较多时间了解资料系结与运作的时机、规则。这过程也都发生在框架内部，如果不熟悉 ZK 的话，一但发生不预期的状况，会不知如何除错。
• 记忆体消耗较大。
  为了要维护元件与 ViewModel 之间的资料系结关系，ZK 内部需要产生、维护额外的追踪物件，因此会比 MVC 消耗更多记忆体。