事件提供的是1对多的绑定，通过委托链实现对订阅者的调用，事件必须要通过发布者调用。同时事件订阅是强引用，事件订阅者的生命周期总是大于等于事件发布者。如果代码中事件很多就会充斥着各种事件的订阅，不利于维护。
Prism提供了EventAggregator器，可以在任何地方进行订阅，任何地方进行调用/发布，实例只对EventAggregator和事件类型有依赖，使用了弱引用，可以过滤消息，并可以控制回调函数线程。感觉很强大，实现应该挺复杂，但看到实现时有一种恍然大悟的感觉，喜欢这种简单而强大的实现。开始一探究竟吧！
先从整体框架解析一下吧。EventAggregator
发现这只是一个集合类，保存着事件类型和事件实例，还有一个线程上下文保证线程同步。
看一下EventBase，看来所有的订阅委托都是在着保存着，因为有一个IEventSubscription列表。EventSubscription因该是订阅委托的包装器。
看到有SubscriptionToken和DelegateReference，
这边终于看到Delegate的真正存放地点了。这边存放了弱引用，委托类型和MethodInfo。
看到这边理解了，通过一个集合保存事件，这个事件内部存储着所有订阅委托。
当我们向订阅发布的时候，只要从这个集合中获取对应的事件进行订阅发布。相通了是不是觉得自己也能写一个简单的事件聚合器呢？
来具体看看代码吧。
看到EventAggregator通过依赖注入，获取MessageSentEvent进行订阅。
保存了UI线程上下文和将事件类型和事件类型实例放到集合中，加锁，线程安全。
事件可以啥都没有但必须继承PubSubEvent，功能都在这里实现了。
threadOption默认是PublisherTHread，这里是说回调函数在什么线程执行，BackgroundThread就是Task创建的线程池线程，Dispatcher就是UI线程
内部订阅进行了校验（主要是委托不为空）和Token
看完订阅再来看看调用
在任何地方调用，还是去EventAggregator获取事件实例，然后调用其Publish
从这边可以看出就是依次调用列表中的委托，DispatcherEventSubscription 调用
BackgroundEventSubscription 调用
到现在还没有讲到Filter，来看看怎么实现过滤消息
在订阅的时候值接受含有Brian的消息
使用了泛型的订阅
使用了prcidate<>保存了filter委托，
在Publish主要就是在GetExecutionStrategy方法中
filter返回true触发订阅委托。
事件聚合提供了一个很好的思路，我们甚至可以利用事件聚合的思想实现事件聚合微服务组件。
原文：https://www.cnblogs.com/lonelyxmas/p/12783727.html