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

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

[書評] 拖延心理學:為什麼我老是愛拖延?是與生俱來的壞習慣,還是身不由己?

作者: Jane B. Burka & Lenora M . Yuen 推薦指數 ★★★★★ 有時候,只是想了解事情發生原因而不是尋求解法 在這邊不是要講這本書的內容,而是想聊它對我的影響。