Mediator项目中的Assembly扫描机制解析

在.NET生态系统中，Mediator是一个流行的中介者模式实现库，它通过源生成器(Source Generator)技术自动发现和处理请求/响应模式。本文将深入探讨Mediator项目中Assembly扫描机制的工作原理及其配置方式。

Assembly扫描机制概述

Mediator的核心功能之一是自动发现并注册请求处理器(Handler)。默认情况下，当调用AddMediator方法时，如果不进行任何配置，源生成器会扫描项目引用的所有程序集(Assembly)来查找处理器类。

这种全自动扫描虽然方便，但在某些场景下可能带来性能问题或意外的行为，特别是在：

1. 单元测试环境中，希望只测试特定处理器
2. 大型项目中，存在大量处理器但只需要使用其中一小部分
3. 需要严格控制依赖关系的场景

精确控制扫描范围

Mediator提供了MediatorOptions.Assemblies属性来精确控制扫描范围。通过这个属性，开发者可以指定只扫描特定的程序集，而不是所有引用程序集。

services.AddMediator(o => o.Assemblies = [typeof(PaymentHistoryQuery).Assembly]);

上述代码将扫描限制在包含PaymentHistoryQuery类型的程序集内。值得注意的是，这里扫描的是整个程序集，而不仅仅是typeof表达式指定的那个类型。

生命周期管理的影响

Mediator中处理器(Handler)的生命周期设置会影响其初始化行为：

• Singleton(单例): 所有处理器会在解析IMediator时立即初始化
• Scoped(作用域): 处理器会按需延迟初始化
• Transient(瞬时): 处理器会按需延迟初始化

在测试环境中，如果希望避免不必要的处理器初始化，可以将生命周期设置为Scoped或Transient，这样处理器只有在实际被调用时才会初始化。

services.AddMediator(o => {
    o.Assemblies = [typeof(PaymentHistoryQuery).Assembly];
    o.ServiceLifetime = ServiceLifetime.Scoped;
});

实际应用建议

1. 测试环境优化：在单元测试中，只注册和测试特定的处理器，减少不必要的依赖和初始化开销。

2. 模块化开发：在模块化应用程序中，每个模块可以只注册自己的处理器程序集，保持清晰的边界。

3. 性能敏感场景：对于启动性能要求高的应用，精确控制扫描范围可以减少启动时的反射开销。

理解并合理配置Mediator的Assembly扫描机制，可以帮助开发者构建更高效、更可控的应用程序架构。通过结合精确的Assembly指定和适当的生命周期管理，可以在便利性和性能之间取得良好平衡。