MVVM Light Toolkit - Messenger使用事件聚合器或中介者模式？

Question

请有人帮我确定I/Messenger类（及其实现）来自MVVM Light Toolkit是否展示了Event Aggregator Pattern或Mediator Pattern的使用？

如果有人提出它部分地遵循这两种模式，那么我请求详细说明哪个实现部分类似于哪个模式，以保持答案有效。

参考：其中一篇比较了这两种模式，非常有趣。

- Jsinh

Answer 1

我认为 Messenger 不是一个纯粹的 Event Aggregator 或者纯粹的 Mediator。如果我必须在它们中间选择一个，我会选择 Mediator。让我们做一些比较。

Messenger

Messenger 便于在松散耦合的对象之间发送消息。有兴趣接收消息的消费者可以注册这些消息。生产者可以使用 Messenger 广播消息：

void Register<TMessage>(object recipient, Action<TMessage> action);
void Send<TMessage>(TMessage message);

如果消费者只对通过特定渠道传递的消息感兴趣，在注册时消费者应提供一个标记。生产者应使用相同的标记通过该渠道发送消息：

void Register<TMessage>(object recipient, object token, Action<TMessage> action);
void Send<TMessage>(TMessage message, object token);

这意味着该 Messenger 中有一些逻辑，可确定将消息发送给哪些订阅者。

事件聚合器

事件聚合器（Event Aggregator）的目的是简单地监听来自许多对象的事件。 它也可以用于聚合事件。 这意味着事件聚合器订阅来自发布者的事件，但向其订户发送自己的事件。

中介者模式

中介者模式的本质是“定义一个封装一组对象如何交互的对象”。 这意味着中介者不仅接收来自发布者的消息并将其发送给订户，而且还可以对接收到的消息执行逻辑。

那么？

在我看来，Messenger 不是事件聚合器，因为它的目的不是简化处理事件。 另一方面，我认为它也不是一个 Mediator，因为它的目的不是决定对象如何交互，也不会强加通信逻辑。 如果我必须选择，我会说 Messenger 是一个中介者，因为它有一些逻辑可以通过频道发送消息。

- venerik

---

实现更受中介者模式的影响，提供专门的通道来发送消息。虽然这些通道是为了“聚合”消息通信而提供的，但在使用相同类型进行通信时，可以更具情况进行通信，并且不需要定义对象如何交互或通过 Messenger 对此交互施加逻辑。另一方面，基本实现（如果不考虑“令牌”）完全符合所提议的聚合器模式。总之，不必强制选择 :) “Messenger 是中介者和聚合器模式的混合、兼容和合并实现”。 - Jsinh