Jesse Wardens 的一篇名為 “10 Tips For Working With Cairngorm” 的文章給了我寫這篇 PureMVC 的10個(gè)小提示的靈感. 我已經(jīng)用PureMVC六個(gè)月了,而且我現(xiàn)在很喜歡它(這已經(jīng)是一個(gè)公開的秘密了).不過(guò)有言在先,下面的所有見解都只是基于我的個(gè)人經(jīng)驗(yàn)而已.
1.用(Pure)MVC的思想去思考
我應(yīng)該如何開始使用(Pure)MVC呢? 一句話:用(Pure)MVC的思想去思考! 從它的名字中就可以看出, PureMVC 是基于一般的 Model-View-Controller 元設(shè)計(jì)模式的.使用Facade-pattern 這種模式你不需要直接instantiate the core actors, 但是PureMVC中的每個(gè)Class都有它自己的定義很清楚的角色:
- Proxies = Model
- Mediator and its ViewComponents = View
- Commands = Controller
2.為View Components創(chuàng)建API
一個(gè) View Component可能是一個(gè)標(biāo)準(zhǔn)的UI component (比如DataGrid) 或者自定義組件 (比如一個(gè)游戲世界) 或者其他的東西. 不要直接使用它的 public方法. 而是把改變它的狀態(tài)或者行為(等允許被外部調(diào)用的各種方法屬性)寫成API.
PureMVC 的一個(gè)有點(diǎn)就是可以與所使用的技術(shù)無(wú)關(guān). 舉個(gè)例子:我建了一個(gè)基于PureMVC的'Pure' Flash application ,沒有用到Flex Framework. 而后,為了使用AIR里面的File System API這個(gè)Application被轉(zhuǎn)成一個(gè)AIR application.這時(shí)只需將View Components轉(zhuǎn)化為使用 Flex Framework即可, 其他的Mediators 或者任何PureMVC中的任何actors均不需改變 .
3.多個(gè)View Components共同使用一個(gè)Mediator
為了緊密協(xié)調(diào)多個(gè)View Components 僅使用一個(gè)Mediator. 換句話說(shuō): 不是所有的Views 都需要Mediator. 例如: 有一個(gè)ApplicationControlBar,其中包含一個(gè)TextInput ,一個(gè)Button 或者其他的組件. 然后為ApplicationControlBar 創(chuàng)建一個(gè)名為ApplicationControlBarMediator的 Mediator 并且把它指定給ApplicationControlBar中所包含的所有View Component.
4.讓Events bubble up起來(lái)
如果你不想在一個(gè)Mediator中用多個(gè)View Components 又會(huì)怎樣呢?為了處理多個(gè) View Components的用戶交互事件, 我們必須把View Component里面嵌套的所有組件的事件bubble up起來(lái).
例如: 當(dāng)你點(diǎn)擊View Component 里面的任意Button都會(huì)觸發(fā)Mediator監(jiān)聽的一個(gè)自定義事件. 所以Mediator并不需要知道這個(gè)Button是否存在或者任何一個(gè)這個(gè) View Component的其他Child,它只需要知道這個(gè)事件已經(jīng)被觸發(fā)了就可以.
5.盡可能地的用Notifications通信
Notifications是PureMVC 里面的“Events” . 當(dāng)Model, View and Controller 三者之間的通信是下面幾種情況時(shí)應(yīng)該盡可能地的使用這個(gè)Notifications :
(通信 from -> to)
- Mediator -> Proxy (via mapped Commands)
- Proxy -> Mediator
- Proxy -> Command
- Commands -> Mediator
即使可以從Mediator獲得Proxy,也不要直接用Mediator來(lái)改變Proxy.應(yīng)該是用一個(gè)mapped Command來(lái)發(fā)送Notification. 不通過(guò)使用Command (Controller)而用Mediator (View)來(lái)直接改變 Proxy (Model) 是一種非常糟糕的方法.
6.盡可能多的使用 Commands / MacroCommands
Commands 在控制端做這些工作: Retrieving and interacting Proxies, 與Mediators通信或者執(zhí)行其他Commands. 即使一個(gè)Command僅被用了一次或者只有兩行代碼也要盡可能多的使用它. 為了在你的Application中可以隨時(shí)隨地的再次執(zhí)行一個(gè)Command ,僅需發(fā)送一個(gè)Notification.以后也可以很容易的用更復(fù)雜的actions來(lái)擴(kuò)展這個(gè) Command. 還有非常重要的一點(diǎn)就是你總是知道改變Proxy (Model)的actor是哪一個(gè).
問(wèn)題: 你有沒有遇到過(guò)需要按照特定次序執(zhí)行多個(gè)Command的情況呢? 使用MacroCommands可以順序執(zhí)行多個(gè)SubCommands (也就是 “簡(jiǎn)單” Commands) .
7.使用Remote Proxy來(lái)接收和發(fā)送服務(wù)端數(shù)據(jù)
在Application 中的發(fā)送和接收數(shù)據(jù)的Proxies 叫做“Remote Proxies”. 它不是一種特殊的PureMVC Proxy, 只是一個(gè)基于Proxy的location,而這個(gè)Proxy是負(fù)責(zé)處理比如HTTPSerivice,RemoteObject或者其他服務(wù)端調(diào)用的 Proxy.
例如: 為了調(diào)用服務(wù)器端一個(gè)負(fù)責(zé)登錄用戶的RemoteObject 而創(chuàng)建了一個(gè)叫做LoginProxy的Proxy. LoginProxy負(fù)責(zé)所有與服務(wù)器端通信的工作, 也就是接收和發(fā)送數(shù)據(jù). 當(dāng)你為L(zhǎng)oginProcess改變服務(wù)器端執(zhí)行操作時(shí),你值需要改變Application中的一個(gè)locationt即可,即 LoginProxy.
8.去掉沒有用到的Mediators
在某些情況下你不再使用一個(gè)Mediator和它的View Components. 你應(yīng)該用facade.removeMediator(MyMediator.NAME)去掉這個(gè)Mediator同時(shí)用 destroy()來(lái)去掉包含所有l(wèi)isteners,timer,references的ViewComponent.以便更好的進(jìn)行 垃圾回收.
9.VO's (Value Objects)的魅力所在
當(dāng)然在Model中存放數(shù)據(jù)的是Proxies. 而且View Components不需要知道Facade和這個(gè)PureMVC application的其他部分. 這就意味著View Component不會(huì)直接訪問(wèn)Model的數(shù)據(jù).
為了避免在View Component中存放數(shù)據(jù)可以使用一個(gè) 名為Value Objects (VO’s)的引用 . VO's并不是PureMVC里面的核心actor,它和Flex里面的Data Binding有點(diǎn)淵源,是一個(gè)可以在不打破規(guī)則的情況下改變Model的數(shù)據(jù)的非常強(qiáng)大的方法..
10.可以找到的課件
Cliff Hall 做個(gè)一個(gè)值得敬畏的工作: 不僅有非常好的文檔 “Framework Overview“, “Best Practices” and a “Conceptual Diagram“, 而且還有非常非常有用的 課件. 自己去看看吧!
本站僅提供存儲(chǔ)服務(wù)，所有內(nèi)容均由用戶發(fā)布，如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容，請(qǐng)
點(diǎn)擊舉報(bào)。
