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 下載並參考範例吧!

[AIR] JoSiResize - Mobile 開發小工具

JoSiResizev0.6.0,Adobe AIR 3 runtime之前開發 tool app 的時候並沒有很深刻的體認到圖片素材的 resize 是一個很麻煩的事情...畢竟圖片使用量並不大,等到開發遊戲類的 app 才發現光處理不同螢幕尺寸的圖片素材是一個相當折磨人的工作。
因此 JoSiResize app 誕生了~~~原理是採用最小 scale 長寬比例不變的方式進行放大縮小。使用方法非常簡單,設定好變更的尺寸,接下來,將需要處理的圖片檔案全選直接拖曳到視窗內,畫面即會跳出預備儲存的檔案夾選擇畫面,確認後即開始轉檔。

[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