说不尽的MVVM(5) - 消息满天飞

知识预备

阅读本文，我假定你具备以下知识:

• C#和WPF基础知识
• Lambda表达式

清楚ViewModel的职责

如果我们的程序需要弹出一个MessageBox，我们应该怎么做？

我见过不少人在ViewModel里面写着：MessageBox.Show("xxx");

程序的功能看似没有什么问题，日后我要把这个ViewModel用到WinRT上，你是不是傻眼了？WinRT是没有MessageBox的。

为什么会出现这样的情况呢？请仔细想想，弹出MessageBox是ViewModel的职责吗？

很明显，MessageBox是与交互相关的东西，对MessageBox的操作应该在UI上执行，我们又知道，ViewModel是不知道View的存在的，那当业务逻辑产生了交互请求时，应该怎样通知UI呢？这里就引出我们今天要讲的Messenger。

通过消息实现松散耦合

这个名词有点抽象，举个简单的例子，老师上课时算一道题，要做一个计算，对同学们说："哪个同学有计算器的帮我算一下这个。"，然后很快有同学算好并且在下面喊："老师，算好了，这个等于xxx！！！"。

在这里不难看出，老师并不依赖于任何一个学生，他只是简单的发出一个消息，然后同学收到老师的请求，执行操作，并将结果一消息的形式返回给老师。老师只是找了个人帮忙计算，并不需要知道是谁在帮忙计算。

这样的好处应该在如今的云计算时代体现的比较明显，举个例子，我们可以把Web前段和BLL分开，中间通过Windows Azure的Service Bus，以消息的形式进行通信，这样，我们可以根据负载情况，把Web层和BLL分别缩放，而不需要考虑他们的依赖关系。

实现一个简单的Messenger

实现Messenger的思想是：通过一个中心的Dictionary存储消息的标记和处理者的关系，在消息发出时，调用对应的处理者。

这是一个非常简陋的Messenger，我们假定一切正常，没有进行错误处理，对于理解Messenger的思想来说，已经足够了，但在实际应用中，一定要注意。

使用MVVM Light的Messenger

相信通过上一个例子，大家已经对Messenger的机制有了一定的理解，我们现在就来用Messenger实现ViewMoel和View的交互请求。

程序非常简单，点击按钮，弹出消息框。

我们现在Windows里面注册这个消息

然后在ViewModel里面发送消息，这里的"MSG"就是消息的标记，他由消息的发送者和接受者约定，这样，对于这个交互请求，不同的表现层技术可以采用不同的相应方式，例如WPF可以用MessageBox，WinRT可以用MessageDialog。

在这里我们使用Messenger默认提供的实例，当然我们也可以另外创建实例。

你可能会有的疑问

所有的消息集中在一个Messenger，会不会混乱？

从消息的容器里面看，的确凌乱不堪，这也是我把文章题目叫做消息满天飞的原因，但我们最终的目的达到了。想想依赖注入的容器吧，一样的。

Windows Azure Service Bus 是什么东西？

这是Windows Azure提供的一系列系统整合服务，包括队列服务，主题/订阅服务，中继服务，通知中心等，详见：https://www.windowsazure.com/en-us/documentation/services/service-bus/