pureMVC的爭議,說說缺點…

pureMVC的優點資料很多,他實現多種設計模式,解耦徹底,靈活度非常高,重用性高,易擴充.

 寫這篇文章僅表達本人的懷疑精神,如有不對,請指教學習.

首先先鏈兩篇我搜到的文章
PureMVC 的得與失
pureMVC優缺點

 

<設計模式：可複用物件導向軟體的基礎>說過一點,為適合的程式選擇適合的設計模式,其它介紹設計模式相關的書都有提過類似的觀點.pureMVC底層實現了多種設計模式,但是,那些並不是提供我們在適合的時候去用,而是約束各模組開發時,必須去用.

Controller是無狀態的,讀了裡面的代碼會知道,controller是訊息綁定Class對象,其實就是訊息過來時controller會跟椐訊息對應的class建立一個臨時對象,調用完裡面的方法就銷毀.大家都知道new多用會影響效能,大型項目訊息很多,一個事件可能會導致半秒數秒的延遲.

命令模式大多是用於日記,記錄,撤銷等關係處理,而pureMVC把所有命令都對象化了,冗餘和流程拉長是肯定的. 

Notification的官方說法是為了相容其它平台而棄用了內建的event,事實上Notification所提供的功能是不夠的,比如我們並不知道Notification的源頭.即誰發的.還有一點,adobe官方的事件機制的效率效能都比pureMVC自寫的方法高.個人覺得這塊應該留個介面供使用者選擇. 

訊息機制是pureMVC用來解耦最多的方法.不過個人覺得訊息機制不應亂用,我們試想一個例子,網頁提交資料後頁面某組資料全加1後重新整理.用pureMVC的操作是mediator收到ui提交事件後發個訊息給controller,controll進行商務邏輯處理,後發訊息繪proxy,proxy再找出要加1的對象更新,再然後發訊息給mediator重新整理.這個長長的流程,表面是四步,但是加上了訊息幀聽和接收,其實流了8步.而這個過程中,因為都是訊息機制,要調試這個過程我們只能在編譯的時候才能一步步找發來的是什麼對象,(或者遍曆訊息對象的方法),應該用什麼類去as它.可能我舉的例不是很好,但暫時沒想出別的了,有經驗的可以類堆.

很多設計模式書中都提過,觀察者模式適用於1對多關係的處理.而在一個項目中,view要觸發的controller大多數是一對一的,還是個人覺得,至少mediator跟controller的互動沒必須用到訊息.而controller跟proxy的訊息解耦代碼的很多時候是多餘的.

 

有人說pureMVC易維護,本人並不認為,大量的訊息發送接收調試起來其實很困難. Actionscript不像java支援泛型,而且訊息機制更容易讓訊息對象無類型.比如我一個vo的屬性改個名後,IDE並不能報錯,類型引用錯時只能編譯的時候才知道.修改調試起來不方便.而我更願意繼承官方event加寫有類型的對象. 

關於解耦的方法很多,事件,訊息只是其中一種,多讀flash api的類會發現adobe並不是亂用事件,因為事件是無類型引用的,所有處理事件adobe十分小心.繼承/覆蓋/組合都可以讓代碼複用而且易讀易調試.

解耦合是為了代碼複用,而複用是為了讓下一個項目不敲這麼多代碼,速度更快點.大量的訊息的管理雖然是做到了複用,但是下個項目的速度並沒達合理的快這個效果.(我的意思是部分模組如果不純用訊息的話,下個項目複用會更快)

 

不過解耦來來去去就是介面,抽象類別,訊息幾種方法;介面,抽象類別來解耦的缺點是介面,抽象改了,實現全都得跟著改.訊息的解耦就很靈活,不管方法屬性隨意添刪,不過缺點就是本文所說的.

 

補一段,很多新手不知道解耦,複用是什麼意思(我當年就是這樣),可以試試考慮寫一個GUI組件.寫的過程思考怎麼讓另一個程式使用這套GUI,(比如重寫,聽訊息,組合來使用).