解析服务总线依赖项.公共交通

本文关键字：依赖 服务 总线 | 更新日期: 2024-11-07 19:16:26

从

控制器发布消息的最简单方法是在 Global.asax 中有一个注册码.cs：

public class MvcApplication : HttpApplication {
    protected void Application_Start() {
        Bus.Initialize(sbc => {
            sbc.UseRabbitMq();
            sbc.ReceiveFrom("rabbitmq://localhost/commands_webui");
        });
    }
}

并在控制器中调用代码，如下所示：

public class OrdersController : Controller {
    public ActionResult AddOrderLine(OrderLine input) {
        var command = SOME_OO_MAPPER<AddOrderLineCommand>(input).Map();
        Bus.Instance.Publish<AddOrderLineCommand>(command);
        return View();
    }
}
  1. 与所描述的方法相比，使用SimpleInjector（或任何其他IoC容器）解决MassTransit bus依赖性是否有任何优势？这是合理的还是只会增加复杂性？
  2. 将基本控制器与注入的服务总线实例一起使用是否合理？
  3. MassTransit 定义了自己的IServiceBus接口。通过此类型解析服务总线依赖项是否正常？

解析服务总线依赖项.公共交通

是否使用SimpleInjector解决MassTransit Bus依赖性（或 与任何其他 IoC 容器相比具有任何优势 方法？这是合理的还是只会增加复杂性？

我想说的是，您应该始终支持构造函数注入，而不是直接将总线用作环境上下文。使用构造函数注入的优点是，它可以真正清楚地了解类的依赖项是什么。我什至会阻止直接在您的代码中使用来自 MassTransit 的 Bus 类或IServiceBus抽象，而是定义您自己的抽象（即使它是相同的）并注册直接映射到 MassTransit 的代理实现。消息总线应该是实现细节，应用程序不必依赖它。通过这种方式，您可以遵循依赖关系反转原则，该原则允许您将核心应用程序逻辑与任何使用的第三方库分离。

使用构造函数注入不会增加复杂性;您的类具有相同数量的依赖项。最大的区别在于，这更加灵活和透明。

使用带有注入服务总线的基本控制器是否合理 实例？

基类是许多人的代码气味，我什至会说它是一种反模式，以防它们用于包含一组常用的依赖项。他们试图隐藏一个类需要太多依赖项的事实，而不解决根本问题，即单一责任违规。防止使用这样的基类，因为它会使这些违规像拇指酸痛一样突出。

MassTransit 定义了自己的 IServiceBus 接口。正常吗 通过此类型解决服务总线依赖项？

正如我上面所说，防止您的应用程序代码依赖于 Masstransit 库本身。这引入了供应商锁定。您的应用程序代码（组合根目录除外）不必知道它使用的外部库的任何信息。这适用于日志记录库、DI 库、消息总线库;你的名字。这样做符合接口隔离原则，该原则指出客户端应定义抽象。使用依赖注入，防止这种耦合非常容易（且令人愉快）。

相关文章：