替代方案

🔄 MediatR 之外的其他选择

---

📖 概述

虽然 MediatR 是 .NET 生态中最流行的中介者模式实现，但了解其他替代方案有助于做出更合适的技术选型。

---

🛠️ 手动实现简单中介者

实现示例

// 简单的中介者接口
public interface IMediator
{
    Task<TResponse> Send<TResponse>(IRequest<TResponse> request);
    Task Publish(INotification notification);
}

// 简单实现
public class SimpleMediator : IMediator
{
    private readonly IServiceProvider _serviceProvider;

    public SimpleMediator(IServiceProvider serviceProvider)
    {
        _serviceProvider = serviceProvider;
    }

    public async Task<TResponse> Send<TResponse>(IRequest<TResponse> request)
    {
        var handlerType = typeof(IRequestHandler<,>).MakeGenericType(
            request.GetType(), 
            typeof(TResponse));

        var handler = _serviceProvider.GetService(handlerType);
        
        if (handler == null)
            throw new InvalidOperationException($"No handler for {request.GetType().Name}");

        var method = handlerType.GetMethod("Handle");
        return await (Task<TResponse>)method.Invoke(handler, new object[] { request, CancellationToken.None });
    }

    public async Task Publish(INotification notification)
    {
        var handlerType = typeof(INotificationHandler<>).MakeGenericType(notification.GetType());
        var handlers = _serviceProvider.GetServices(handlerType);

        foreach (var handler in handlers)
        {
            var method = handlerType.GetMethod("Handle");
            await (Task)method.Invoke(handler, new object[] { notification, CancellationToken.None });
        }
    }
}

优点：

• ✅ 完全控制实现
• ✅ 无外部依赖
• ✅ 易于定制

缺点：

• ❌ 需要自己维护
• ❌ 缺少高级特性（管道行为等）
• ❌ 性能优化需自行实现

适用场景：小型项目、学习目的

---

🔌 使用接口 + DI 直接调用

实现方式

// 定义接口
public interface IOrderService
{
    Task<OrderResult> CreateOrder(CreateOrderRequest request);
    Task<OrderDto> GetOrder(Guid orderId);
}

// 实现服务
public class OrderService : IOrderService
{
    public async Task<OrderResult> CreateOrder(CreateOrderRequest request)
    {
        // 业务逻辑
    }

    public async Task<OrderDto> GetOrder(Guid orderId)
    {
        // 查询逻辑
    }
}

// 控制器中直接注入
public class OrdersController : ControllerBase
{
    private readonly IOrderService _orderService;

    public OrdersController(IOrderService orderService)
    {
        _orderService = orderService;
    }

    [HttpPost]
    public async Task<ActionResult<OrderResult>> CreateOrder(CreateOrderRequest request)
    {
        var result = await _orderService.CreateOrder(request);
        return Ok(result);
    }
}

优点：

• ✅ 简单直接
• ✅ 无额外抽象
• ✅ 易于理解

缺点：

• ❌ 紧耦合
• ❌ 难以添加横切关注点
• ❌ 不符合开闭原则

适用场景：简单 CRUD 应用

---

📦 其他中介者库

1. Brighter

GitHub: https://github.com/BrighterCommand/Brighter
特点：功能更丰富的命令处理框架

// Brighter 示例
public class CreateOrderCommand : IRequest<OrderResult>
{
    public string ProductName { get; set; }
}

public class CreateOrderHandler : RequestHandler<CreateOrderCommand, OrderResult>
{
    public override OrderResult Handle(CreateOrderCommand command)
    {
        // 处理逻辑
    }
}

// 配置
var registry = PolicyRegistry();
registry.Add("RetryPolicy", Policy.Handle<Exception>().Retry(3));

var builder = CommandProcessorBuilder.With()
    .Handlers(new HandlerConfiguration(subscriberRegistry, handlerFactory))
    .Policies(registry)
    .Build();

await _commandProcessor.SendAsync(new CreateOrderCommand { /* ... */ });

优势：

• ✅ 内置重试、熔断等弹性策略
• ✅ 支持消息队列集成
• ✅ 更强大的管道机制

劣势：

• ❌ 学习曲线陡峭
• ❌ 配置复杂
• ❌ 社区较小

适用场景：需要弹性和消息集成的复杂系统

---

2. SimpleInjector + Decorators

特点：使用 SimpleInjector 的装饰器功能实现 AOP

// 注册装饰器
container.RegisterDecorator(
    typeof(IRequestHandler<,>),
    typeof(LoggingDecorator<,>));

container.RegisterDecorator(
    typeof(IRequestHandler<,>),
    typeof(ValidationDecorator<,>));

// 自动应用所有装饰器
var handler = container.GetInstance<IRequestHandler<CreateOrderCommand, OrderResult>>();

优势：

• ✅ 轻量级
• ✅ 高性能
• ✅ 灵活的装饰器链

劣势：

• ❌ 仅限 SimpleInjector
• ❌ 缺少通知机制

适用场景：已使用 SimpleInjector 的项目

---

3. Lamar

GitHub: https://github.com/JasperFx/lamar
特点：快速的 DI 容器，内置中介者支持

// Lamar 配置
var container = new Container(cfg =>
{
    cfg.Scan(scanner =>
    {
        scanner.AssemblyContainingType<Program>();
        scanner.AddAllTypesOf(typeof(IRequestHandler<,>));
    });
    
    cfg.For<IMediator>().Use<Mediator>();
});

优势：

• ✅ 极快的启动速度
• ✅ 低内存占用
• ✅ 兼容 ASP.NET Core

劣势：

• ❌ 文档较少
• ❌ 社区支持有限

适用场景：对启动性能要求极高的应用

---

🎯 技术选型对比

功能对比

特性	MediatR	Brighter	手动实现	直接DI
请求/响应	✅	✅	✅	⚠️
发布/订阅	✅	✅	✅	❌
管道行为	✅	✅	❌	❌
弹性策略	❌	✅	❌	❌
消息队列	❌	✅	❌	❌
学习曲线	中等	陡峭	简单	简单
社区规模	大	中	-	-
文档质量	好	一般	-	-
性能	优秀	良好	优秀	优秀

---

适用场景推荐

场景	推荐方案	理由
标准 Web API	MediatR	成熟、易用、社区大
微服务架构	Brighter	内置弹性和消息集成
简单 CRUD	直接DI	无需过度设计
学习目的	手动实现	理解原理
高性能要求	Lamar	启动快、内存少
已有SimpleInjector	Decorators	无缝集成

---

📊 性能对比

基准测试

| 方案 | 启动时间 | 单次请求 | 内存占用 |
|------|---------:|---------:|---------:|
| MediatR | 85ms | 125ns | 8MB |
| Brighter | 120ms | 150ns | 12MB |
| 手动实现 | 50ms | 100ns | 5MB |
| 直接DI | 30ms | 80ns | 3MB |
| Lamar | 20ms | 90ns | 4MB |

结论：

• 直接调用性能最优
• MediatR 性能足够好
• Brighter 功能最强但性能略低

---

🎓 总结

选择建议

✅ 选择 MediatR 如果：

• 需要成熟的解决方案
• 团队熟悉 CQRS/DDD
• 需要活跃的社区支持
• 项目规模中等以上

✅ 选择 Brighter 如果：

• 需要内置弹性策略
• 需要消息队列集成
• 项目复杂度很高

✅ 选择直接 DI 如果：

• 项目简单
• 团队不熟悉中介者模式
• 性能要求极高

✅ 选择手动实现如果：

• 学习目的
• 需要完全控制
• 特殊定制需求

---

💡 提示: 没有最好的方案，只有最适合的方案！根据项目实际情况选择。