解決服務總線依賴性。 軌道交通

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();
    }
}

1. 與SimpleInjector （或任何其他IoC容器 ）相比，解決MassTransit總線依賴性是否比上述方法有任何優勢？ 是合理的還是只會增加復雜性？
2. 將基本控制器與注入的服務總線實例一起使用是否合理？
3. MassTransit定義了自己的IServiceBus接口。 通過這種類型解決服務總線依賴性是否正常？

Answer 1

與SimpleInjector（或任何其他IoC容器）相比，解決MassTransit總線依賴性是否比上述方法有任何優勢？ 是合理的還是只會增加復雜性？

我要說的是，與直接將Bus直接用作環境上下文相比 ，您應該始終偏向於構造函數注入。 使用構造函數注入的優勢在於，它可以真正弄清類的依賴關系是什么。 我什至會阻止直接在您的代碼中使用MassTransit的Bus類或IServiceBus抽象，而是定義自己的抽象（即使相同），並注冊一個直接映射到MassTransit的代理實現。 您的消息總線應該是實現細節，您的應用程序不必依賴於它。 這樣，您就可以遵循Dependency Inversion Principle ，它使您可以將核心應用程序邏輯與任何二手的第三方庫分離。

使用構造函數注入不會增加復雜性。 您的類具有相同數量的依賴項。 最大的區別是，這更加靈活和透明。

將基本控制器與注入的服務總線實例一起使用是否合理？

對於許多人來說，基類是代碼的味道，如果它們被用來包含一組常用的依賴項，我什至會說它是一種反模式。 他們試圖掩蓋一個類需要太多依賴的事實，而沒有解決根本問題，即單一責任違規 。 避免使用這樣的基類，因為這會使這些違規像拇指酸痛一樣突出。

MassTransit定義了自己的IServiceBus接口。 通過這種類型解決服務總線依賴性是否正常？

如上所述，請防止您的應用程序代碼依賴於Masstransit庫本身。 這引入了供應商鎖定。 您的應用程序代碼（“合成根”除外）不必了解有關其使用的外部庫的任何信息。 這適用於日志記錄庫，DI庫，消息總線庫； 你給它命名。 這樣做符合接口隔離原則 ，該原則規定客戶端應定義抽象。 借助依賴注入，防止這種耦合確實非常容易（而且很愉快）。