データベースに構成を保存するソフトウェアを構築しているとしましょう。私のビジネスルール、ページなどは、Coreと呼ぶプロジェクトにあります。データベースにアクセスするために必要なすべてのメソッドを備えたConfigurationという別のプロジェクトがあります。そう：
BusinessComponent ConfigurationProvider
+---------------------------+ +---------------------------+
| | | |
| | ----> | |
| | | |
+---------------------------+ +---------------------------+
構成オブジェクトは、インターフェースを介しIConfigurationてビジネス コンポーネントに注入されます。
BusinessComponent IConfigurationProvider ConfigurationProvider
+--------------------------+ +---------------------------+ +---------------------------+
| | | | | |
| | ---> | | ---> | |
| | | | | |
+--------------------------+ +---------------------------+ +---------------------------+
したがって、ある意味では、 と の両方BusinessComponentが にConfigurationProvider依存しIConfigurationProviderます。
問題は、コアまたは構成の 2 つのプロジェクトのどちらにあるべきIConfigurationProviderかということです。
DI を使用する場合は、プロジェクトでインターフェイスを作成して依存関係を宣言し、それらの実装を提供することに関心のあるプロジェクトがこのプロジェクトへの参照を追加するのが最善だと思います。それは間違いなく「拡張性」のアプローチのように見えます。(これは一種の依存関係の逆転ですよね?)
ただし、同じ構成に依存するプロジェクトが複数ある場合、このアプローチは奇妙になりますIConfigurationProvider。この場合、2 つの同様の宣言があります。
これが以前に尋ねられた場合は申し訳ありませんが、見つけることができませんでした。