Skip to main content

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 instance 透過 Facade 註冊後，其 class instance 會被這三個單例做儲存。

Proxy, Command and Mediator
除了 Facade 外，這三個 class 一定要好好認識它們。Proxy 用來儲存資料與其邏輯運算，Command 則是頂呱呱的棒當然是能用儘量用，而 Mediator 是用來串接 ViewComponent 與 PureMVC 架構的橋樑。圖示上三個 class instances 會互相連接，這全部都是 Facade 與 Notification 的功勞啊~~

躲起來的 Observer & Notification
PureMVC 用的訊息傳遞機制，不能不認識它，不過不用擔心，實際應用起來卻是簡單到不行！

所以整個 PureMVC 其實只要將 Facade, Mediator, Command, Proxy and Notification 搞懂就圓滿了...(驚!)

同場加映：
AS3 版之 Standard and Multi-Core 的差異
Standard 版本的四個單例是基本的 Class。但是 Multi-Core 版本是 Array，用來承接複數的 Facade，Multi-Core 辨識的方法就是賦予 Facade 一個 String Key，所以要跨 Facade 應用也是挺容易的，就是透過 String Key 找到目標 facade，手工寫連接工具，或者參考官網上的 Pipes utility 來做串接。
兩個版本的寫法差異非常小，通常 Multi-Core 版本都是用來開發多人大型專案才會使用到，否則一般練習與中小型專案，使用 Standard version 其實就很足夠了！反正就是挑一個順眼的用就可以了...=)

推薦文章：
其實一堆朋友如邦邦、奶綠茶、Ticore 等都寫過 PureMVC 的文章。請認真的 google 一下~~
google 任意門
DesignPatterns_Singleton - 奶綠茶 << 不知道啥是 Singleton 的同學們請先到這邊補課一下。
PureMVC Best Practices 官網上的「最佳練習」中文版
[Flex] pureMVC Standard 練習筆記

to be continued....
Labels:

Comments

Post a Comment

Popular posts from this blog

PureMVC for Unity

幾個月前改用 Unity 開發遊戲，到目前的心得為：組件式開發真的是很便利，但是當組件數量多到一定程度時，結構上就有點可怕，常常在某 GameObject 上掛了組件後就忘了它的存在，雖然可以使用 Singleton design pattern 來製作主要的 Manager（本人對 Singleton 並不是很熱愛），程式還是會亂到一定程度，搜尋了一些 Unity with MVC 討論，一部分的人都對實作 MVC 不是很熱絡，也許是 Unity 特有的開發環境導致。 以前開發 Adobe Flex 專案最愛用的 MVC Framework 就是 PureMVC，即使後來有更方便的 MVC Framework 的也擋不住我對它的熱愛。Unity 是沒有所謂的全域 Root Scene，所有場景都是獨立，想要將 AS3 實作邏輯套用在 Unity 上將控制項都在 PureMVC 架構中實作是有點矯情多餘。如何保持 Unity 組件開發模式，導入 PureMVC 鬆綁主要邏輯，就是這次實驗的重點。 不清楚 PureMVC 的朋友們可以到這邊參觀一下： PureMVC 我也會 PureMVC C# Standard Framework on GitHub ViewComponent 與 Mediator 整合是首要工作： 由於 Unity 沒有全域 Root Scene，如果將 new Mediator( viewComponent ) 寫在 PureMVC 架構下，即使透過 GameObject.Find 找那個對應的 GameObject 就轉了九彎十八拐，寫起來一點都不愉快，尤其考慮到場景的轉換，兩個場景中相關 Mediator 的註冊與移除處理，何況對 Unity 組件來說，能不能被打包動態載入是件重要的事。綜合以上問題點，反向思考，改由 GameObject 掛載中介組件，在 OnEnable 與 OnDisable 通知 Facade 去註冊與移除其 Mediator，一來簡化為了實作 Meditaor 掛載 ViewComponent 而對 static class GameObject 的依賴，二來也不會對 Unity 組件開發模式有太大的影響。
1 comment
Read more

[Swift3] weak 與 unowned 關鍵字

雖然在 Swift 中看起來"很像"是不需要煩惱內存管理的問題，不過實際上它還是遵循著自動引用計數 (ARC) 的規則，當一個物件沒有被其他對象引用時會自動被銷毀，如果三魂七魄沒有完全回位的話，就會有個靈體留在現世的空間裡，最經典的範例如下： 閉包(Closure)引用 classClassA { typealias Complete = ()->() var name : String var onComplete : Complete? init(_ name: String){ self.name = name print("Hello I am \(self.name)") onComplete = { print("\(self.name): onComplete!") // --> 閉包引用 self, 計數 + 1 } } deinit { print("deinit: \(self.name)") } } var a : ClassA? = ClassA("A") // --> 引用計數 + 1 a = nil // 2-1 = 1 還剩下 1 所以沒辦法銷毀 ---output------- Hello I am A 由於這邊的 onComplete 宣告為 Optional, 正確的做法要連同 onComplete 一起刪除才可以被回收，若不是 Optional 則會進入無法回收狀態： var b : ClassA? = ClassA("B") b?.onComplete = nil // --> 還好是 Optional 可以設成 nil 計數 - 1 b = nil // 計數 = 0 所以被回收 ---output------- Hello I am B deinit: B 但是做人不需要煩惱太多，這時候就出動 unowned 關鍵字讓物件可以順利被回收： onComplete = { [unowned self] in print...
4 comments
Read more