依存性注入フレームワークは依存性リスクを引き起こしますか？

依存性注入を使用するように既存のシステムをリファクタリングしており、その作業は順調に進んでいます。

しばらくして、社内ライブラリの多くが、使用しているDIフレームワークに依存するようになったことに気付きました。その結果、プロジェクト全体がこのサードパーティフレームワークに依存するようになりました。

共有ライブラリに依存させることで、すべての依存関係を分離することに皮肉を感じました。

私の最初の反応は、依存関係フレームワークのラッパーライブラリを作成することでした。したがって、必要に応じてこのフレームワークを置き換えることができます。関連する作業を推定した後、結果のAPIは既存のフレームワークに似ているため、置き換えがより困難になることに気付きました。だから私はその考えを捨てました。

私の懸念は、使用しているDIフレームワークが時代遅れになるか、交換する必要があることです。

DIを操作するときに、プロジェクトとDIフレームワーク間の結合を減らす開発パターンがありますか？

あなたは完全に正しいです-DIフレームワークを使用すると、おそらくそのコードに依存するコードになります。実際、これは他のすべてのフレームワークまたは基盤ライブラリに当てはまるため、特にそのlibがコードのどこでも使用されるいくつかの汎用機能でプロジェクトをサポートする場合に当てはまるため、これは驚くべきことです。たとえば、特定のUIフレームワークまたはWebフレームワークを使用することを決定した場合、そのライブラリに基づいて特定の量のコードをビルドするとすぐに、この決定を変更することは困難です。特定の（非標準の）Stringクラスを使用することにした場合、その決定を後で簡単に変更することはできません。このような決定はアーキテクチャ上の決定であり、特定のプログラミング言語を選択して、100K行を超えるコードを記述した後にその決定を変更しようとするようなものです。

すべてのコードが特定のフレームワークに依存していることは、期待どおりに機能し、適切に維持されている限り、問題にならない可能性があります。しかし、そうでない場合は問題になる可能性があります。その状況に対処する方法がいくつかあります。

• 数年前からアップデートや新しいリリースを提供できると信じているベンダーからフレームワークを選択する

• ベンダーが市場から姿を消したことを考えると、十分な数のコード行（および適切なライセンス）を備えたオープンソースフレームワークを選択してください。

• 独自のフレームワークを書く

• ベンダーが利用可能である限り状況に耐え、彼が本当に姿を消したとき、別のフレームワークを選択し、新しいフレームワークを使用して古いフレームワークをエミュレートするアダプターを作成しようとします

事前にラッパーライブラリを作成するというアイデアはまったく新しいものではありませんが、動作することはほとんどありません。 「新しい」フレームワークは次のようになります。一方、数年前、上記のアダプター戦略を適用することにより、C ++プロジェクトの完全なUIフレームワークを約120K行のコードと正常に交換しました。

通常のコンストラクター注入では、フレームワークはまったく必要ありません。失うのは、依存関係を構成ファイルに集中化する機能だけです。

DIコンテナは、「エンタープライズソフトウェア」パターンであり、オブジェクトグラフが非常に大きく複雑な場合に使用されます。私は、アプリケーションの95％がそれを必要としないと思います。

私は、DIフレームワークがすぐに本当に時代遅れになるとは思わない。廃止するにはどうすればよいですか？

• 新しい、よりスマートなパターンの発明でしょうか？どのように見えても、コードを大幅に変更する必要があります。
• 多分言語の変更？さらに悪い。

私は、現在のDIが十分に成熟しており、そこに多くのことが起こっていることに気付いていないと思います。言語を指定していないため、Guiceと言えば、かなり目立たず、標準のJavaアノテーションで動作します（標準化されていないものにも独自のアノテーションを使用しますが、ほとんど必要ありません）。オープンソースで広く使用されており、Apacheがライセンスされています。何が問題なのでしょうか？

DIフレームワークの変更は、他のライブラリを変更するよりも桁違いに簡単であると確信しています（たとえば、UIの変更はより多くの作業を意味します）。