PureMVC（AS3）剖析：吐槽

寫在前面

世上沒有銀彈——不存在適用于所有情況的框架，只有適合的框架。再者任何一個好的東西（語言、框架等）最終還取決于用的人，語言和框架本身并不能保證用戶的代碼清晰、解耦等，當(dāng)然它只是盡可能地做到這點(diǎn)。所以記住我寫這篇不是為了否定PureMVC，相反是為了更好的了解它、使用它。

1. 吐槽一：過于強(qiáng)調(diào)解耦

PureMVC引入了多種設(shè)計模式、消息機(jī)制（使用觀察者模式，發(fā)布/訂閱模式）來解耦各個模塊，它確實(shí)做到了這點(diǎn)，但是徹底解耦是需要代價的！

1.1. Notification消息命名及管理復(fù)雜

PureMVC為了做到跨平臺，使用Notification來實(shí)現(xiàn)模塊間通信，而非Flash原生的EventDispatcher/Event機(jī)制。然而Notification使用字符串來定義消息，存在以下“問題”。

注：Notification并不是Event的替代物。一般情況下，Mediator給其視圖組件添加Event偵聽器，按常用方式處理，然后給目標(biāo)Command/Mediator廣播Notification。

n 消息ID為字符串，雖然字符串可以做到編譯時解耦，但無法做到消息強(qiáng)類型，這樣錯誤將推遲到運(yùn)行時才能發(fā)現(xiàn)。

n 消息命名，在一個大型項(xiàng)目中，需要一套詳細(xì)的規(guī)則。相信我，否則你會吃苦頭的。特別是多人參與項(xiàng)目中，如果沒有按照一定規(guī)則命名，命名沖突可是會讓你調(diào)試一陣。但不管你如何定義命名規(guī)則，【記住】為了模塊間解耦，Notification發(fā)布者應(yīng)該不關(guān)心誰對這個消息感興趣（誰來處理），感興趣者自行注冊（Mediator通過listNotificationInterests注冊、Command通過facade.registerCommand()注冊）。例如當(dāng)Proxy中用戶信息改變時，不應(yīng)該sendNotification通過“UpdateUserInfoVIew”、“UpdateFriendListView”2個通過來分別更新用戶信息、好友列表中對應(yīng)用戶的信息，而只是發(fā)送一個通知，如“UpdateUserInfo”，用戶信息欄、好友列表都注冊這個消息，然后分別處理。

n 無法知道Notification的源頭。然而這點(diǎn)可以通過在消息體body中，增加字段標(biāo)識，如：

sendNotification(ApplicationConstants.UPDATE_LEVEL_DATA, { "noticeSource": this, "levelData": m_levelData } );

noticeSource標(biāo)識消息來源，如果您還想要知道消息傳遞層次，可以用數(shù)組表示，順序插入傳遞者。

1.2. 強(qiáng)松耦合加重通信次數(shù)

PureMVC中模塊間通信推薦使用Notification機(jī)制，但是全部使用Notification這種強(qiáng)松耦合模式：①強(qiáng)松耦合加重通信次數(shù)；②帶反饋數(shù)據(jù)的通信加重通信負(fù)擔(dān)。

圖：UI使用Notification修改Proxy中的數(shù)據(jù)通信過程

PureMVC中UI修改Proxy的數(shù)據(jù)并返回后刷新過程：Mediator收到UI提交事件后，發(fā)送Notification消息給Command；Command進(jìn)行業(yè)務(wù)邏輯處理，調(diào)用Proxy接口修改數(shù)據(jù)（這里還可能涉及到與服務(wù)器通信）,然后發(fā)消息給Mediator刷新，Mediator收到消息調(diào)用UI接口刷新。

因?yàn)槎际窍C(jī)制，整個流程很長，而且Proxy中對數(shù)據(jù)進(jìn)行操作后，發(fā)送Notification時，可能需要攜帶修改后的數(shù)據(jù)（可能是來自服務(wù)器的數(shù)據(jù)）。這個過程不僅通過次數(shù)多，而且?guī)Х答仈?shù)據(jù)的消息增加通信負(fù)擔(dān)。另一方面要調(diào)試這個過程，我們只能在編譯的時候找出一步一步的通信流程，才能跟蹤調(diào)試。

2. 吐槽二：解耦增加了代碼量，不方便調(diào)試

解耦的同時將使項(xiàng)目修改的復(fù)雜程度提高，某些解耦的辦法還會增加代碼量、降低執(zhí)行效率。PureMVC是一個強(qiáng)解耦的框架，其效率本身不是很高，函數(shù)調(diào)用層次較深，而有時根本不清楚消息發(fā)到了哪里。

PureMVC為了實(shí)現(xiàn)解耦增加了代碼量，不方便調(diào)試，但哪個MVC框架不是呢！這不是PureMVC的問題，已經(jīng)有前輩編寫了PureMVC模版，如FlashDevelop的模板（下載），使用模板可以減少手動編寫代碼量，但不能減少類的數(shù)量。

有篇文章詳細(xì)介紹了PureMVC的耦合與解耦：耦合與脫耦——深入分析為什么使用pureMVC、接口或抽象基類（入口http://bbs.9ria.com/thread-161667-1-1.html）

3. 吐槽三：過度使用單例模式

單例模式過于萬能，屬于高耦合寫法。PureMVC中有4個單例Model、View、Controller、Fa?ade。我們可以通過Model、View、Controller的getInstance()方法獲取實(shí)例，并對他們進(jìn)行操作。然而Fa?ade是用于管理Model、View、Controller并對外提供接口。如果Model、View、Controller對外不可見，為什么要設(shè)定為單例，而不是Fa?ade的成員變量呢？

4. 總結(jié)

上面說了一些PureMVC的缺點(diǎn)，不過總體來說PureMVC還算一個優(yōu)秀的框架，解耦徹底、靈活性高。

本文轉(zhuǎn)自吳秦博客園博客，原文鏈接：http://www.cnblogs.com/skynet/archive/2013/02/17/2914742.html，如需轉(zhuǎn)載請自行聯(lián)系原作者

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結(jié)

以上是生活随笔為你收集整理的PureMVC（AS3）剖析：吐槽的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。