Skip to main content

PureMVC 我也會 [6]

Mediator
  • ViewComponents 與 pureMVC 架構的中介
  • 監聽並反應 View Component 發出的 Event
  • 可以發送與接收 Notification
  • 儘量少操作 Proxy 公開方法,多用 sendNotification...

Mediator design pattern
要多認識這個 Mediator 設計模式的話,請自行看連結說明啊! 簡單來講,假使有一個 View 裡面有好幾個 MovieClip
組成,而這些 MovieClip 會互相影響對方...這個情況在 Flash 中,通常都會變成下圖:

MovieClip 直接控制其他 MovieClip 搞到整個關係很複雜...換一個元件簡直是災難。
加入 Mediator 後,示意圖就會變成:

這樣,所有的 MovieClip 都透過 Mediator 來跟其他 MovieClip 溝通,當某一個 MovieClip 替換成別的元件,這時候也只需要修改 Mediator 中的引用即可,是不是變得很乾淨?如果同一組 MovieClip 有另外一個操作模式,也只需要替換掉 Mediator 即可!天下太平啊~~~

而 PureMVC 中就是利用 Mediator class 為與前端 ViewComponent 的中介,這樣可以切開 ViewComponent 與 PureMVC framework 的關係,不管你前端介面使用 Flash or Flex 製作都跟程式核心無關。

所以 ViewComponent 製作時只需要兩個原則,一把所有的請求都以 Event 送出由 Mediator 處理,二提供公開方法, Mediator 只需要監聽 View 的 Event,將收到的資訊透過公開方法喂進 ViewComponent 即可。
如在 ViewComponent 中:

public function setList( result:Object ):void{
list.dataProvider = result as ArrayCollection;
}

//然後在按下取得資料的按鈕 Click action 寫上:
dispatchEvent( new Event( "GET_LIST" ));

新建 Mediator 的時候一樣有幾個重點方法需要覆寫,onRegister, onRemove, listNotificationInterests and handleNotification。
處理 List ViewComponent 的 Mediator:

package com.mvc.views
{
import com.mvc.models.ListProxy;
import fl.core.UIComponent
import flash.events.Event;

import org.puremvc.as3.interfaces.INotification;
import org.puremvc.as3.patterns.mediator.Mediator;

public class ListMediator extends Mediator
{
public function ListMediator(mediatorName:String=null, viewComponent:Object=null)
{
super(mediatorName, viewComponent);
}
override public function listNotificationInterests():Array
{
//要處理啥訊息都在這邊列好,列出有興趣的 Notification
return [
ListProxy.LIST_CHANGED
];
}
override public function onRegister():void{
//監聽 view 的 Event
view.addEventListener( "GET_LIST" , onClick );
}
override public function onRemove():void{
//記得在 onRemove 中移除監聽
view.removeEventListener( "GET_LIST" , onClick );
}
override public function handleNotification(notification:INotification):void
{
//listNotificationInterests 有列這邊才收的到喔!
switch(notification.getName()){
case ListProxy.LIST_CHANGED:
view.setList( notification.getBody());
}
}
private function onClick(event:Event):void{
//假使已經做了一個 Command 來處理 ListProxy request...
//facade.registerCommand( "GET_DATA_LIST", ListProxyCommand );
sendNotification( "GET_DATA_LIST" );
}
//給自己看的,重點還是轉換物件型態
private function get view():UIComponent {
return viewComponent as UIComponent;
}
}
}


當然,要先註冊 ListMediator:

//listViewComponent 為畫面中某個 ViewComponent
facade.registerMediator( new ListMediator("ListMediator", listViewComponent );

Mediator 跟 ViewComponent 並不是只有一對一,也是可以控制多個 ViewComponent 喔!完全是看你要如何組織而已。
在 team work 中,處理前端介面的工程師其實只需要會串接 Mediator 即可,可以不用真正的熟悉整個 PureMVC 的運作,這樣分工起來簡單很多。

可喜可賀!!!恭喜大家撐到現在,主要的 class 都講完了!這份教學就是要配合實作才會更容易理解,就請各位多看一些範例吧!多練習才是王道啊!

相關連結:
PureMVC 官網上範例
[Flex] pureMVC Standard 練習筆記
[Flex] pureMVC 練習筆記啪兔
[ AS3] 簡單講客製 Event
[Flex] pureMVC and Utility - StateMachine
[Flex] pureMVC and Utility - StateMachine(2)
[AS3]PureMVC Utility - AsyncNotifier
Google PureMVC 任意門

Comments

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 時,在沒有一個共用的核心框架前提下,這個專案開發到最後一定會是一個多手多腳的怪物,共用核心框架的價值就在這邊展現,這

[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