MVVM を使用して WPF アプリケーションを設計しており、MVVM オブジェクトを解決するために UnityContainer を試しています。私の問題は、必要な適切なオブジェクトを構築するために、UnityContainer がすべてのビューとビューモデルへの参照を必要とすることです。これらの ViewModel の 1 つが新しいウィンドウを開く必要がある場合を除いて、これは問題ありません。これを処理するために、UnityContainer から MVVM オブジェクトを取得して新しいウィンドウを開く DialogService を用意することを考えました。ViewModel は DialogService を参照する必要があり、DialogService は UnityContainer を参照する必要があり、UnityContainer はビューとビューモデルを参照する必要があるため、循環依存関係が作成されます。私は Prism や、Nuget からインストールされた UnityContainer だけを使用していません。以下は、私の問題の簡略化された疑似コードです。
Assembly-Interfaces (私は誰も参照していません)
- IViewX
- IViewY
- IViewModelX
- IViewModelY
アセンブリ ビュー (私はインターフェイスを参照します)
- ViewX : IViewX
- ViewY : IViewY
Assembly-ViewModels (Interfaces と DialogService を参照) <- これは循環依存です
- ViewModelX : IViewModelX
- ViewModelY : IViewModelY
Assembly-MyUnityContainer (インターフェイス、ビュー、およびビューモデルを参照します)
- UnityService (UnityContainer へのアクセスを提供します)
Assembly-DialogService (Interfaces と MyUnityContainer を参照)
- ダイアログサービス
明らかに私のデザインには欠陥があります。Views と ViewModels を解決するために UnityContainer をどこからでも参照する必要があるため、UnityContainer をどこからでも使用する正しい方法が何であるかはわかりません。UnityContainer を使用した経験のある方は、私が間違っている点と、これをどのように設計することをお勧めしますか? ところで私はWPF 4.5を使用しています。
注: 私の問題は設計に関連しています。文字通り、ViewModel に DialogService への参照を追加できません。VS はそれを許可しません。これは、循環依存関係がスタック オーバーフローを引き起こす問題ではありません。それを明確にしたかっただけです。
ありがとう！
編集：解決 策私が受け取ったアドバイスに従って、私は次のようなデザインをすることになりました。
MainApp はすべてを確認するため、UnityContainer を作成し、すべての型を登録して、IUnityContainer として DialogService アセンブリに渡します。これで、DialogService アセンブリは具体的な実装を知らなくても、任意のインターフェイス タイプを解決できます。ViewModel は DialogService を使用してダイアログ サービスを作成できます。これにより、ウィンドウやその他のダイアログが開きます。ViewModel は、開きたいインターフェイスを認識し、それを DialogService に渡すだけでよく、ダイアログ サービスはウィンドウを開く作業を行います。