Mediator模式有一種本事，就是可以讓本身需要互相協(xié)作的對方，可以不用知道彼此，而把兩者之間的聯(lián)系，轉(zhuǎn)交給Mediator來處理。換句話說，Mediator模式解除了需要互相協(xié)調(diào)的對象之間的依賴。這也是Mediator（調(diào)停者）模式名字的由來。一個頗為形象的例子是＊＊＊。

　　進(jìn)入＊＊＊的用戶總是要彼此通信的，這些對象如果直接進(jìn)行交互，就會彼此連接，最后織成一張紛繁復(fù)雜的大網(wǎng)。要分清彼此之間的關(guān)系，真可以說是“剪不斷理還亂”了。所以，引入一個＊＊＊對象來管理用戶間的交流，就勢成必然。

　　Mediator模式與Facade模式都是管理復(fù)雜對象的行家里手，不過二者在運(yùn)用上還是有本質(zhì)的不同。Facade是門面，通過它隔斷了客戶端與復(fù)雜對象之間的直接關(guān)系。Mediator是仲裁者，哪里出現(xiàn)糾紛哪里就有它的身影。

　　Facade對象對于客戶端來說是可見的，而隱藏了復(fù)雜對象；Mediator對象對于客戶端來說則是隱藏的，客戶端直接調(diào)用復(fù)雜對象，而復(fù)雜對象之間的關(guān)系，則轉(zhuǎn)交給了Mediator。

　　MVC模式則是職責(zé)分離的典范，就好似三權(quán)分立一般，各司其職。Model負(fù)責(zé)提供數(shù)據(jù)，View則負(fù)責(zé)顯示數(shù)據(jù)，Controller則負(fù)責(zé)控制Model與View之間的交互，封裝了領(lǐng)域邏輯。這樣的職責(zé)分離形式，能夠有效地解除數(shù)據(jù)、業(yè)務(wù)邏輯與UI界面之間的耦合關(guān)系。但是，在MVC模式中，由于業(yè)務(wù)邏輯的問題，很有可能在Controller之間還需要進(jìn)行交互。這種交互一旦增多，就可能出現(xiàn)在一個Controller中出現(xiàn)不同的Controller，導(dǎo)致代碼出現(xiàn)分散，形成霰彈式修改的壞味道。

　　Marlon在其博客上發(fā)表了一篇文章，有效地將MVC模式與Mediator模式兩者結(jié)合，創(chuàng)造出一種稱之為MVC+M的模式，有效地解決了Controller對象之間相互依賴的問題。Marlon實(shí)現(xiàn)了一個文件瀏覽器來展示這一模式。運(yùn)行程序，當(dāng)我們點(diǎn)擊左邊的目錄樹時，在右邊就會顯示當(dāng)前目錄下的所有文件。UI如圖所示：

左邊視圖對應(yīng)的控制對象為DirectorySelectorController，而右邊視圖對應(yīng)的則為FileSelectorController對象。Marlon統(tǒng)一定義了一個接口IColleague，作為Mediator模式中參與者的抽象接口，并讓相關(guān)的Controller實(shí)現(xiàn)它。類圖如下所示：

每個Controller對象所接收的Mediator對象都是相同的，因?yàn)镸ediator對象作為BaseController基類的屬性存在，并利用了Singleton模式，保證了Mediator對象只能存在一個：

public abstract class BaseController : INotifyPropertyChanged, IColleague

{

    static Mediator mediatorInstance = new Mediator();

    public Mediator Mediator { get; private set; }

    {

        //set the mediator to be the same one for every controller.

        Mediator = mediatorInstance;

    }

     //rest of implementation

it知識庫：MVC模式結(jié)合Mediator模式的運(yùn)用，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。