企業級Rich Client的設計模式

原創

2020-02-21 01:45

現在的軟件越來越大，越來越複雜，體現在用戶交互上尤爲明顯，導致相關設計開發不再像使用 IBM RPG 那樣簡單。開發人員需要了解很多的相關知識才能夠開發出一個健壯的 Rich Client, 本文就以設計模式爲切入點，對此展開討論，目的是讓大家通過本文對 GUI 設計領域裏的一些設計模式有個大概的瞭解。

看到這個題目，我估計絕大部分朋友會第一時間想到 model-view-controller （ MVC ）模式。的確這個是在 GUI 設計領域裏應用最爲廣泛的模式了， 3 個模塊相互之間交互，大家耳熟能詳，我就不多費筆墨了，不瞭解的朋友請察看相關資料。本文主要介紹一些大家可能還不太熟悉的模式，讓大家對 GUI 設計領域相關的設計模式有個大概的瞭解。本文只會對所有的模式進行粗略的介紹，文章末尾列出了每一個模式的原出處，如果哪位朋友對某個模式特別感興趣可以進行深入的解讀。

Autonomous View

軟件開發總是從小逐漸演變到大，從簡到繁。最初，一個 Frame 可能只包括一個 Panel, 上面只有幾個輸入欄，幾個按鈕。可能包含一些展示邏輯（ presentation logic ），但是這些邏輯是非常簡單的，這個時候我們應該使用 Autonomous View 模式，也就是隻用一個類來實現所有的功能。具體來說就是每個 window 或 frame 一個類，把實現展示邏輯的代碼直接寫到 view 類中。這樣做的好處就是方便快捷，缺點就是不太方便測試 , 一個類實現了多種功能，任何一個功能的改變都導致類的改變。

隨着軟件的成長，當 view 及其相關的展示邏輯變得比較複雜時， view 和展示邏輯就需要分開了，就好像當年 business logic 從 service 層脫離出來一樣。這樣做的好處是 view 和邏輯分離，代碼易於共享，易於管理；邏輯功能可以重複使用，易於測試。還有很多其他的好處，介紹 MVC 的相關書籍已做了詳細說明，我就不在這裏展開了。

在進行 view 和邏輯分離的工作中，到目前爲止有三種模式可以採用，她們分別是 MVC, Model-View-Presenter (MVP), 以及我會重點介紹的 Presentation Model.

MVC

我在文章開始就提到了不會對她進行展開，不瞭解的朋友請參考相關書籍。

MVP

由 Martin Fowler 發現並進行研究，從根本上來說，她只是個 MVC 的變種。在 MVC 中 view 直接處理相關的 GUI event ，比方說，鍵盤鼠標事件， checkBox 被選中，按鈕被按等等。而在 MVP 中 view 接收到事件，然後會將它們傳遞到 Presenter, 如何具體處理這些事件，將由 Presenter 來完成。從 class diagram 上來看，就是 Presenter 有 View 和 Model 的引用， Presenter 負責來管理其他兩個模塊。跟據兩者不同來看， MVC 比較適合用來開發 components, 而 MVP 比較適合進行 applications 的開發 , 因爲使用 MVP 導致絕大部分邏輯代碼集中在 Presenter, 而 view 變得非常簡單 , 適當採用良好的編碼風格，可以讓毫無經驗的編碼人員稍加培訓立刻上崗，大大加速開發 view 的速度，

Presentation Model

也是由 Martin Fowler 發現並進行研究，從根本上來說就是把所有的邏輯功能完全濃縮到 model 模塊裏去，這樣我們就只有 2 個模塊： View 和 Presentation Model 。其中 View 和 MVP 中的 View 一樣，具有上面提到的所有優點，而 Presentation Model 則起着承上啓下的作用，她連接 domain object 並將其展現在 view 上。看到這裏聰明的讀者可能會發現這個模式有個缺點，就是在 view, presentation model, 和 domain object 之間一定要保持同步。在其他兩個模式中，這個功能可以由 Controller 和 Presenter 來完成。而在 presentation model 模式中卻沒有一個合適的地方來實現，在 view 裏肯定不行，在 model 裏也不太合適。也就是說當我們使用 presentation model 進行開發時，我們所使用的框架必須要提供這種同步功能。在 windows 世界裏 .Net data binding 就是這種功能的實際實現。如果我們使用 Swing 開發，很抱歉， Swing 沒有這種功能。而作爲 Swing 的擴展， JGoodies binding 比較完美的解決的這個遺憾。

選擇

模式已經介紹完了，到了選擇的時候了。其實看到這裏大家應該已經有個比較清晰的 big picture 了。那麼當我們進行 GUI 開發時，何時選用什麼模式呢？我的建議是：

對於簡單的 view ，直接使用 Autonomous View.
開發 component 級別的 GUI, 至少要使用 MVC.
開發 applications, 則應該採用 MVP 或者是 Presentation Model

那麼如果是開發 application 到底應該使用 MVP 還是 Presentation Model 呢？這應該是絕大部分開發人員關心的問題。 Martin fowler 在他的文章中說是 it really comes down to how easy it is to do the pattern in your GUI environment and on your own personal tastes. 我覺得不完全對。還記得前面說 presentation model 有個缺點吧 , 就是那個同步的問題。問題總是有兩面性的，當我們換個角度來考慮這個問題時缺點就變成了優點了！簡而言之，如果再開發中使用了像 JGoodies 這樣的 framework ，她提供了完善的同步服務，那麼我們應該毫不猶豫的使用 presentation model, 因爲同步問題已被 framework 解決，應用開發人員不需要投入時間在這些問題上。而相反，使用 MVP 的話，應用開發人員卻不得不面對這些問題，直接導致開發週期延長。另外還有一個使用 presentation model 原因就是在 swing 中 presentation model 已經比較完善（請注意，是比較完善而非完美）得到了實現，比方說 ListModel, TableModel ，並且針對每一個 model 也都實現了同步。美中不足就是 swing 提供的每一個 model 都是針對具體 GUI component 的，而且沒有提供一個全局同步策略。而 JGoodies binding 比較完美的解決的這個問題。

最後還要提到一個比較小的模式就是 value model ，她是 value object 的變種，她提供了一種 set ， get ，和 observe 某個對象功能，這個對象通常是個 Java Bean ，當然也可以是其他的對象類型。這個模式在 JGoodies 中應用非常廣泛，我會在以後的文章中作深入講解。