[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 吧...= =