4

依存性注入を使用する方が良いと言う人もいます。何故ですか？

巨大なコンストラクターよりも、グローバルでアクセスしやすいクラスが少ないほうがよいと思います。

アプリケーションの速度に何らかの影響がありますか?

この2つの組み合わせがおそらくベストでしょう。

4

4 に答える 4

5

主な利点はdecouplingで、単体テストに役立ちます。これは、これらの「簡単にアクセスできるクラス」をどのようにコーディングするかに完全に依存します。

アイデアはこれです。クラスは、コントラクト( )のみに依存することで、実装( ) の依存関係から切り離されます。実際の環境では、新しい実装クラスを提供することは決してないかもしれませんが、テスト環境ではおそらく提供するでしょう (手作りのスタブであれ、モック フレームワークからのモック クラスであれ)。classinterface

アプリケーションの速度にはプロファイリングが必要ですが、DI のフレームワークを使用すると、既知のシングルトンと直接やり取りする代わりに、オーバーヘッドが発生する可能性があります。重要な質問: このオーバーヘッドは問題ですか? それを教えてくれるのは、パフォーマンスの期待値とプロファイリングだけです。私の経験では、そのメリットは無視できるほどのパフォーマンスの低下をはるかに上回ります。

于 2012-05-01T08:57:10.807 に答える
4

staticおそらく、クラスとメソッドをグローバルとして使用するでしょう。パフォーマンスへの影響はありません。ただし、静的クラスはテスト容易性には向いていません。

静的メソッドの欠点は何ですか?

さらに、コードが静的クラス (グローバル) に密結合されると、将来それらを別の実装に置き換えることができなくなります。そのため、非常に単純な状況で使用しない限り、グローバルは適切な設計ではない可能性があります。

静的クラスとメソッドはコンパイル時バインディングであり、DI は実行時バインディングであることに注意してください。クラスを疎結合に保つのに役立ちます。

于 2012-05-01T08:56:48.847 に答える
1

このトピックに関するトップの投稿には、DI の非常に優れた要約と、それを正しい方法で使用する方法があると思います: Dependency Inject (DI) の「フレンドリーな」ライブラリ

このトピックについて深く掘り下げたい場合は、Mark Seeman 著の「Dependency Injection in .NET」という本をお勧めします。

于 2012-05-02T11:20:24.207 に答える
1

「グローバル」と DI の使用には大きな違いがあります。まず、おそらくシングルトンとサービスロケーターをステップスルーするため、通常、パスは分割されません. どちらも今日、どういうわけかアンチパターンと見なされています。その理由は、テスト可能なコードを設計することになっているためです。これにより、保守や新しい要件を満たすためにコードベースを変更する必要がある場合に大きな利点が得られます。コードが分離されていれば、テスト可能性は容易に達成できます。グローバルな動作はデカップリングに役立たないので、たとえば、静的シングルトンにアクセスするコードがある場合、シングルトン自体が必要なそのようなコードをテストするには、それをモックすることはできません。好きなようにシステムにストレスを与えます。一見したところ、サービス ロケーターの方が優れているように見えます。テストが必要な場合は、サービス ロケーターを最終的にモックできますが、次のことを行う必要があります。

  • テスト対象のシステムがロケーターに要求するサービスを事前に把握する
  • 返されたサービスもモックする可能性があるため、常に「再帰的モック」を作成してください。

コンストラクターでの DI は、オブジェクトが実行する必要があるものを非常に明確に記述し、何をモック、スタブなどにするかを一目で決定できるため、コード分離の良い方法です。DIカーネルがコード全体の依存関係として移動しないようにする場合にのみ、DIが機能し、役立つことに注意してください。これにより、アンチパターンでDIが変換されます（コードを分離しますが、コンテナにバインドします）。構成ルート パターンを学習して実際に実装することを忘れないでください。これにより、より優れたテスト可能なコードを作成することができます。

于 2012-05-01T09:15:39.990 に答える