私はちょうどこの 48 時間を上記の実現に費やしました。Rhino Service Bus は非常に有用であると思いますが、ドキュメントには多くの要望が残されています。私が直面していた問題を解決したので、他の人が私がやったことを見るのに役立つかもしれないと思ったので、ここにあります. うまくいけば、誰かがそれを見つけるでしょう。
私は WPF/PRISM/Unity レポート アプリケーションを開発しており、サービス バスを使用して、VPN 経由で接続したときにバス メッセージを介してデータを取得するアプリケーションを時折接続できるようにしたいと考えていました。アプリのブートストラップにバスを導入し、Rhino DefaultHost でホストしました。ConsumerOf インターフェイスを実装するクラスのコンストラクターに IEventAggregator を挿入しようとするまでは、これによりバスが動作し、メッセージが十分にやり取りされました。
「IEventAggregator はインターフェイスであり、構築できません。型の登録がありませんか」というエラーが表示され続けましたが、イベント アグリゲーターがアプリケーションの Bootstrapper でシングルトンとして登録された理由がわかりませんでした。
問題は、ConsumerOf を実装するクラスを登録すると、そのクラスがバスの内部 Unity コンテナーに結び付けられ、そのクラスがアプリケーション コンテナーに対して持つ可能性のある接続をオーバーライドするように見えることです。
解決策 (一度見れば明白であることは認めます) は、失敗した解決 (IEventAggregator が見つからない?!) が解決のために親に渡されるように、バス コンテナーをアプリケーション コンテナーの子コンテナーにすることです (ああ、ほら、ここだ!!)。
それを達成する方法は次のとおりです...
protected override void ConfigureContainer()
{
base.ConfigureContainer();
//Singletons
var accountData = new AccountService();
//ServiceBus
var host = new DefaultHost();
host.Start<ESBBootStrapper>();
var childContainer = Container.CreateChildContainer();
new RhinoServiceBusConfiguration().UseUnity(childContainer).Configure();
var bus = childContainer.Resolve<IStartableServiceBus>();
bus.Start();
//Application Instances
Container.RegisterInstance(bus as IServiceBus, new ContainerControlledLifetimeManager());
}
また、ConsumerOf を実装しているアプリケーション内のクラスを見つけるために、ESBBootstrapper 内の同じオーバーライドを変更する必要がありました。これは次のように行われました...
public class ESBBootStrapper : UnityBootStrapper
{
protected override void ConfigureContainer()
{
base.ConfigureContainer();
foreach (var current in AppDomain.CurrentDomain.GetAssemblies())
{
ConfigureConsumers(current);
}
}
}