MVC结合Mediator模式的运用
Mediator模式有一种本事，就是可以让本身需要互相协作的对方，可以不用知道彼此，而把两者之间的联系，转交给Mediator来处理。换句话说，Mediator模式解除了需要互相协调的对象之间的依赖。这也是Mediator（调停者）模式名字的由来。一个颇为形象的例子是＊＊＊。
进入＊＊＊的用户总是要彼此通信的，这些对象如果直接进行交互，就会彼此连接，最后织成一张纷繁复杂的大网。要分清彼此之间的关系，真可以说是“剪不断理还乱”了。所以，引入一个＊＊＊对象来管理用户间的交流，就势成必然。
Mediator模式与Facade模式都是管理复杂对象的行家里手，不过二者在运用上还是有本质的不同。Facade是门面，通过它隔断了客户端与复杂对象之间的直接关系。Mediator是仲裁者，哪里出现纠纷哪里就有它的身影。
Facade对象对于客户端来说是可见的，而隐藏了复杂对象；Mediator对象对于客户端来说则是隐藏的，客户端直接调用复杂对象，而复杂对象之间的关系，则转交给了Mediator。
MVC模式则是职责分离的典范，就好似三权分立一般，各司其职。Model负责提供数据，View则负责显示数据，Controller则负责控制Model与View之间的交互，封装了领域逻辑。这样的职责分离形式，能够有效地解除数据、业务逻辑与UI界面之间的耦合关系。但是，在MVC模式中，由于业务逻辑的问题，很有可能在Controller之间还需要进行交互。这种交互一旦增多，就可能出现在一个Controller中出现不同的Controller，导致代码出现分散，形成霰弹式修改的坏味道。
Marlon在其博客上发表了一篇文章，有效地将MVC模式与Mediator模式两者结合，创造出一种称之为MVC+M的模式，有效地解决了Controller对象之间相互依赖的问题。Marlon实现了一个文件浏览器来展示这一模式。运行程序，当我们点击左边的目录树时，在右边就会显示当前目录下的所有文件。UI如图所示：
左边视图对应的控制对象为DirectorySelectorController，而右边视图对应的则为FileSelectorController对象。Marlon统一定义了一个接口IColleague，作为Mediator模式中参与者的抽象接口，并让相关的Controller实现它。类图如下所示：
每个Controller对象所接收的Mediator对象都是相同的，因为Mediator对象作为BaseController基类的属性存在，并利用了Singleton模式，保证了Mediator对象只能存在一个：
publicabstractclassBaseController:INotifyPropertyChanged,IColleague
{
staticMediatormediatorInstance=newMediator();
publicMediatorMediator{get;privateset;}
publicBaseController()
{
//setthemediatortobethesameoneforeverycontroller.
Mediator=mediatorInstance;
}
//restofimplementation
}
在子类的构造函数中，通过调用Mediator对象的Register方法，建立了消息与Controller对象之间的映射关系。以FileSelectorController类为例：
publicFileSelectorController()
{
Mediator.Register(this,new[]
{
Messages.DirectorySelectedChanged
});
}
Mediator类完成Controller对象之间的协调，其定义如下：
publicclassMediator
{
MultiDictionary<string,IColleague>internalList
=newMultiDictionary<string,IColleague>();
publicvoidRegister(IColleaguecolleague,IEnumerable<string>messages)
{
foreach(stringmessageinmessages)
internalList.AddValue(message,colleague);
}
publicvoidNotifyColleagues(stringmessage,objectargs)
{
if(internalList.ContainsKey(message))
{
//forwardthemessagetoalllisteners
foreach(IColleaguecolleagueininternalList[message])
colleague.MessageNotification(message,args);
}
}
}
Register()方法会将消息与Controller对象的映射注册到内部字典internalList中。而NotifyColleagues()方法则会遍历整个internalList，然后执行Controller对象（体现为IColleague类型）的MessageNotification()方法。通过MessageNotification()方法，每个Controller对象根据传输的消息字符串，做出相应的响应操作。例如在FileSelectorController类中，就是根据Message的值，执行装载文件的业务逻辑：
publicoverridevoidMessageNotification(stringmessage,objectargs)
{
switch(message)
{
caseMessages.DirectorySelectedChanged:
//loadallfilesforthedirectoryspecified
LoadFiles((DirectoryDisplayItem)args);
break;
}
}
如果没有引入Mediator模式，由于需要在点击目录时显示当前目录的文件，因此在DirectorySelectorController类的ItemSelected事件中，必须调用FileSelectorController对象获取文件信息，然后通过对应视图显示这些文件信息。这就导致了DirectorySelectorController和FileSelectorController之间的依赖。现在，在DirectorySelectorController的ItemSelected事件中，就可以通过Mediator来实现文件信息的读取与显示：
//eventhandlerfortheselectingchanged
voidItemSelected(objectsender,RoutedEventArgse)
{
TreeViewtreeView=(TreeView)e.OriginalSource;
//Sendamessagethatanitemisselectedandpasstheobjectselected
Mediator.NotifyColleagues(Messages.DirectorySelectedChanged,treeView.SelectedItem);
}
Marlon实现的MVC+M模式有效地解除了Controller对象之间的耦合关系，其中，他引入了IColleague接口对Controller的相关方法进行了抽象。不过，这样的接口并非必须，正如我在《Strategy模式与Delegate委托》一文中提到的接口与委托之间的关系，我们完全可以用委托来代替IColleague接口的定义，使整个结构变得更加的灵活。由于引入了委托与消息对象的映射关系，因此在Controller类的MessageNotification()方法中，不再需要用switch语句来判断消息的值，而是直接根据映射关系，调用委托对象所指代的方法逻辑。Mediator类可以修改为：
publicclassMediator
{
IDictionary<string,Action<object>>m_List=newDictionary<string,Action<object>>();
publicvoidRegister(stringmessage,Action<object>callback)
{
m_List.Add(message,callback);
}
publicvoidNotifyColleagues(stringmessage,objectargs)
{
if(m_List.ContainsKey(message))
{
m_List[message](args);
}
}
}
与之对应的，FileSelectorController可以修改为：
publicFileSelectorController()
{
Mediator.Register(Messages.DirectorySelectedChanged,
(obj)=>
{
LoadFiles((DirectoryDisplayItem)obj);
});
}
至于最初定义在Controller类的MessageNotification()方法，则被匿名函数所代替，已经不再需要了