Skip to main content

[Flex] 再談 Cairngorm2 framework

最近很不怕死的支援了一個 ERP project(常做半路接手或支援的工作),原始的開發團隊使用的是 Flex 4 SDK, Cairngorm2 框架,雖然上一次發表 Cairngorm2 的文章是兩年前,不過還是很快的進入狀況。

以下是真實開發後使用 Cairngorm2 的個人感想:
先談缺點...(果然迫不及待啊...)
  1. Singleton ModelLocator 的設計果然是一個敗筆:
    不使用 DI(依賴注入)的話,每次新增一個 Model 都是一種折磨,尤其是團隊開發,新增、修改 = 在 ModelLocator 引入或修改。每個 View 都可以操作所有在 ModelLocator 的 public data,Model 內有大量的 bindable IListCollection,因為不這樣做 list 無法同步。若沒有完整列出清單的話,可能有不同 Model 分別持有相同的 list data query。
    更麻煩的是,如果是非同步 update 的 data ,Model 就必須持有兩份相同的 data instance 供比對操作...

  2. Bindable 是個兩面刀:
    有它會讓你上天堂,也很有可能更快讓你下地獄...為了達到資料同步,必須大量的綁定 View 所使用的 deta,Model 無法主動通知做了啥事(除非是建一個公開綁定的屬性跟 Views 綁在一起,又或者透過 CairngormEvent 回 call viewHelper ,但是前提是這個 Event 必須註冊到對應 command 又是一堆 C & E)
    不然就是得使用 BindingUtils 做 watcher,但是重點就是 Model 必須公開綁定所有待操作的資料!總之如果一開始沒有規劃好的話,團隊開發就是一團亂...addCommand() 都 add 不完。

  3. 一點小事情就需要一個 command,與對應的 Event:
    在團隊開發中,如果核心 command 沒有開立完整的話,有時候 view 相關的 command 所操作部份都太過 detail ,會造成差不多的東西可能都要搞好幾份...當然這個情況已經在手上的專案看到了...

  4. Delegate 與 Command 也多多:
    Delegate 明明是用來組織分類對外連線部分,並且做 data parse 又或者配合一個 Command 處理完後送回分類好的 Model,但是一開發起來卻變成每個 view 都有自己一組 delegate+command+model,不然很難分開開發,每次新增修改都要動用到 FrontController, ModelLocator,每天光同步 code 就同步不完。
    不過還是老話一句,事前有規劃好還是可以減少很多多餘的工作。但是太多團隊開發都有時程壓力,想要好好規劃也要看 SA 願不願意花時間設計...

  5. Views 也是亂七八糟:
    Views 可以直接操作 Model public data 已經不是新聞,正因為可以直接操作,所以 Views 有可能會包含大量操作 data 邏輯,下場就是差不多的功能在不同的 View 都有相同的 functions...除非很認真的送回 Model 做更新,這樣有時候也很危險,因為很可能 Views 在一個不小心就改到 Model data 還無所知覺, bug 就是這樣來的!!!!

再來是優點...
呃...列不出來啊~~~~~~~果然 PureMVC 還是我的本命啊~~

不過說實話,有好好的初期規劃,應該還是不會陷入無限的混亂迴圈啦!
Cairngorm + DI 應該是個不錯的選擇...在 Cairngorm3 已經有看到 [Inject] 相關字眼的 metadata 應該是已經大量的被改善過了吧?

結論:
公開的 Singleton design pattern 果然要小心使用啊!
Cairngorm2 已經落伍了,請改用 3 吧...= =

Comments

  1. 不過實際上, Cairngorm 3 只是提供一個方針和一些函式庫而已,並沒有提供MVC框架。

    ReplyDelete
  2. @葉山 輔助函式庫應該有讓 Cairngorm 好用多吧?我是放棄它了,跟它無緣,要不是支援專案也不會想去使用它...= =

    ReplyDelete

Post a Comment

Popular posts from this blog

[Unity] erinylin.lazylib - Cookie for PlayerPrefs

有鑑於 PlayerPrefs 測試與版本更新問題,將大家都愛用的 PreviewLabs.PlayerPrefs 打包起來,製作重點還是以懶人為主,基本上 PlayerPrefs 資料更新與數量並不可能會有強烈衝擊效能的狀況產生,所以為了方便開發,就弄了一個視覺化工具,方便除錯用。

雖然 PreviewLabs.PlayerPrefs 作者都宣告放棄他們的版權,不過為了尊重程式,僅僅加入了兩個公用函式,其他並無更改。

內有:
Cookie ManagerCookie 用 DataObject 混合編輯 ScriptableObject執行階段除錯視窗工具當然還是有懶人常數檔案輸出資料版本控制,方便更新版後儲存資料更新功能其實很多,有興趣的請自行到 Github 下載並參考範例吧!

PureMVC 我也會 [1]

為什麼要學 PureMVC ? 明明網路上一堆免費的 MVC 微型框架,為什麼 Erin 特別愛用 PureMVC?
嚴格說起來,使用 PureMVC 開發的專案寫出來的 class 檔一定比 一些簡化版 PureMVC base 的 framework 如 Robotlegs 多,也比較難入門,但是為什麼要特別推薦它?

答案很簡單,越基本的東西反而是最好延伸,留白越多的紙最好畫!也因為如此才令人著迷啊...(咦?)

百分百真情推薦:
大家的職責切分的很乾淨...棒訊息傳遞機制是好物由於架構超然於 Flash / Flex 架構上,反而在 team work 分工的時候更方便擁有多個程式語言的版本,想要入門其他語言是個不錯的選擇Source code 公開化,要改要加什麼隨便你~~出來的時間比較久相關資源多
接下來就來看圖說故事。
PureMVC Diagram, 出處:PureMVC 官網

當初第一眼看到這張圖的時候,真的挺像個變形蟲,不過想要快速了解 framework 的基本運作流程,最容易的方法就是看圖說故事...

PureMVC 核心是由四個單例(singleton design pattern) 組成: Facade, Model, View and Control,唯一出入口就是 Facade,你會發現圖示中 Model, View and Control 都是雙向指向連接到 Facade,它們互相不清楚其他人的存在。

這四個 Class 你也只需要認識 Facade 即可...=)

Facade :
圖示中, Facade 下方有三個圈圈分別是 Mediator, Command and Proxy,意思是所有實作這三種 class instance 都是透過 Façade 來註冊移除或取用其他資源。拿 Flash 來比喻, Facade 很像是 root,所有的 DisplayObject 顯示、操作和移除都可以透過 root 抓取實體後執行,所有實體都可以透過 root 去找到其他實體。在 PureMVC 中, 它最大的作用就是切開 MVC 彼此的依賴,也提供 user 一個統一的操作出入口。

Model, View and Control
你會發現這三個大圈圈旁邊都有一堆同色的 Proxy, Command and Mediator,當各自的 class inst…

[Mac app] 開啟 Mac OSX 中自帶的 Color Picker 並加上 HexColorPicker 功能

參考出處:Mac — Adding Hex Color Picker to Color Picker

Mac app store 上有很多 Color Picker app,差不多 98% 都是需要付費,而這個小工具恰恰是開發中不可缺少一個東西。其實 Mac OSX 中就有自帶一個 ColorPicker,秉持著 DIY 的精神,用幾個小步驟就可以組合出顯示 Hex 色碼的 ColorPicker.app。

Mac 系統需求:10.4 and up