代码之家  ›  专栏  ›  技术社区  ›  lexeme

正在解决服务总线依赖关系。MassTransit公司

  •  1
  • lexeme  · 技术社区  · 10 年前

    从控制器发布消息的最简单方法是在 全局.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. 是否解决 MassTransit公司 总线依赖性 单喷油器 (或与任何其他 IoC容器 )与上述方法相比有什么优势吗? 这是合理的还是只会增加复杂性?
    2. 使用 基本控制器 具有 注入服务总线实例 ?
    3. MassTransit公司 定义自己的 IServiceBus 界面通过此类型解决服务总线依赖性是否正常?
    1 回复  |  直到 10 年前
        1
  •  1
  •   Steven    9 年前

    是否使用SimpleInjector(或 与任何其他IoC容器)相比具有任何优点 方法这是合理的还是只会增加复杂性?

    我想说,您应该始终支持构造函数注入,而不是直接使用总线作为 Ambient Context 使用构造函数注入的优点是它可以真正明确类的依赖关系是什么。我甚至会阻止使用 Bus 类或 IServiceBus 直接在代码中从MassTransit抽象,而是定义自己的抽象(即使它是相同的)并注册一个直接映射到 MassTransit 。消息总线应该是一个实现细节,应用程序不应该依赖它 Dependency Inversion Principle ,这允许您将核心应用程序逻辑与任何使用的第三方库分离。

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

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

    基类是许多人的代码气味,我甚至会说它是一种反模式,以防它们被用来包含一组常用的依赖项。他们试图隐藏这样一个事实:一个类需要太多的依赖项,而没有解决根本问题,即 Single Responsibility Violation 。防止像这样使用基类,因为这样会使这些违规行为变得非常突出。

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

    如上所述,防止应用程序代码依赖Masstransit库本身。这引入了供应商锁定。您的应用程序代码(除了Composition Root)不应该知道它使用的外部库。这适用于日志库、DI库、消息总线库;这样做符合 Interface Segregation Principle 声明客户端应该定义抽象。通过依赖注入,防止这种耦合非常容易(而且令人愉快)。