不管是現在剛開始接觸 ZK 或是用過一陣子的人都可能會遇到的問題是到底要用 MVC 或 MVVM 的方式開發。從 ZK 8 之後又把 MVVM 的能力更佳的擴展，所以 MVVM 會是一個功能更強的開發方式。但 MVC 在使用上比較直覺，仍有其優勢，所以我想決定性的因素會比較是開發者的偏好及專案的特性。你可參考下面的比較來決定哪種方式比較適合你。
優勢比較
MVVM
- ViewModel 較不易受畫面變動影響。
- 因為 ViewModel 沒有變數直接指向 ZK 元件，因此若是畫面上有元件更改，ViewModel 一般不需要修改
- ViewModel 較易於在不同頁面中重用。
- 因為 ViewModel 只包含資料跟業務邏輯，若是不同頁面需要的資料跟業務邏輯相同，就可以重用同一個 ViewModel
- 例如 A 頁面按按鈕執行搜尋，B 頁面點選單執行同樣的搜尋，則可以重用同一個 ViewModel 中的 command，只是兩個頁面 data binding 寫在不同的元件上。
- 畫面較易於重用（易於模組化）。
- 透過 shadow component 跟 template 機制，可以將一段頁面的片段做成可以接受傳入參數
- 套用 Responsive Design 的成本較低。
- 通常需要針對不同裝置設計不同版面，但是顯示的資料內容大同小異，因此 ViewModel 多半可以重用
- 易於套用美工所設計的畫面，或是網路上現成的元件。
- 易於整合第三方 javascript library 或 widget。
- 因為 ZK 8 提供了一個可以讓你透過 javascript 去呼叫 ViewModel 中的 command (client side binding) 的方式來跟後端溝通
- ViewModel 的可測試性較好。
- 因為 ViewModel 不需要繼承特定類別跟實作特定介面，可以輕易地執行單元測試
MVC
- 操控元件方式直覺好學、易懂。
- MVVM 控制元件較不直接，需要了解 zk framework data binding 的行為
- 可以完全使用元件所提供的所有 API。
- 仍有極少部分 ZK 元件行為沒辦法用 MVVM 控制。例如產生
Messagebox,Listbox.renderAll(),Popup.open()。但這都可以改用直接控制元件的方式來解決，只是就是非 MVVM 的方法，喜歡維持一致的開發模式的人可能不會喜歡
- 仍有極少部分 ZK 元件行為沒辦法用 MVVM 控制。例如產生
- 易於控制客製化元件
- 這裏是指透過繼承既有元件的 java class 所創造出來的客製化元件，若要能以 MVVM 方式控制，還必須要額外加上 data binding 的設定
比較簡表
| MVC | MVVM | |
|---|---|---|
| controller 與畫面的耦合程度 | 較高 | 不耦合 |
| 如何實作 controller | 需繼承ZK的SelectorComposer | 不需繼承特定類別或實作特定介面的一個 Java class (POJO) |
| 如何控制 UI 元件 | 透過元件的 API | 透過 data binding |
| 更新 UI 的方式 | 直接操作元件 | 透過 ZK 內建機制自動更新(需加上 @NotifyChange) |
| 元件控制的精細程度 | 很精細，可以完全控制 | 主要控制元件 attribute |
| 整合後端其他服務的方式 | 在 controller 中直接呼叫 | 在 controller 中直接呼叫 |
留言