大連協(xié)同辦公軟件開發(fā)測試經(jīng)常出現(xiàn)的問題比較難易發(fā)現(xiàn)。無論是可靠性還是可維護(hù)性，因?yàn)榻缑嬖氐淖兓茴l繁，而通過編程來控制界面和用戶真實(shí)操作經(jīng)常有細(xì)微的差別，尤其是時(shí)序相關(guān)的問題。
致遠(yuǎn)服軟認(rèn)為：http://www.soft8.com.cn/一個(gè)思路就是把顯示邏輯從View中分離，讓View退化為簡單的GUI控件的容器。MVP做出了最初的努力，而另外兩個(gè)模式更加強(qiáng)調(diào)了這一點(diǎn)：Presentation Model 和Passive View。
Passive View針對可測試性的方案是把所有的顯示邏輯都從View 中移除，View 不再依賴任何Model，只是提供接口，完全被動(dòng)地由Controller或者Presenter來設(shè)置顯示所需數(shù)據(jù)并刷新。
Presentation Model則封裝了Domain Model擁有的數(shù)據(jù)到View顯示所需車輛精準(zhǔn)定位軟件開發(fā)數(shù)據(jù)之間的映射。View 不再需要與 Domain Model 打交道自己來把業(yè)務(wù)數(shù)據(jù)轉(zhuǎn)換成顯示需要的數(shù)據(jù)，只需從Presentation Model 中取數(shù)據(jù)，映射邏輯都在 Presentation Model 中。而 View 所需數(shù)據(jù)和Presentation Model 是簡單的一一對應(yīng)關(guān)系。
我們上面討論的都是大連協(xié)同辦公軟件開發(fā)測試經(jīng)常出現(xiàn)的問題相對簡單的 GUI，比如我們其實(shí)假定了 View 和 Model 的一一對應(yīng)，甚至也假定了應(yīng)用只有一個(gè)Vi e w。然而我們還有多視圖的情況。多視圖帶來了以下問題。
? 當(dāng)Model 變化時(shí)如何保持多個(gè)視圖間的一致性。
? 多個(gè)視圖間的交互的可控性。
? 事件的循環(huán)觸發(fā)問題。
Martin Fowler blog 中描述的Flow Synchronization 和 Observer Synchronization 當(dāng)Model變化時(shí)為刷新多個(gè)視圖提供了兩種方式，分別應(yīng)對不同的情況。
Flow Synchronization 在 Model 變化后的某些明確定義的時(shí)機(jī)明確地更新所有受影響的View。它的優(yōu)點(diǎn)是顯式、直觀、可控，缺點(diǎn)是很容易造成多個(gè)View之間彼此有依賴，不易擴(kuò)展，因此它適用于視圖較少的情況。
Observer Synchronization則是讓多個(gè)View 都訂閱Model 的更新事件。這是Observer模式在同步方面的應(yīng)用，具有Observer松耦合的特點(diǎn)。缺點(diǎn)也不意外，它讓用戶交互的影響變得隱式了，不易于理解應(yīng)用整體行為和開發(fā)時(shí)調(diào)試等。
傳統(tǒng)上還有一種用于解決大連協(xié)同辦公軟件開發(fā)測試經(jīng)常出現(xiàn)的問題的可控性并讓View之間彼此解耦的模式，就是Mediator。當(dāng)我們在應(yīng)用Flow Synchronization 時(shí)，如果把View 之間的交互都抽取到一個(gè)中介者對象里面，每個(gè)View都不知道其他View，只知道中介者對象，當(dāng)有事件發(fā)生時(shí)，由中介者對象來更新Model和其他View，那么我們可以獲得相對清晰的交互和相對松散的耦合。我們來看一下《設(shè)計(jì)模式》里面對Mediator的描述。
用一個(gè)中介對象來封裝一系列對象交互。中介者使各對象不需要顯式地相互引用，從而使其耦合松散，而且可以獨(dú)立改變他們之間的交互。
