富有經(jīng)驗(yàn)的Java開發(fā)者Per Olesen在Tech Per上發(fā)了一篇博 客文章，比較兩個(gè)最流行的Flex框架，PureMVC 和Cairngorm，并且著重比較了可用性和它們對GUI架構(gòu)模式的應(yīng)用。
在開發(fā)中以設(shè)計(jì)模式為指導(dǎo)已經(jīng)是Java開發(fā)者的基本技術(shù)。在Flex和ActionScript開發(fā)者當(dāng)中，設(shè)計(jì)模式的實(shí)踐要么是從Java開發(fā) 經(jīng)驗(yàn)中來的，要么就是由一些ActionScript/Flex框架帶來的。Olesen描述了這個(gè)過程：
為了幫助架構(gòu)這類應(yīng)用，發(fā)展出了一些GUI架構(gòu)的模式。其中一些比較著名的模式，Martin Fowler已經(jīng)作了很好的描述，比如a >Presentation Model（呈現(xiàn)模型）和Supervising Presenter。它們不是像MVC一樣完整的用戶界面架構(gòu)，而是一些比較小的架構(gòu)指引，涉及的是應(yīng)用程序的邏輯如何與視圖框架的API聯(lián)系 起來。
他解釋說：
PureMVC有一個(gè)名為Mediator的 構(gòu)造，顧名思義，它就是Mediator 模式的實(shí)現(xiàn)，充當(dāng)視圖API和程序其余部分的API之間的中介。這是PureMVC實(shí)現(xiàn)MVC架構(gòu)視圖部分的關(guān)鍵構(gòu)造。引入它是為了減少應(yīng)用和視 圖之間的依賴，從而降低整個(gè)系統(tǒng)的耦合程度。
Olesen還指出PureMVC有一份關(guān) 于實(shí)現(xiàn)之慣例和最佳實(shí)踐的文檔，文檔中還以實(shí)際的例子LoginPanel進(jìn)行解說。在例子里可以看出，只有mediator了解視圖，視圖對 mediator一無所知。
在分析了PureMVC的文檔提供的源代碼之后，Olesen相信這個(gè)其實(shí)就是Supervising Presenter模式或者Passive View（被動(dòng)視圖）模式。兩種模式都把行為從視圖中抽出來，將之放入與視圖耦合的一個(gè)表現(xiàn)類。在兩個(gè)模式中，都是“表現(xiàn)者知道視圖，視圖不知道表現(xiàn) 者”。因此兩種模式的區(qū)別在于如何抽取邏輯。PureMVC的mediator與Supervising Presenter最為接近。
談到Cairngorm框架，Olesen的觀察是：
Cairngorm沒有mediator、supervising presenter,或者passive view的概念。實(shí)際上批評它的人很多，因?yàn)樗拇档姆桨甘菍⒁晥D組件的狀態(tài)直接綁定到模型。但更糟的問題是模型只是通過單體模式表達(dá)的一個(gè)全局狀態(tài)。
在Cairngorm文檔和例子（無論是簡單的聯(lián)系人管理程序還是比較復(fù)雜的Cairngorm Store）中，這個(gè)問題更加突出。視圖中有許多邏輯，而且是按照Autonomous View（自治視圖）模式來安排的。什么是Autonomous View模式呢？Martin Fowler的回答是：將一個(gè)窗口所有的表現(xiàn)狀態(tài)和行為都放在一個(gè)類里。
Olesen覺得這種模式等于是沒有模式。他覺得采用Cairngorm的應(yīng)用程序里的自治視圖是在鼓勵(lì)直接把數(shù)據(jù)綁定到一個(gè)全局模型的實(shí)例上，非 常不利于分離視圖和模型兩者的關(guān)注點(diǎn)。
最后，Olesen并非簡單地認(rèn)為這個(gè)框架比那個(gè)好，他的結(jié)論是：
無論是哪個(gè)框架，UI模式都只是框架的一部分，雖然是重要的一部分。有人會覺得PureMVC自帶的東西更多一些，mediator是框架中內(nèi)建的 概念。中介者及以通知方式進(jìn)出中介者的通信，都很好地整合進(jìn)了PureMVC框架。
查看英文原文：Comparing GUI Patterns in PureMVC and Cairngorm 閱讀全文
(###)
