跳到主要內容

ZK 教學 - 使用 MVC 或 MVVM?

不管是現在剛開始接觸 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 的方法,喜歡維持一致的開發模式的人可能不會喜歡
  • 易於控制客製化元件
    • 這裏是指透過繼承既有元件的 java class 所創造出來的客製化元件,若要能以 MVVM 方式控制,還必須要額外加上 data binding 的設定

比較簡表

MVC MVVM
controller 與畫面的耦合程度 較高 不耦合
如何實作 controller 需繼承ZK的SelectorComposer 不需繼承特定類別或實作特定介面的一個 Java class (POJO)
如何控制 UI 元件 透過元件的 API 透過 data binding
更新 UI 的方式 直接操作元件 透過 ZK 內建機制自動更新(需加上 @NotifyChange)
元件控制的精細程度 很精細,可以完全控制 主要控制元件 attribute
整合後端其他服務的方式 在 controller 中直接呼叫 在 controller 中直接呼叫

參考資料:

留言

這個網誌中的熱門文章

JavaScript 關掉瀏覽器頁面

如果你直接呼叫 window.close() 來關掉目前的頁面的話,你應該會在 console 看到以下訊息:
Scripts may close only the windows that were opened by it.
( 我在 Chrome, Firefox, IE 11 都試過)
主因就是你並沒有用 JavaScript 開啟這個頁面,所以也不能用 JavaScript 關掉它。這是 HTML window.close() 的規格規定,各家瀏覽器應該都遵循。

隨著瀏覽器安全性增加,以下方法已經不適用了,可參考這個討論


有個變通的辦法就是:
window.open(location, '_self').close();


Code Complete, 2ed (中譯:軟體建構之道) 讀後心得

Code Complete, 2ed (中譯:軟體建構之道)讀後心得

雖然以前在學校有修過軟體工程,但是說實在現在我對建構軟體的整個概念都來自於兩本書:「人月神話」(The Mythical Man-Month)、Code Complete[1]。我畢業後第一份工作是軟體研發工程師,我們公司所開發的系統大約有近百位工程師共同維護,當然各有依功能與專業知識將系統劃分不同的區 塊來維護,在面對大型的系統與這麼多人寫程式是以前在學校沒有遇過的,因此也開始思考怎樣才是好的軟體開發方式。從大學好友那探聽到了Code Complete這本書,花了上千元買了英文版,(現在中文版已出,簡體版聽說只要三分之一的價錢)認真讀了幾篇之後,真是如獲至寶,於是自己讀過後,還跟同事組成讀書會一同研討這本書。
作者Steve McConnell (個人Blog http://www.stevemcconnell.com/)著作不算量大,但是我看過的幾本質量都很好,印象中他曾經在微軟工作過,後來成立一家軟體顧問公司Construx Software
這本書(書本網站 http://cc2e.com/Default.aspx)的討論主題很廣泛,但是並不空泛,從最小的、最基本的如何寫出好的程式, 例如函式(routine)、註解 (comment)、變數的命名等,也談整個軟體建構的過程除錯、測試,最後也談到軟體工程師個人能力與技術生涯的發展,算是各方面都有提及。但是我比較 建議有半年以上的實際程式經驗來讀這本書比較適合,我自認為如果我在學生時代接觸本書,可能沒有什麼太大的感觸,因為面對的都是小格局、人數少的小系統, 書中所探討的原則與例子,很多時候沒有團隊開發或大型系統的經驗,很難體會。但稍有經驗的人,看完之後保證在程式撰寫與軟體開發方面的觀念會有很大的提 昇。
Table of ContentLaying the Foundation
1 Welcome to Software Construction
2 Metaphors for a Richer Understanding of Software Development
3 Measure Twice, Cut Once: Upstream Prerequisites
4 Key Construction DecisionsCr…

AJAX 網頁卡住?可能是超過瀏覽器同時連線數上限 (max HTTP connection)

若你的程式中使用如 comet 這種 server push 技術的話,就會產生一個不中斷的 HTTP 連線,也就是發出的 AJAX request 不會立即收到伺服器的回覆,一般來說並不會造成問題,但若是使用者開啟多個頁面 (tab) 的話,就會產生多個不中斷連線,而各個瀏覽器對於同一個網站所允許的同時連線數的上限一般不大,多為 6 的左右,請參考 Connections per hostname一旦達到連線數上限,之後所發出的 AJAX request 都會卡住而不會送出。從瀏覽器的 developer tool 就可以觀察到,你會發現不會顯示任何 request 相關的細節。更詳細的套論可以參考相關文章: Maximum concurrent connections to the same domain for browsers這個跟 Firefox 的 network.http.max-connections-per-server 不同,這是指 Firefox 本身總共能發出的 HTTP 連線數總量,也就是所有 tab 加起來的數量。