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. 處理Module真是棘手啊

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

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

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

      ReplyDelete

    Post a Comment

    Popular posts from this blog

    PureMVC 我也會 [0]

    最近感覺 PureMVC 又熱了起來,也剛好好久沒有更新文章了, 就順便將去年底做的企業內訓 PureMVC 課程部分整理寫出來, 要講 PureMVC 當然要先從啥是 MVC 講起: Model-View-Control 出處: 維基百科 MVC ,大概節錄一段: (控制器Controller)- 負責轉發請求,對請求進行處理。 (檢視View) - 介面設計人員進行圖形介面設計。 (模型Model) - 程式設計師編寫程式應有的功能(實作算法等等)、數據庫專家進行資料管理和數據庫設計(可以實作具體的功能)。 其實到 Flash 的世界來講,Model and Control 都是由 .as 處理,而 View 便是 .fla+.as ,為了要鬆綁之間的關係,Event 機制就相當重要。其實每個人對 MVC 的最佳解釋都不同,真的要多練習才會有所領悟。 簡單來說: Model = 餐廳廚房 data: 西餐類 action:依照點菜單做餐點 action: 做完餐點就是將餐點放在出菜口按下通知鈴等服務生來 Control = 服務生 action: 聽到大門歡迎鈴就要說「歡迎光臨」 action: 看到客人揮揮手要去收點菜單 action: 聽到廚房通知鈴看是哪桌的餐點去送菜 View = 餐廳外場 view: 田園式的西餐廳裝潢 action: 客人進門會有歡迎鈴 action: 客人揮揮手叫服務生過來服務,是哪個服務生都無所謂,重點只要會收點菜就行了。 action: 客人收到餐點準備開動 當餐廳要改成外炒店,這時候只需要將大廚換成會中餐廚師,其出的菜就是中式快炒。 當餐廳外場由田園式外觀重新裝潢成華麗感夜店風,其進門的客層也會有所不同。 重點就是當你換掉一個地方時,對其它的部份不會造成太大的影響或者根本無所謂,這就是 MVC 所講求的境界... 一般來說,小專案有沒有必要使用 MVC 就是由各位自己判斷了,當你習慣將程式切分開來,發現 debug 不是一件痛苦的事情時,這時候有沒有強制使用 MVC 倒不是重點,因為你已經養成良好的撰寫習慣。但是開始接觸大型專案配合 team work 時,在沒有一個共用的核心框架前提下,這個專案開發到最後一定會是一個多手多腳的怪物,共用核心框架的價值就在這邊展現,這

    [Flex] Optilink雲端報價系統

    這個報價系統雖然是兩三年前的作品,一年前應客戶要求更新並改版到 v2.5,目前線上說明書也趨近完備,所以在這邊分享一下。 Optilink雲端報價系統線上說明書: http://optiland.asia/help/index.html 相關文章: [作品]Flex 3.4 + PureMVC 的企業級 RIA 應用