从零实现AOT支持的MediatR-01为什么要重构

360影视 2024-12-28 08:53 2

摘要:在项目request不多的情况下他确实会比MediatR快,但是一旦request超过1000,性能就会暴跌并且随着request数量性能下降的愈发厉害

MediatR应该是.Net中介者模式使用最广泛的类库,但是因为本身基于反射对aot不友好

在net5刚推出source generator就有人进行了重新的实现

Mediator类库

但是依然存在问题

宣称的"高性能"只是幌子

在项目request不多的情况下他确实会比MediatR快,但是一旦request超过1000,性能就会暴跌并且随着request数量性能下降的愈发厉害

performance for large projects is pretty bad

https://github.com/martinothamar/Mediator/issues/7#issuecomment-1142088164

handler不能分散在多个程序集中

很多情况下handler本身可能存在于多个程序集中,例如业务层,包引用中,在MediatR中注册时提供了RegisterServicesFromAssemblies方法但是Mediator没有对标的行为

Api/行为并不是完全一致

作为使用者我更希望完全没有差别的迁移到生成器的MediatR和他本体的Api完全一致

原本MediatR对于Behavior 是能进行更细分的操作的,拥有AddBehavior,AddOpenBehavior两种方式

因为这些问题并且Mediator已经很长时间没有更新,所以决定在空闲时间进行重构

目前已经完成基本的实现已经完成,后续会解析具体实现

基础实现

支持多程序集中定义handler

aot支持(支持web api/native aot)

性能提升

来源:opendotnet

相关推荐