Question

从控制器发布消息的最简单方法是在 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();
    }
}

使用 SimpleInjector （或使用任何其他 IoC容器）解析 MassTransit 总线依赖关系是否比所描述的方法有任何优势？是合理还是只会增加复杂性？
将基本控制器与注入服务总线实例一起使用是否合理？
MassTransit 定义了自己的IServiceBus界面。通过这种类型解决服务总线依赖是否正常？

Answer 1

使用SimpleInjector解析MassTransit总线依赖关系（或与任何其他IoC容器相比，具有任何优于所描述的优点进场？这是合理的，还是只会增加复杂性？

我想说你应该总是喜欢构造函数注入而不是直接使用Bus作为Ambient Context。使用构造函数注入具有以下优点：它使得类的依赖性非常清楚。我甚至会阻止在代码中直接使用MassTransit中的Bus类或IServiceBus抽象，而是定义自己的抽象（即使它是相同的）并注册直接映射到的代理实现MassTransit。您的消息总线应该是一个实现细节，您的应用程序不应该依赖它。这样您就可以使用Dependency Inversion Principle，它允许您将核心应用程序逻辑与任何使用过的第三方库分离。

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

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

基类是很多代码的味道，我甚至会说它是一个反模式，以防它们被用来包含一组常用的依赖项。他们试图隐藏一个类需要太多依赖关系而不解决根问题的事实，即Single Responsibility Violation。防止使用这样的基类，因为它会使这些违规行为像拇指一样突出。

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

正如我上面所说，阻止您的应用程序代码依赖Masstransit库本身。这引入了供应商锁定。您的应用程序代码（组合根除外）不必了解它使用的外部库。这适用于日志库，DI库，消息总线库;你说出来的。这样做符合Interface Segregation Principle，表明客户端应该定义抽象。使用依赖注入，防止这种耦合非常容易（并且令人愉快）。

解决服务总线依赖性。轨道交通

1 个答案: