PureMVC使用心得

       PureMVC大大的優化了我們使用FLEX進行前台的開發，使得整個開發過程變的較為可控，但是如果放任程式員去自由的使用pureMVC也會帶來很大的隐患。本文内容主要記錄我使用pureMVC開發原型這一個星期來使用的一些開發規範和經驗總結。

1.  如果有個項目有幾個開發人員共同開發，同時采用版本控制工具對項目項目的源碼進行版本控制，可是維護通

知的名稱着實讓人煩惱，我們若要将通知名稱放在同一 個類中{ApplicationFacade}就不能很好的使用版本控制工具，因為每個人都要修改這個類 {在你修改時你要看看别人是否已經修改該檔案，别人若是修改了還得讓他送出，然後自己更新再修改，太痛苦了!} ，而且都放在一個類裡也會增加維護的難度，那麼有沒有什麼好的辦法呢？

     通常一兩個人做個例子時遇到這種情況可能比較好解決，單如果參與的人較多的化，可能花在協調上面的工作

量就會比較多，為了增加開發的速度，使開發變的更加的簡單，我們可以讓通知名稱分散到各個子產品的Mediator

類中進行維護{每個子產品首頁面的協調類，可根據自己的系統大小控制粒度}，這樣每個開發人員可以隻要維護自身的通知名稱或者隻要與一兩個人進行協調，同時我們要求每個通知名稱都要包含該類所在的包路徑和類名稱，具體的格式可以是“通知名稱+包路徑.類名稱”，這樣我們隻要保證通知名稱唯一，且便于日後維護。

2.  每個Mediator，Proxy都要定一個NAME屬性，通常我要求每個NAME屬性必須是“包路徑+類名稱”，也是 

為了避免不必要的沖突，找半天BUG。

3.  PureMVC中Mediator似乎什麼都可以坐了，Command的用處似乎不大。

     這是一個錯誤的看法，雖然我們在Mediator中可以直接擷取到Proxy，Mediator類的對象，也可以注冊

Mediator，Proxy，Command，但是我們必須給自已一個限制，不然随着開發的不斷深入你會發現代碼也越來越亂。是以我們增加了較為嚴禁的限制：

       3.1 通常情況在程式啟動後，Mediator負責注冊Command，以及派發通知和接收通知，當Mediator類需要進行目前範圍外的一些操作時就可以通過派發通知的方式。一般來說頁面UI主要負責頁面的布局和簡單的作，其他的應該交由Mediator來處理。例如，Mediator協調的UI需要擷取資料，這是Mediator可以派發一個擷取資料的通知（之前已經注冊一個用于處理該通知的Command），然後有pureMVC會初始化被注冊的Command并執行擷取資料的操作。如果你需要告知另外一個頁面進行某些操作或者增加一個新的頁面，也應該通過派發通知的方式來處理，應避免在目前Mediator類中直接擷取響應頁面的對象或者擷取Mediator類進行操作，如果是增加一個新的頁面應當在頁面加載後将該頁面的對象作為報體通知Command進行注冊以及其他操作。

       3.2 Command主要負責注冊Mediator和Proxy以及協調Mediator和Proxy之間的操作，應當将複雜的操作放在這裡處理。Command的注冊不必集中但也不可以太過分散，一般來說放在比功能級稍大點的Mediator中來注冊（例如一個增删改查，4個頁面需要不停的切換，關于這4個頁面功能的Command一般來說都是放在這四個頁面的上一層頁面的Mediator中進行注冊，也就是管理這四個頁面的Mediator中）。當我們要增加啊一個新的UI時需要通知Command來注冊Mediator，需要調用model層對資料進行處理時也應通知Command來調用，如果一個Command類裡的代碼過多，應當考慮進行拆分，Command類應盡可能分的細點，便于維護。

     3.3Proxy主要負責對資料的維護以及與伺服器端進行通信處理資料。Proxy應當做到隻做純粹的資料處理不幹涉過多的邏輯處理，不關心外面發生了什麼事情，隻要在資料處理後派發通知來通知外界即可，如果各個Proxy之間需要進行互動，那也應該在Command中來是先調用不用Proxy的方法，不要在Proxy中直接去調用另一個Proxy更不能去調用Mediator。

4.注意清除你不用的Mediator，Proxy，Command應當及時的清除，pureMVC采用觀察者模式，及時的清楚能減輕系統的負擔，但是有時無法做到清楚指定的Mediator等對象，是以在每次注冊新的Mediator，Command，Proxy時要判斷是否已經存在相同的類，然後根據自己的需要選擇是重新注冊還是繼續使用以前的，切不可同時注冊兩個相同的，例如：當你有兩個相同的Mediator時，你通過NAME屬性去擷取該對象，那究竟擷取哪一個對象才是你想要的呢？