|
|
Mediator模式有一種本事，就是可以讓本身需要互相協(xié)作的對方，可以不用知道彼此，而把兩者之間的聯(lián)系，轉交給Mediator來處理。換句話說，Mediator模式解除了需要互相協(xié)調的對象之間的依賴。這也是Mediator（調停者）模式名字的由來。一個頗為形象的例子是＊＊＊。
進入＊＊＊的用戶總是要彼此通信的，這些對象如果直接進行交互，就會彼此連接，最后織成一張紛繁復雜的大網(wǎng)。要分清彼此之間的關系，真可以說是“剪不斷理還亂”了。所以，引入一個＊＊＊對象來管理用戶間的交流，就勢成必然。
Mediator模式與Facade模式都是管理復雜對象的行家里手，不過二者在運用上還是有本質的不同。Facade是門面，通過它隔斷了客戶端與復雜對象之間的直接關系。Mediator是仲裁者，哪里出現(xiàn)糾紛哪里就有它的身影。
Facade對象對于客戶端來說是可見的，而隱藏了復雜對象；Mediator對象對于客戶端來說則是隱藏的，客戶端直接調用復雜對象，而復雜對象之間的關系，則轉交給了Mediator。
MVC模式則是職責分離的典范，就好似三權分立一般，各司其職。Model負責提供數(shù)據(jù)，View則負責顯示數(shù)據(jù)，Controller則負責控制Model與View之間的交互，封裝了領域邏輯。這樣的職責分離形式，能夠有效地解除數(shù)據(jù)、業(yè)務邏輯與UI界面之間的耦合關系。但是，在MVC模式中，由于業(yè)務邏輯的問題，很有可能在Controller之間還需要進行交互。這種交互一旦增多，就可能出現(xiàn)在一個Controller中出現(xiàn)不同的Controller，導致代碼出現(xiàn)分散，形成霰彈式修改的壞味道。
Marlon在其博客上發(fā)表了一篇文章，有效地將MVC模式與Mediator模式兩者結合，創(chuàng)造出一種稱之為MVC+M的模式，有效地解決了Controller對象之間相互依賴的問題。Marlon實現(xiàn)了一個文件瀏覽器來展示這一模式。運行程序，當我們點擊左邊的目錄樹時，在右邊就會顯示當前目錄下的所有文件。UI如圖所示：
左邊視圖對應的控制對象為DirectorySelectorController，而右邊視圖對應的則為FileSelectorController對象。Marlon統(tǒng)一定義了一個接口IColleague，作為Mediator模式中參與者的抽象接口，并讓相關的Controller實現(xiàn)它。類圖如下所示：
每個Controller對象所接收的Mediator對象都是相同的，因為Mediator對象作為BaseController基類的屬性存在，并利用了Singleton模式，保證了Mediator對象只能存在一個：
public abstract class BaseController : INotifyPropertyChanged, IColleague
{
static Mediator mediatorInstance = new Mediator();
public Mediator Mediator { get; private set; }
public BaseController()
{
//set the mediator to be the same one for every controller.
Mediator = mediatorInstance;
}
//rest of implementation
it知識庫：MVC模式結合Mediator模式的運用，轉載需保留來源！
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。
