PureMVC（AS3）剖析：吐槽

PureMVC（AS3）剖析：吐槽

寫在前面

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

1.  吐槽一：過於強調解耦

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

1.1.          Notification消息命名及管理復雜

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

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

n  消息ID為字符串，雖然字符串可以做到編譯時解耦，但無法做到消息強類型，這樣錯誤將推遲到運行時才能發現。

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

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

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

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

1.2.          強松耦合加重通信次數

PureMVC中模塊間通信推薦使用Notification機制，但是全部使用Notification這種強松耦合模式：①強松耦合加重通信次數；②帶反饋數據的通信加重通信負擔。

圖：UI使用Notification修改Proxy中的數據通信過程

PureMVC中UI修改Proxy的數據並返回后刷新過程：❶Mediator收到UI提交事件后，❷發送Notification消息給Command；❸Command進行業務邏輯處理，❹調用Proxy接口修改數據（這里還可能涉及到與服務器通信）,❺然后發消息給Mediator刷新，❻Mediator收到消息調用UI接口刷新。

因為都是消息機制，整個流程很長，而且Proxy中對數據進行操作后，發送Notification時，可能需要攜帶修改后的數據（可能是來自服務器的數據）。這個過程不僅通過次數多，而且帶反饋數據的消息增加通信負擔。另一方面要調試這個過程，我們只能在編譯的時候找出一步一步的通信流程，才能跟蹤調試。

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

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

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

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

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

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

4.  總結

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

相關文章

[1]     PureMVC（AS3）剖析：開篇，http://goo.gl/uqUV4

[2]     PureMVC（AS3）剖析：實例，http://goo.gl/UqnQh