Model 是資料模型
View 是顯示畫面
Controller 是程式流程
在PureMVC架構下是由一個 Facade 管理 Model、View 和 Controller
根據PureMVC說明文件和Facade pattern的定義
Model class、View class 和 Controller class是確實存在的
但是我們看不到，因為已經被 Facade 包裝起來了
我們能寫的部分是Proxy、Mediator 和 Command
然後註冊給 Facade
理論上，Facade 應該會：
將 Proxy 交給 Model 管理
將 Mediator 交給 View 管理
將 Command 交給 Controller 管理
但因為Facade已經將MVC架構包裝好了，所以我們並不需要管這些東西
就我的觀點來看
每個 Mediator 會負責管理一個像是flash內建 "組件" 的那種東西
只有這個 Mediator 有權力存取這個組件
組件則是在畫面上的控制項，組件本身應該要提供和使用者互動的能力
而在PureMVC，將組件稱為viewComponent
在 Mediator 裡，我們應該會寫兩種東西
1. 註冊 "什麼時機(Notification)" 要去存取 viewComponent
2. 當使用者對 viewComponent 作互動時，丟出 Notification
我認為一個TextField加上一個Sprite不能說是viewComponent
因為他沒有經過包裝，提供存取的方法
我在某些人的範例中有看到 Mediator 會包含一些 viewComponent 本身的存取方法
但如果Mediator 跟 viewComponent 切不開，那麼組件就無法在其他專案重用
或者說重用 viewComponent 的時候你就會發現你的 Mediator 有些 code 會重複
每個 Proxy 會負責和內部或外部資料作存取
在這裡指的內部，是指存在 flash player 記憶體中的變數資料
外部應該是後端的 web service server 或是某個外部檔案，總之不是在記憶體內的變數資料
我們會在 Proxy 裡面寫好存取內外部資料的程式，和丟出資料變更的事件
最後我們會在 Command 決定何時該去存取 Proxy
其中 code 可以在其他專案重用的部分有 viewComponent 和 Proxy
Mediator 和 Command 應該是很少機會能重用
以上全是猜測，因為我沒寫過PureMVC專案，我只看過文件和幾個範例和參加第1次AS讀書會
如果要用我上次畫的精美圖片來解釋 javascript 版本的 web programing
那就是用 Mediator 去包裝 3、4
用 Proxy 去包裝 2、5
用 Command 串接 2 → 3 和 4 → 5
不過我現在重看這張圖我好像數字寫錯了，執行順序應該是 4 → 5 → 6 → 1 → 2 → 3
4 則留言:
真有趣的心得。
雖然，我認為主講人可以再說多點，不過能有這樣的心得也不錯了。
另外，幫你補充一下。
>> 我在某些人的範例中有看到 Mediator 會包含一些 viewComponent 本身的存取方法
>> 但如果Mediator 跟 viewComponent 切不開，那麼組件就無法在其他專案重用
>> 或者說重用 viewComponent 的時候你就會發現你的 Mediator 有些 code 會重複
博主的說法，鄙人假定是說viewComponent必須完整封裝，對外只有數據與命令的單純操作。
這樣的設計猶如Youtube API。
這點，請先回歸到OOP原本的定位。
在理想情況上，所有單元都應該可被重複使用，但實際情況並不可能發生。
主要原因出自客製單元會因為畫面問題導致不可避免的極微小修改。
因此，在Mediator和viewComponent會有無法切開或無法完整切開的問題。
再依造viewComponent的實用上的分別來看，例如：按鈕的動作可重複用，但按鈕的圖示會變化。
這種情況則會設計成按鈕單元有部分的資訊仰賴使用viewComponent的Mediator。
對於此狀況，viewComponent的設計會混合使用鬆散耦合和繼承兩個方式，實際被封裝的僅是單元動作部份。
而這樣設計也可混合應用於Composite和Decorator兩個pattern上。
此外viewComponent的概念，可參考Architectural Pattern：Presentation-abstraction-control。
這個Pattern也可以解釋Flash本身所有MovieClip、Sprite的構成。
另外，博主最後那張圖很有趣。
MVC的研究是在幾年前的事情，印象中當時和負責IBM計畫的博士朋友討論過一個問題。
“如何用網際網路來表達MVC的結構。”
最後的結論是，HTML、Flash為View，Client-Server的網路環境為Control，DataBase為Model。
但是，Flash和DataBase內又可細分為MVC結構，最後整體畫起來卻又變成了HMVC / PAC ... XD
>> 用 Command 串接 2 → 3 和 4 → 5
這句真是有趣。
( _ _ ) ... 以上，是看完博主內容的心得。
樓上的文太難了看不太懂T_T
再換個角度想
Mediator 和 Proxy 除了包裝畫面和資料之外
還有一個功能就是當 pureMVC 的 Adapter
因為他們將溝通形態轉為 Notification 了
T .. T 太難了！！
抱歉，看你的心得，我以為專有名詞大大多少有碰過。
>> 我在某些人的範例中有看到 Mediator 會包含一些 viewComponent 本身的存取方法
>> 但如果Mediator 跟 viewComponent 切不開，那麼組件就無法在其他專案重用
>> 或者說重用 viewComponent 的時候你就會發現你的 Mediator 有些 code 會重複
我的心得，是因為你對封裝的說法有點僵硬說的。
實際上，物件封裝的完整度高低會影響物件間使用的關係，這稱為“藕合”。
如果物間之間耦合強烈，表示A物件的修改會導致B物件也必須修改。
而博主所的內容，我假設是指強烈鬆散耦合設計。
這樣的設計，確實可增加物件的再利用，但對於應變突發或微小變化的設計會過於僵硬。
因此，對於物件的設計，是一門詭異的課題，有些情況當然頃向博主的設計 ( 大部分情況 )，但有時會設計可應變用的不完全封裝物件。
這樣的設計，你也可以想像成可以依自己喜歡決定顏色的杯子，杯子本身不變，但在顏色等小地方是允許外部干涉。
以上，希望這部份博主看得懂。
張貼留言