dependency-injection - いつ依存性注入を使用しますか?

Question

私は最近 StructureMap を使用しており、その経験を十分に楽しんでいます。ただし、すべてをインターフェイスで接続することに簡単に夢中になり、コンストラクターに大量のインターフェイスを取り込むクラスになってしまうことは理解できます。依存性注入フレームワークを使用している場合、これは実際には大きな問題ではありませんが、インターフェースを提供するためだけにインターフェースを提供する必要のない特定のプロパティが存在するように感じられます。

クラスにプロパティを追加するだけでなく、何をインターフェイスアウトするかについて、どこに線を引きますか?

score 22 · Accepted Answer

依存性注入の主な問題は、疎結合アーキテクチャのように見えますが、実際にはそうではないことです。

あなたが実際に行っているのは、その結合をコンパイル時からランタイムに移動することですが、それでもクラス A が動作するためにインターフェイス B が必要な場合でも、インターフェイス B を実装するクラスのインスタンスを提供する必要があります。

依存性注入は、ベースコードを再コンパイルせずに動的に変更する必要があるアプリケーションの部分にのみ使用する必要があります。

制御パターンの反転に役立つと思われる用途:

プラグインアーキテクチャ。したがって、適切なエントリポイントを作成することで、提供する必要があるサービスの契約を定義できます。
ワークフローのようなアーキテクチャ。コンポーネントの出力を別のコンポーネントの入力に動的に接続する複数のコンポーネントを接続できます。
クライアントごとのアプリケーション。プロジェクトの一連の「機能」に対して支払いを行うさまざまなクライアントがいるとします。依存性注入を使用すると、コアコンポーネントと、クライアントが支払った機能だけを提供する「追加」コンポーネントのみを簡単に提供できます。
翻訳。これは通常、翻訳目的では行われませんが、アプリケーションの必要に応じて異なる言語ファイルを「挿入」できます。これには、必要に応じて RTL または LTR ユーザーインターフェイスが含まれます。

score 9 · Accepted Answer

あなたのデザインについて考えてください。DI を使用すると、構成の変更によってコードの機能を変更できます。また、オブジェクトを簡単に分離してテストできるように、クラス間の依存関係を解消することもできます。これがどこで意味があり、どこで意味がないかを判断する必要があります。パットの答えはありません。

経験則としては、テストが難しすぎる場合は、単一の責任と静的な依存関係にいくつかの問題があるということです。単一の機能を実行するコードをクラスに分離し、インターフェイスを抽出し、DI フレームワークを使用して実行時に正しいインスタンスを挿入することで、静的な依存関係を解消します。これにより、2 つの部分を別々にテストすることが簡単になります。

score 8 · Accepted Answer

依存性注入は、ベースコードを再コンパイルせずに動的に変更する必要があるアプリケーションの部分にのみ使用する必要があります

DIは、外部リソース（データベース、Webサービス、xmlファイル、プラグインアーキテクチャ）からコードを分離するために使用する必要があります。データベースに依存するコンポーネントをテストしている場合、コードでロジックをテストするのにかかる時間は、多くの企業でほとんど法外なものになります。

ほとんどのアプリケーションでは、データベースは動的に変更されません（ただし、変更される可能性はあります）が、一般的に言えば、アプリケーションを特定の外部リソースにバインドしないことをお勧めします。リソースの変更に伴う量は少なくする必要があります（データアクセスクラスのメソッドが循環的複雑度を超えることはめったにありません）。

score 2 · Accepted Answer

「クラスにプロパティを追加するだけ」とはどういう意味ですか?

私の経験則は、クラスユニットをテスト可能にすることです。クラスが別のクラスの実装の詳細に依存している場合は、クラスを分離してテストできるようにリファクタリング/抽象化する必要があります。

編集:コンストラクターでインターフェースのボートロードについて言及しています。代わりにセッター/ゲッターを使用することをお勧めします。長期的には、物事を維持するのがはるかに簡単になることがわかりました.

score 2 · Accepted Answer

関心の分離に役立つ場合にのみ行います。

おそらくクロスプロジェクトのように、ライブラリプロジェクトの1つで実装者にインターフェースを提供し、実装プロジェクトは必要な特定の実装を注入します。

しかし、それだけです...他のすべてのケースでは、システムが不必要に複雑になるだけです

score 1 · Accepted Answer

世界のすべての事実とプロセスがあっても..すべての決定は判断の呼びかけに要約されます-どこで読んだか忘れましたが、
それは経験/飛行時間の呼びかけだと思います. 基本的に、依存関係が近い将来に置き換えられる可能性のある候補オブジェクトと見なされる場合は、依存関係の挿入を使用します。「classA とその依存関係」を 1 つの置換ブロックと見なす場合、おそらく A の依存関係に DI を使用しないでしょう。

score 1 · Accepted Answer

最大の利点は、アプリケーションのアーキテクチャを理解したり、明らかにしたりするのに役立つことです。依存関係チェーンがどのように機能するかを非常に明確に確認でき、無関係なものを変更する必要なく、個々の部分に変更を加えることができます。疎結合のアプリケーションになってしまいます。これにより、より良い設計が可能になり、改善を続けることができるようになると驚くでしょう。これは、設計がコードの分離と整理を前進させるのに役立つからです。また、特定のインターフェイスの実装を自然に置き換える方法があるため、単体テストも容易になります。

使い捨てのアプリケーションもいくつかありますが、疑いがある場合は、先に進んでインターフェイスを作成します。ある程度の練習をすれば、それほど負担にはなりません。

score 0 · Accepted Answer

Castle Windsor / Microkernelを使用しています。他に経験はありませんが、とても気に入っています。

何を注入するかはどうやって決めるのですか？これまでのところ、次の経験則が役に立ちました。クラスが非常に単純で単体テストを必要としない場合は、クラスで自由にインスタンス化できます。そうでない場合は、コンストラクターを介して依存関係を設定する必要があります。

インターフェイスを作成する必要があるのか、メソッドとプロパティを仮想化するだけなのかについては、a）クラスが別のアプリケーション（つまりロガー）である程度の再利用性を持っていることを確認できる場合、またはb ）コンストラクターパラメーターの量が原因であるか、コンストラクターにかなりの量のロジックがあるために、クラスをモックするのは困難です。

score 0 · Accepted Answer

私が取り組んでいるもう 1 つの項目は、どこで依存性注入を使用する必要があるかということです。StructureMap への依存関係はどこにありますか? スタートアップアプリケーションのみですか？それは、すべての実装を最上層から最下層までずっと引き継がなければならないということですか?

dependency-injection - いつ依存性注入を使用しますか?

9 に答える 9

Related

Reference