由於滷麪的app.config XML是一種用於一個總線實例,每個進程的方案進行了優化,則不能配置多條總線充分,但沒有什麼能夠阻止您在同一個進程中啓動多個總線實例。
我經常這樣做,例如在Azure工作者角色中,我希望託管多個邏輯端點,而不會產生物理上分離的部署成本,而且我有時也使用託管的Windows服務來完成此任務。
通常情況下,我的app.config結束了以下XML:
<rebus workers="1">
<add messages="SomeAssembly.Messages" endpoint="someEndpoint.input"/>
<add messages="AnotherAssembly.Messages" endpoint="anotherEndpoint.input"/>
</rebus>
從而使我配置每個總線工人和端點映射的默認數量一勞永逸。然後,當我的應用程序啓動時,它將在應用程序生命週期期間保持每個總線的IoC容器 - 對於Windsor,我通常會得到一個具有隊列名稱參數的通用總線安裝程序,這使我可以配置Windsor像這樣:
var containers = new List<IWindsorContainer> {
new WindsorContainer()
// always handlers first
.Install(FromAssembly.Containing<SomeEndpoint.SomeHandler>())
// and then the bus, which gets started at this point
.Install(new RebusInstaller("someEndpoint.input", "error"))
// and then e.g. background timers and other "living things"
.Install(new PeriodicTimersInstannce()),
new WindsorContainer()
.Install(FromAssembly.Containing<AnotherEndpoint.AnotherHandler>())
.Install(new RebusInstaller("anotherEndpoint.input", "error"))
};
// and then remember to dispose each container when shutting down the process
其中RebusInstaller
(這是一個溫莎機構)基本上只是把一個總線與右隊列名稱放入容器中,例如像這樣:
Configure.With(new WindsorContainerAdapter(container))
.Transport(t => t.UseMsmq(_inputQueueName, _errorQueueName))
.(...) etc
.CreateBus().Start();
我喜歡這樣的想法,即每個IoC容器實例都作爲一個獨立的邏輯應用程序運行。通過這種方式,如果你想要在未來的某個時間將事情分開,很容易。能夠獨立部署您的端點。
我希望這能爲你提供一些靈感:)請不要猶豫,問你是否需要更多的指針。
感謝您的有趣答案。我通常使用Ninject作爲IoC。我會嘗試使用帶有上下文綁定的單個容器的類似方法,以便爲每個工作人員注入專用總線。 – Ganto 2014-10-06 11:37:29