事件总线知多少(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的源码,感兴趣的可自行参阅。
参考资料:
ABP EventBus
[c#] 反射真的很可怕吗?
推荐链接:你必须知道的ML.NET开发指南
推荐链接:你必须知道的Office开发指南
推荐链接:你必须知道的IOT开发指南
推荐链接:你必须知道的Azure基础知识
推荐链接:你必须知道的PowerBI基础知识
关注我的公众号『微服务知多少』,我们微信不见不散。
阅罢此文,如果您觉得本文不错并有所收获,请【打赏】或【推荐】,也可【评论】留下您的问题或建议与我交流。 你的支持是我不断创作和分享的不竭动力!