Skip to main content

[Flex] Cairngorm v.s. pureMVC

跟 Cairngorm and pureMVC 相處過一陣子之後,在這邊與大家分享一下使用它們在 Flex 中的開發經驗(也許有錯誤的理解,請多指正囉!)

Cairngorm :
喜歡的部份:
  • 架在 Flex framework 上使用中央 Event (CairngormEventDispatcher )機制,UI 開發簡單 (因為容易理解...)
  • ModelLocator 採用 Flex 綁定機制,UI 顯示資料無煩惱
  • 由於上面兩項,所以使用 Module 開發專案不會很痛苦
    討厭的部份:
    • 主要的東西都是 Singleton design pattern, 如果專案很大的話,又統一在一起開發,那個 ModelLocator 到後來應該會很奇怪...
    • 綁太多細節在 UI component 內,如 UI component 一定要認識 ModelLocator 還可以直接操作或修改它...@@
    • Event 跟 Command 比多的...重點跟 pureMVC 的 command 比起來它的亂多了...
    • 專案越大越亂...
    pureMVC:
    喜歡的部份:
    • 大家的職責切分的很乾淨...棒 (這個只能意會不能言傳啊...XD 快去研究它吧!)
    • 寫在 UI (MXML)內的程式開發起來比使用 Cairngorm 的乾淨好幾倍(因為邏輯層被切分到 Mediator 了)
    • Notification & Command 果然是好物...雖然一開始感覺很囉唆,但是跟它熟了之後發現真是好用...
    • Proxy 比 ModelLocator 更加好用...因為不需要的 Proxy 要清掉也很容易...所以在資料的增減上,pureMVC 架構彈性比較高
    • 簡而言之就是乾淨乾淨乾淨~~~
    討厭的部份:
    • 它的架構比較像仙人一樣超脫於 Flex framework 之上,所以想要整合 Flex 的優點要花點腦袋想(結果這個也是優點...@@)
    • 很多語法都是要繼承並 override 寫起來不夠爽...快,這點 Cairngorm 大量的使用 interface 就棒多了。
    • 由於 Facade 的存在如果要使用 Module 與 MultiCore 版本來開發的話,還需要撰寫連接的元素,或者直接參考 pureMVC網站上的 Utility - AS3 / Pipes 來應用...不過我覺得加上 Pipes 的 UI component 就喪失了它的簡單美,可能會想別的方法來解決它...XD
    看到這邊大家應該蠻容易理解 Erin 最後的選項吧...ccc

    Comments

    1. 我現在也在做2選1的選擇
      看了你的文章後想想,我還是用PureMVC好了
      因為
      1.PureMVC還出了其他語言的版本,說不定哪天需要用Java Swing開發程式時也還用的上.

      2.Cairngorm我實在念不出來 = =

      ReplyDelete
    2. pureMVC 很好用喔!用了不會後悔,至少我目前手上的案子用的很開心~~~

      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…

    [AIR] JoSiResize - Mobile 開發小工具

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