事件总线知多少（1）
源码路径：Github-EventBus事件总线知多少（1）事件总线知多少（2）
1. 引言
事件总线这个概念对你来说可能很陌生，但提到观察者（发布-订阅）模式，你也许就很熟悉。事件总线是对发布-订阅模式的一种实现。它是一种集中式事件处理机制，允许不同的组件之间进行彼此通信而又不需要相互依赖，达到一种解耦的目的。
我们来看看事件总线的处理流程：
了解了事件总线的基本概念和处理流程，下面我们就来分析下如何去实现事件总线。
2.回归本质
在动手实现事件总线之前，我们还是要追本溯源，探索一下事件的本质和发布订阅模式的实现机制。
2.1.事件的本质
我们先来探讨一下事件的概念。都是读过书的，应该都还记得记叙文的六要素：时间、地点、人物、事件（起因、经过、结果）。
我们拿注册的案例，来解释一下。
用户输入用户名、邮箱、密码后，点击注册，输入无误校验通过后，注册成功并发送邮件给用户，要求用户进行邮箱验证激活。
这里面就涉及了两个主要事件：
- 注册事件：起因是用户点击了注册按钮，经过是输入校验，结果是是否注册成功。
- 发送邮件事件：起因是用户使用邮箱注册成功需要验证邮箱，经过是邮件发送，结果是邮件是否发送成功。
其实这六要素也适用于我们程序中事件的处理过程。开发过WinForm程序的都知道，我们在做UI设计的时候，从工具箱拖入一个注册按钮（btnRegister），双击它，VS就会自动帮我们生成如下代码：
void btnRegister_Click(object sender, EventArgs e)
{
// 事件的处理
}其中object sender指代发出事件的对象，这里也就是button对象；EventArgs e 事件参数，可以理解为对事件的描述 ，它们可以统称为事件源。其中的代码逻辑，就是对事件的处理。我们可以统称为事件处理。
说了这么多，无非是想透过现象看本质：事件是由事件源和事件处理组成。
2.2. 发布订阅模式
定义对象间一种一对多的依赖关系，使得每当一个对象改变状态，则所有依赖于它的对象都会得到通知并被自动更新。 ——发布订阅模式
发布订阅模式主要有两个角色：
- 发布方（Publisher）：也称为被观察者，当状态改变时负责通知所有订阅者。
- 订阅方（Subscriber）：也称为观察者，订阅事件并对接收到的事件进行处理。
发布订阅模式有两种实现方式：
- 简单的实现方式：由Publisher维护一个订阅者列表，当状态改变时循环遍历列表通知订阅者。
- 委托的实现方式：由Publisher定义事件委托，Subscriber实现委托。
总的来说，发布订阅模式中有两个关键字，通知和更新。
被观察者状态改变通知观察者做出相应更新。
解决的是当对象改变时需要通知其他对象做出相应改变的问题。
如果画一个图来表示这个流程的画，图形应该是这样的：
3 实现发布订阅模式
相信通过上面的解释，对事件和发布订阅模式有了一个大概的印象。都说理论要与实践相结合，所以我们还是动动手指敲敲代码比较好。
我将以『观察者模式』来钓鱼这个例子为基础，通过重构的方式来完善一个更加通用的发布订阅模式。
先上代码：
/// <summary>
/// 鱼的品类枚举
/// </summary>
public enum FishType
{
鲫鱼,
鲤鱼,
黑鱼,
青鱼,
草鱼,
鲈鱼
}钓鱼竿的实现：
/// <summary>
/// 鱼竿（被观察者）
/// </summary>
public class FishingRod
{
public delegate void FishingHandler(FishType type); //声明委托
public event FishingHandler FishingEvent; //声明事件
public void ThrowHook(FishingMan man)
{
Console.WriteLine("开始下钩！");
//用随机数模拟鱼咬钩，若随机数为偶数，则为鱼咬钩
if (new Random().Next() % 2 == 0)
{
var type = (FishType) new Random().Next(0, 5);
Console.WriteLine("铃铛：叮叮叮，鱼儿咬钩了");
if (FishingEvent != null)
FishingEvent(type);
}
}
}垂钓者：
/// <summary>
/// 垂钓者（观察者）
/// </summary>
public class FishingMan
{
public FishingMan(string name)
{
Name = name;
}
public string Name { get; set; }
public int FishCount { get; set; }
/// <summary>
/// 垂钓者自然要有鱼竿啊
/// </summary>
public FishingRod FishingRod { get; set; }
public void Fishing()
{
this.FishingRod.ThrowHook(this);
}
public void Update(FishType type)
{
FishCount++;
Console.WriteLine("{0}：钓到一条[{2}]，已经钓到{1}条鱼了！", Name, FishCount, type);
}
}场景类也很简单：
//1、初始化鱼竿
var fishingRod = new FishingRod();
//2、声明垂钓者
var jeff = new FishingMan("圣杰");
//3.分配鱼竿
jeff.FishingRod = fishingRod;
//4、注册观察者
fishingRod.FishingEvent += jeff.Update;
//5、循环钓鱼
while (jeff.FishCount < 5)
{
jeff.Fishing();
Console.WriteLine("-------------------");
//睡眠5s
Thread.Sleep(5000);
}代码很简单，相信你一看就明白。但很显然这个代码实现仅适用于当前这个钓鱼场景，假如有其他场景也想使用这个模式，我们还需要重新定义委托，重新定义事件处理，岂不很累。本着”Don't repeat yourself“的原则，我们要对其进行重构。
结合我们对事件本质的探讨，事件是由事件源和事件处理组成。针对我们上面的案例来说， public delegate void FishingHandler(FishType type);这句代码就已经说明了事件源和事件处理。事件源就是FishType type，事件处理自然是注册到FishingHandler上面的委托实例。
问题找到了，很显然是我们的事件源和事件处理不够抽象，所以不能通用，下面咱们就来动手改造。
3.1. 提取事件源
事件源应该至少包含事件发生的时间和触发事件的对象。
我们提取IEventData接口来封装事件源：
/// <summary>
/// 定义事件源接口，所有的事件源都要实现该接口
/// </summary>
public interface IEventData
{
/// <summary>
/// 事件发生的时间
/// </summary>
DateTime EventTime { get; set; }
/// <summary>
/// 触发事件的对象
/// </summary>
object EventSource { get; set; }
}自然我们应该给一个默认的实现EventData：
/// <summary>
/// 事件源：描述事件信息，用于参数传递
/// </summary>
public class EventData : IEventData
{
/// <summary>
/// 事件发生的时间
/// </summary>
public DateTime EventTime { get; set; }
/// <summary>
/// 触发事件的对象
/// </summary>
public Object EventSource { get; set; }
public EventData()
{
EventTime = DateTime.Now;
}
}针对Demo，扩展事件源如下：
public class FishingEventData : EventData
{
public FishType FishType { get; set; }
public FishingMan FisingMan { get; set; }
}完成后，我们就可以去把在FishingRod声明的委托参数类型改为FishingEventData类型了，即public delegate void FishingHandler(FishingEventData eventData); //声明委托；
然后修改FishingMan的Update方法按委托定义的参数类型修改即可，代码我就不放了，大家自行脑补。
到这一步我们就统一了事件源的定义方式。
3.2.提取事件处理器
事件源统一了，那事件处理也得加以限制。比如如果随意命名事件处理方法名，那在进行事件注册的时候还要去按照委托定义的参数类型去匹配，岂不麻烦。
我们提取一个IEventHandler接口：
/// <summary>
/// 定义事件处理器公共接口，所有的事件处理都要实现该接口
/// </summary>
public interface IEventHandler
{
}事件处理要与事件源进行绑定，所以我们再来定义一个泛型接口：
/// <summary>
/// 泛型事件处理器接口
/// </summary>
/// <typeparam name="TEventData"></typeparam>
public interface IEventHandler<TEventData> : IEventHandler where TEventData : IEventData
{
/// <summary>
/// 事件处理器实现该方法来处理事件
/// </summary>
/// <param name="eventData"></param>
void HandleEvent(TEventData eventData);
}你可能会纳闷，为什么先定义了一个空接口？这里就留给自己思考吧。
至此我们就完成了事件处理的抽象。我们再继续去改造我们的Demo。我们让FishingMan实现IEventHandler接口，然后修改场景类中将fishingRod.FishingEvent += jeff.Update;改为fishingRod.FishingEvent += jeff.HandleEvent;即可。代码改动很简单，同样在此略去。
至此你可能觉得我们完成了对Demo的改造。但事实上呢，我们还要弄清一个问题——如果这个FishingMan订阅的有其他的事件，我们该如何处理？
聪颖如你，你立马想到了可以通过事件源来进行区分处理。
public class FishingMan : IEventHandler<IEventData>
{
//省略其他代码
public void HandleEvent(IEventData eventData)
{
if (eventData is FishingEventData)
{
//do something
}
if(eventData is XxxEventData)
{
//do something else
}
}
}至此，这个模式实现到这个地步基本已经可以通用了。
4. 实现事件总线
通用的发布订阅模式不是我们的目的，我们的目的是一个集中式的事件处理机制，且各个模块之间相互不产生依赖。那我们如何做到呢？同样我们还是一步一步的进行分析改造。
4.1.分析问题
思考一下，每次为了实现这个模式，都要完成以下三步：
- 事件发布方定义事件委托
- 事件订阅方定义事件处理逻辑
- 显示的订阅事件
虽然只有三步，但这三步已经很繁琐了。而且事件发布方和事件订阅方还存在着依赖（体现在订阅者要显示的进行事件的注册和注销上）。而且当事件过多时，直接在订阅者中实现IEventHandler接口处理多个事件逻辑显然不太合适，违法单一职责原则。这里就暴露了三个问题：
- 如何精简步骤？
- 如何解除发布方与订阅方的依赖？
- 如何避免在订阅者中同时处理多个事件逻辑？
带着问题思考，我们就会更接近真相。
想要精简步骤，那我们需要寻找共性。共性就是事件的本质，也就是我们针对事件源和事件处理提取出来的两个接口。
想要解除依赖，那就要在发布方和订阅方之间添加一个中介。
想要避免订阅者同时处理过多事件逻辑，那我们就把事件逻辑的处理提取到订阅者外部。
思路有了，下面我们就来实施吧。
4.2.解决问题
本着先易后难的思想，我们下面就来解决以上问题。
4.2.1. 实现IEventHandler
我们先解决上面的第三个问题：如何避免在订阅者中同时处理多个事件逻辑？
自然是针对不同的事件源IEventData实现不同的IEventHandler。改造后的钓鱼事件处理逻辑如下：
/// <summary>
/// 钓鱼事件处理
/// </summary>
public class FishingEventHandler : IEventHandler<FishingEventData>
{
public void HandleEvent(FishingEventData eventData)
{
eventData.FishingMan.FishCount++;
Console.WriteLine("{0}：钓到一条[{2}]，已经钓到{1}条鱼了！",
eventData.FishingMan.Name, eventData.FishingMan.FishCount, eventData.FishType);
}
}这时我们就可以移除在FishingMan中实现的IEventHandler接口了。
然后将事件注册改为fishingRod.FishingEvent += new FishingEventHandler().HandleEvent;即可。
4.2.2. 统一注册事件
上一个问题的解决，有助于我们解决第一个问题：如何精简流程？
为什么呢，因为我们是根据事件源定义相应的事件处理的。也就是我们之前说的可以根据事件源来区分事件。
然后呢？反射，我们可以通过反射来进行事件的统一注册。
在FishingRod的构造函数中使用反射，统一注册实现了IEventHandler<FishingEventData>类型的实例方法HandleEvent：
public FishingRod()
{
Assembly assembly = Assembly.GetExecutingAssembly();
foreach (var type in assembly.GetTypes())
{
if (typeof(IEventHandler).IsAssignableFrom(type))//判断当前类型是否实现了IEventHandler接口
{
Type handlerInterface = type.GetInterface("IEventHandler`1");//获取该类实现的泛型接口
Type eventDataType = handlerInterface.GetGenericArguments()[0]; // 获取泛型接口指定的参数类型
//如果参数类型是FishingEventData，则说明事件源匹配
if (eventDataType.Equals(typeof(FishingEventData)))
{
//创建实例
var handler = Activator.CreateInstance(type) as IEventHandler<FishingEventData>;
//注册事件
FishingEvent += handler.HandleEvent;
}
}
}
}这样，我们就可以移出场景类中的显示注册代码fishingRod.FishingEvent += new FishingEventHandler().HandleEvent;。
4.2.3. 解除依赖
如何解除依赖呢？其实答案就在本文的两张图上，仔细对比我们可以很直观的看到，Event Bus就相当于一个介于Publisher和Subscriber中间的桥梁。它隔离了Publlisher和Subscriber之间的直接依赖，接管了所有事件的发布和订阅逻辑，并负责事件的中转。
Event Bus终于要粉墨登场了！！！
分析一下，如果EventBus要接管所有事件的发布和订阅，那它则需要有一个容器来记录事件源和事件处理。那又如何触发呢？有了事件源，我们就自然能找到绑定的事件处理逻辑，通过反射触发。代码如下：
/// <summary>
/// 事件总线
/// </summary>
public class EventBus
{
public static EventBus Default => new EventBus();
/// <summary>
/// 定义线程安全集合
/// </summary>
private readonly ConcurrentDictionary<Type, List<Type>> _eventAndHandlerMapping;
public EventBus()
{
_eventAndHandlerMapping = new ConcurrentDictionary<Type, List<Type>>();
MapEventToHandler();
}
/// <summary>
///通过反射，将事件源与事件处理绑定
/// </summary>
private void MapEventToHandler()
{
Assembly assembly = Assembly.GetEntryAssembly();
foreach (var type in assembly.GetTypes())
{
if (typeof(IEventHandler).IsAssignableFrom(type))//判断当前类型是否实现了IEventHandler接口
{
Type handlerInterface = type.GetInterface("IEventHandler`1");//获取该类实现的泛型接口
if (handlerInterface != null)
{
Type eventDataType = handlerInterface.GetGenericArguments()[0]; // 获取泛型接口指定的参数类型
if (_eventAndHandlerMapping.ContainsKey(eventDataType))
{
List<Type> handlerTypes = _eventAndHandlerMapping[eventDataType];
handlerTypes.Add(type);
_eventAndHandlerMapping[eventDataType] = handlerTypes;
}
else
{
var handlerTypes = new List<Type> { type };
_eventAndHandlerMapping[eventDataType] = handlerTypes;
}
}
}
}
}
/// <summary>
/// 手动绑定事件源与事件处理
/// </summary>
/// <typeparam name="TEventData"></typeparam>
/// <param name="eventHandler"></param>
public void Register<TEventData>(Type eventHandler)
{
List<Type> handlerTypes = _eventAndHandlerMapping[typeof(TEventData)];
if (!handlerTypes.Contains(eventHandler))
{
handlerTypes.Add(eventHandler);
_eventAndHandlerMapping[typeof(TEventData)] = handlerTypes;
}
}
/// <summary>
/// 手动解除事件源与事件处理的绑定
/// </summary>
/// <typeparam name="TEventData"></typeparam>
/// <param name="eventHandler"></param>
public void UnRegister<TEventData>(Type eventHandler)
{
List<Type> handlerTypes = _eventAndHandlerMapping[typeof(TEventData)];
if (handlerTypes.Contains(eventHandler))
{
handlerTypes.Remove(eventHandler);
_eventAndHandlerMapping[typeof(TEventData)] = handlerTypes;
}
}
/// <summary>
/// 根据事件源触发绑定的事件处理
/// </summary>
/// <typeparam name="TEventData"></typeparam>
/// <param name="eventData"></param>
public void Trigger<TEventData>(TEventData eventData) where TEventData : IEventData
{
List<Type> handlers = _eventAndHandlerMapping[eventData.GetType()];
if (handlers != null && handlers.Count > 0)
{
foreach (var handler in handlers)
{
MethodInfo methodInfo = handler.GetMethod("HandleEvent");
if (methodInfo != null)
{
object obj = Activator.CreateInstance(handler);
methodInfo.Invoke(obj, new object[] { eventData });
}
}
}
}
}事件总线主要定义三个方法，注册、取消注册、事件触发。还有一点就是我们在构造函数中通过反射去进行事件源和事件处理的绑定。
代码注释已经很清楚了，这里就不过多解释了。
下面我们就来修改Demo，修改FishingRod的事件触发：
/// <summary>
/// 下钩
/// </summary>
public void ThrowHook(FishingMan man)
{
Console.WriteLine("开始下钩！");
//用随机数模拟鱼咬钩，若随机数为偶数，则为鱼咬钩
if (new Random().Next() % 2 == 0)
{
var a = new Random(10).Next();
var type = (FishType)new Random().Next(0, 5);
Console.WriteLine("铃铛：叮叮叮，鱼儿咬钩了");
if (FishingEvent != null)
{
var eventData = new FishingEventData() { FishType = type, FishingMan = man };
//FishingEvent(eventData);//不再需要通过事件委托触发
EventBus.Default.Trigger<FishingEventData>(eventData);//直接通过事件总线触发即可
}
}
}至此，事件总线的雏形已经形成！
5.事件总线的总结
通过上面一步一步的分析和实践，发现事件总线也不是什么高深的概念，只要我们自己善于思考，勤于动手，也能实现自己的事件总线。
根据我们的实现，大概总结出以下几条：
- 事件总线维护一个事件源与事件处理的映射字典；
- 通过单例模式，确保事件总线的唯一入口；
- 利用反射完成事件源与事件处理的初始化绑定；
- 提供统一的事件注册、取消注册和触发接口。
最后，以上事件总线的实现只是一个雏形，还有很多潜在的问题。有兴趣的不妨思考完善一下，我也会继续更新完善，尽情期待！
参考资料
出处：
=======================================================================================
事件总线知多少（2）
1.引言
之前的一篇文章事件总线知多少（1），介绍了什么是事件总线，并通过发布订阅模式一步一步的分析重构，形成了事件总线的Alpha版本，这篇文章也得到了大家的肯定和积极的反馈和建议，在此谢谢大家。本着继续学习和回馈大家的思想，我决定继续完善。本文将继续延续上一篇循序渐进的写作风格，来完成对事件总线的分析和优化。
2.回顾事件总线
在进行具体分析之前，我们还是先对我们实现的事件总线进行一个简单的回顾：
- 针对事件源，抽象
IEventData接口； - 针对事件处理，抽象
IEventHandler<TEventData>接口，定义唯一事件处理方法void HandleEvent(IEventData eventData)； - 事件总线维护一个事件源和事件处理的类型映射字典
ConcurrentDictionary<Type, List<Type>> _eventAndHandlerMapping； - 通过单例模式，确保事件总线的唯一入口；
- 利用反射完成事件源与事件处理的动态初始化绑定；
- 提供入口支持事件的手动注册/取消注册；
- 提供统一的事件触发接口，通过反射动态创建
IEventHandler实例完成具体事件处理逻辑的调用。
3.发现反射问题
基于以上的简单回顾，我们可以发现Alpha版本事件总线的成功离不开反射的支持。从动态绑定到动态触发，都是反射在默默的处理着业务逻辑。如果我们只是简单学习了解事件总线，使用反射无可厚非。但如果在实际的项目中，使用反射却不是一个很明智的行为，因为其性能问题。尤其是事件总线要集中处理整个应用程序的所有事件，更易导致程序性能瓶颈。
既然说到了反射性能，那就顺便解释下为什么反射性能差？
- 类型绑定（元数据字符串匹配）
- 参数校验
- 安全校验
- 基于运行时
- 反射产生大量临时对象，增加GC负担
那既然反射有性能瓶颈，我们该如何是好呢？
你可能会说，既然反射有问题，那就对反射进行性能优化，比如增加缓存机制。出发点是好的，但最终还是在反射问题的阴影之下。对于反射我们应该持以这样一种态度：能不用反射，则不用反射。
那既然要推翻反射这条路，那如何解决动态绑定和动态触发的问题呢？
办法总比问题多。额，啊，嗯。就不饶圈子了，咱们上IOC。
4.使用IOC解除依赖
先看下面一张图，来了解下DIP、IOC、DI与SL之间的关系，详细可参考Asp.net mvc 知多少（十）。
下面我们就以Castle Windsor作为我们的IOC容器为例，来讲解下如何解除依赖。
4.1. 了解Castle Windsor
使用Castle Windsor主要包含以下几步：
- 初始化容器：
var container = new WindsorContainer(); - 使用WindsorInstallers从执行程序集添加和配置所有组件：
container.Install(FromAssembly.This()); - 实现
IWindsorInstaller自定义安装器：
public class RepositoriesInstaller : IWindsorInstaller
{
public void Install(IWindsorContainer container, IConfigurationStore store)
{
container.Register(Classes.FromThisAssembly()
.Where(Component.IsInSameNamespaceAs<King>())
.WithService.DefaultInterfaces()
.LifestyleTransient());
}
}- 注册和解析依赖
- 程序退出时，释放容器
4.2. 使用Castle Windsor
使用IOC容器的目的很明确，一个是在注册事件时完成依赖的注入，一个是在触发事件时完成依赖的解析。从而完成事件的动态绑定和触发。
4.2.1. 初始化容器
要在EventBus这个类中完成事件依赖的注入和解析，就需要在本类中持有一个对IWindsorContainer的引用。
可以直接定义一个只读属性，并在构造函数中进行初始化即可。
public IWindsorContainer IocContainer { get; private set; }//定义IOC容器
private readonly ConcurrentDictionary<Type, List<Type>> _eventAndHandlerMapping;
public EventBus()
{
IocContainer = new WindsorContainer();
_eventAndHandlerMapping = new ConcurrentDictionary<Type, List<Type>>();
}4.2.2.注册和取消注册依赖
初始化完容器，我们需要在手动注册和取消注册事件API上分别完成依赖的注册和取消注册。因为Castle Windsor在3.0版本取消了UnRegister方法，所以在进行事件注册时，就不再手动卸载IOC容器中已注册的依赖。
/// <summary>
/// 手动绑定事件源与事件处理
/// </summary>
/// <param name="eventType"></param>
/// <param name="handlerType"></param>
public void Register(Type eventType, Type handlerType)
{
//注册IEventHandler<T>到IOC容器
var handlerInterface = handlerType.GetInterface("IEventHandler`1");
if (!IocContainer.Kernel.HasComponent(handlerInterface))
{
IocContainer.Register(Component.For(handlerInterface, handlerType));
}
//注册到事件总线
//省略其他代码
}
/// <summary>
/// 手动解除事件源与事件处理的绑定
/// </summary>
/// <typeparam name="TEventData"></typeparam>
/// <param name="handlerType"></param>
public void UnRegister<TEventData>(Type handlerType)
{
_eventAndHandlerMapping.GetOrAdd(typeof(TEventData), (type) => new List<Type>())
.RemoveAll(t => t == handlerType);
}4.2.3. 动态事件绑定
要实现事件的动态绑定，我们要拿到所有IEventHandler<T>的实现。而遍历所有类型最好的办法就是拿到程序集（Assembly）。拿到程序集后就可以将所有IEventHandler<T>的实现注册到IOC容器，然后再基于IOC容器注册的IEventHandler<T>动态映射事件源和事件处理。
/// <summary>
/// 提供入口支持注册其它程序集中实现的IEventHandler
/// </summary>
/// <param name="assembly"></param>
public void RegisterAllEventHandlerFromAssembly(Assembly assembly)
{
//1.将IEventHandler注册到Ioc容器
IocContainer.Register(Classes.FromAssembly(assembly)
.BasedOn(typeof(IEventHandler<>))
.WithService.AllInterfaces()
.LifestyleSingleton());
//2.从IOC容器中获取注册的所有IEventHandler
var handlers = IocContainer.Kernel.GetHandlers(typeof(IEventHandler));
foreach (var handler in handlers)
{
//循环遍历所有的IEventHandler<T>
var interfaces = handler.ComponentModel.Implementation.GetInterfaces();
foreach (var @interface in interfaces)
{
if (!typeof(IEventHandler).IsAssignableFrom(@interface))
{
continue;
}
//获取泛型参数类型
var genericArgs = @interface.GetGenericArguments();
if (genericArgs.Length == 1)
{
//注册到事件源与事件处理的映射字典中
Register(genericArgs[0], handler.ComponentModel.Implementation);
}
}
}
}通过这种方式，我们就可以再其他需要使用事件总线的项目中，添加引用后，通过调用以下代码，来完成程序集中IEventHandler<T>的动态绑定。
//注册当前程序集中实现的所有IEventHandler<T>
EventBus.Default.RegisterAllEventHandlerFromAssembly(Assembly.GetExecutingAssembly());4.2.4. 动态事件触发
触发事件时主要分三步，第一步从事件源与事件处理的字典中取出映射的IEventHandler集合，第二步使用IOC容器解析依赖，第三步调用HandleEvent方法。代码如下：
/// <summary>
/// 根据事件源触发绑定的事件处理
/// </summary>
/// <typeparam name="TEventData"></typeparam>
/// <param name="eventData"></param>
public void Trigger<TEventData>(TEventData eventData) where TEventData : IEventData
{
//获取所有映射的EventHandler
List<Type> handlerTypes = _eventAndHandlerMapping[typeof(TEventData)];
if (handlerTypes != null && handlerTypes.Count > 0)
{
foreach (var handlerType in handlerTypes)
{
//从Ioc容器中获取所有的实例
var handlerInterface = handlerType.GetInterface("IEventHandler`1");
var eventHandlers = IocContainer.ResolveAll(handlerInterface);
//循环遍历，仅当解析的实例类型与映射字典中事件处理类型一致时，才触发事件
foreach (var eventHandler in eventHandlers)
{
if (eventHandler.GetType() == handlerType)
{
var handler = eventHandler as IEventHandler<TEventData>;
handler.HandleEvent(eventData);
}
}
}
}
}5.用例完善
我们上面使用IOC容器替换了反射，在程序的易用性和性能上都有所提升。但很显然，用例不够完善且存在一些潜在问题，比如：
- 支持Action EventHandler的绑定和触发
- 异步触发
- 触发指定的EventHandler
- 线程安全
- 等等等
下面我们就来先一一完善以上几个问题。
5.1.支持Action事件处理器
如果每一个事件处理都要定义一个类去实现IEventHandler<T>接口，很显然会造成类急剧膨胀。且在一些简单场景，定义一个类又大才小用。这时我们应该立刻想到Action。
使用Action，第一步我们要对其进行封装，提供一个公共的ActionEventHandler来统一处理所有的Action事件处理器。代码如下：
/// <summary>
/// 支持Action的事件处理器
/// </summary>
/// <typeparam name="TEventData"></typeparam>
internal class ActionEventHandler<TEventData> : IEventHandler<TEventData> where TEventData : IEventData
{
/// <summary>
/// 定义Action的引用，并通过构造函数传参初始化
/// </summary>
public Action<TEventData> Action { get; private set; }
public ActionEventHandler(Action<TEventData> handler)
{
Action = handler;
}
/// <summary>
/// 调用具体的Action来处理事件逻辑
/// </summary>
/// <param name="eventData"></param>
public void HandleEvent(TEventData eventData)
{
Action(eventData);
}
}有了ActionEventHandler做封装，下一步就是注入IOC容器并注册到事件总线了。
/// <summary>
/// 注册Action事件处理器
/// </summary>
/// <typeparam name="TEventData"></typeparam>
/// <param name="action"></param>
public void Register<TEventData>(Action<TEventData> action) where TEventData : IEventData
{
//1.构造ActionEventHandler
var actionHandler = new ActionEventHandler<TEventData>(action);
//2.将ActionEventHandler的实例注入到Ioc容器
IocContainer.Register(
Component.For<IEventHandler<TEventData>>()
.UsingFactoryMethod(() => actionHandler)
.LifestyleSingleton());
//3.注册到事件总线
Register<TEventData>(actionHandler);
}使用起来就很简单：
//注册Action事件处理器
EventBus.Default.Register<EventData>(
actionEventData =>
{
Trace.TraceInformation(actionEventData.EventTime.ToLongDateString());
});
//触发
EventBus.Default.Trigger(new EventData());5.2. 支持异步触发
异步触发很简单直接使用Task.Run包装一下就ok了。
/// <summary>
/// 异步触发
/// </summary>
/// <typeparam name="TEventData"></typeparam>
/// <param name="eventData"></param>
/// <returns></returns>
public Task TriggerAsync<TEventData>(TEventData eventData) where TEventData : IEventData
{
return Task.Run(() => Trigger<TEventData>(eventData));
}5.3.触发指定EventHandler
在我们的Trigger方法中我们会将某一个事件源绑定的事件处理全部触发。但在某些场景下，我们可能并不需要全部触发，仅需要触发指定的EventHandler。这个需求很实际，我们来实现一下。
/// <summary>
/// 触发指定EventHandler
/// </summary>
/// <param name="eventHandlerType"></param>
/// <param name="eventData"></param>
public void Trigger<TEventData>(Type eventHandlerType, TEventData eventData)
where TEventData : IEventData
{
//获取类型实现的泛型接口
var handlerInterface = eventHandlerType.GetInterface("IEventHandler`1");
var eventHandlers = IocContainer.ResolveAll(handlerInterface);
//循环遍历，仅当解析的实例类型与映射字典中事件处理类型一致时，才触发事件
foreach (var eventHandler in eventHandlers)
{
if (eventHandler.GetType() == eventHandlerType)
{
var handler = eventHandler as IEventHandler<TEventData>;
handler?.HandleEvent(eventData);
}
}
}
/// <summary>
/// 异步触发指定EventHandler
/// </summary>
/// <param name="eventHandlerType"></param>
/// <param name="eventData"></param>
/// <returns></returns>
public Task TriggerAsycn<TEventData>(Type eventHandlerType, TEventData eventData)
where TEventData : IEventData
{
return Task.Run(() => Trigger(eventHandlerType, eventData));
}上个测试用例：
[Fact]
public async void Should_Call_Specified_Handler_Async()
{
TestEventBus.Register<TestEventData>(new TestEventHandler());
var count = 0;
TestEventBus.Register<TestEventData>(
actionEventData => { count++; }
);
await TestEventBus.TriggerAsycn<TestEventData>
(typeof(TestEventHandler), new TestEventData(999));
TestEventHandler.TestValue.ShouldBe(999);
count.ShouldBe(0);
}5.4.线程安全问题
在事件总线中，维护的事件源和事件处理的映射字典是整个程序中的重中之重。我们选择了使用ConcurrentDictionary线程安全字典来规避线程安全问题。但实际我们真正做到线程安全了吗？我们看下映射字典申明：
/// <summary>
/// 定义线程安全集合
/// </summary>
private readonly ConcurrentDictionary<Type, List<Type>> _eventAndHandlerMapping;聪慧如你，我们的事件源支持绑定多个事件处理，ConcurrentDictionary确保了对key值（事件源）修改的线程安全，但无法确保事件处理的列表List<Type>的线程安全。那我们就来动手改造吧。同样代码很简单：
/// <summary>
/// 定义锁对象
/// </summary>
private static object lockObj= new object();
/// <summary>
/// 获取事件总线映射字典中指定事件源的事件列表
/// 若有，返回列表
/// 若无，构造空列表返回
/// </summary>
/// <param name="eventType"></param>
/// <returns></returns>
private List<Type> GetOrCreateHandlers(Type eventType)
{
return _eventAndHandlerMapping.GetOrAdd(eventType, (type) => new List<Type>());
}
public void Register(Type eventType, Type handlerType)
{
//省略其他代码
//注册到事件总线
lock (lockObj)
{
GetOrCreateHandlers(eventType).Add(handlerType);
}
}
public void UnRegister<TEventData>(Type handlerType)
{
lock (lockObj)
{
GetOrCreateHandlers(typeof(TEventData)).RemoveAll(t => t == handlerType);
}
}6.单元测试
为了确保重构的正确性和业务的完整性，以上的改进都是基于单元测试进行改进的，使用的是Xunit+Shouldly。虽然不能保证单元测试的覆盖度，但至少确保了正常业务的流转。
7.总结
这一次，通过单元测试，一步一步的推进事件总线的重构和完善。主要完成了使用IOC替换反射来解耦和一些用例的完善。源码已上传至Github（源码路径：Github-EventBus）。
至此，事件总线进入Beta版本。但很显然还有许多细节有待完善，比如异常处理等，后续就不再继续这个系列，我会直接维护Github的源码，感兴趣的可自行参阅。
