可能であれば、依存性注入を常に使用する必要があります。これには明確な強みがいくつかあるためです。ただし、UI テクノロジでは、依存性注入を常に使用できるとは限りません。一部の UI テクノロジ (たとえば、.NET 空間、Win フォーム、および Web フォーム) では、UI クラス (フォーム、ページ、コントロールなど) のみが依存性注入を使用できるためです。デフォルトのコンストラクタ。その場合、サービスロケーターである別のものにフォールバックする必要があります。
その場合、私はあなたに次のアドバイスを与えることができます：
- 依存性注入を使用してコンテナーで作成できない UI クラスと、とにかく単体テストを行っていないものに対してのみ、Service Locator にフォールバックします。
- これらの UI クラス (ビュー関連のみを持つHumble オブジェクトとして) にできるだけ少ないロジックを実装するようにしてください。これにより、可能な限り単体テストを行うことができます。
- コンテナーを静的メソッドにラップして、コンテナーをアプリケーションの残りの部分から非表示にします。依存関係を解決できない場合は、この静的メソッドの呼び出しが失敗することを確認してください。
- その型の (既定の) コンストラクターですべての依存関係を解決します。これにより、後で何らかのボタンがクリックされたときではなく、そのタイプが作成されたときにその依存関係の 1 つが解決できない場合に、アプリケーションがすぐに失敗するようになります。
- アプリの起動時に (または単体テストを使用して)、これらすべての UI タイプを作成できるかどうかを確認します。これにより、(すべてのフォームを開いて) アプリケーション全体を調べて、DI 構成にエラーがあるかどうかを確認する必要がなくなります。
- コンテナーで型を構築できない場合、それらをコンテナーに登録する理由はありません。コンテナーによって作成できる場合 (ASP.NET MVC コントローラー クラスなど)、それらを明示的に登録すると便利です。一部のコンテナーでは構成を事前に確認できるため、これらの型の構成エラーを正しく検出できます。あちらへ。
単体テスト以外にも、Service Locator の使用に反対する 2 つの重要な議論があります。これらは、Mark Seemann の有名なブログ投稿Service Locator is an Anti-Patternで示されています。
- Service Locator は「クラスの依存関係を隠し、コンパイル時エラーではなく実行時エラーを引き起こします」
- Service Locator は「コードの保守をより難しくしている」