テストまたは生産のための依存性注入？

Question

依存性注入フレームワークはテストのためだけに使用されているのか、それとも実動コードで使用されていますか？ ninjectのようなフレームワークを使い始めると、すべてを逆にしたくないと思われます。また、ninjectのようなものを使用するとパフォーマンスが低下しますか？

Answer 1

依存性注入はテストパターンではなく、アーキテクチャパターンです。したがって、生産コードを作成するときに使用することを意図しています。実際には、本当に良いフレームワークであれば、非常に小さなオーバーヘッドが導入されます。 ninjectや団結がそうであれば、私は自分自身を実装するために使用されたかどうかについてはっきり言うことはできません。

DIの可能な本物の欠点は、ほとんどがコーディングプロセスの周りであり、生産のパフォーマンスではありません。おそらく言及されるべきである：DIを使用するときには、「Go to Definition」を使ってコードを歩く能力を失う。それは、常に論理的だが使えないインターフェースにつながる。

Answer 2

DIを実稼働環境で使用することは間違いありません。テスト環境では、テスト目的のために物事を結ぶだけでいいです。実際にはモックオブジェクトを使用している場合、にはがあります。

Answer 3

すべてに使用してください！それを逆にするのはなぜですか？質の高いフレームワークのパフォーマンスは、起動時にのみ発生するはずです。さらに、VMが余分なレイヤーをインライン化できるようになるまで、わずかなペナルティが発生する可能性があります。いずれにしても、バグが減少し、開発者の生産性が向上します。

DIは特に生産に適しています。私たちのソフトウェアでは、私たちがテストで行ったのとまったく同じ構成をプロダクションで使用しています。

テストが実行されると、テスト設定では特定のサービスが偽装されているとフラグを立てるだけです。これは、テスト構成があることを意味します

1. リストが出て、様々な方法が出て嘲笑サービスメソッドを呼び出しの戻り値を指定するサービス
2. を嘲笑します。

テストの利点：生産と試験の間

1. なし設定の違いは
2. サービスもTestクラスに注入される潜在設定依存不具合の可能性を意味しません。
3. テスト構成は些細なものです（サービスが模擬される場合にのみ必要です）
4. テスト構成は常に本番と同じです。 （維持しやすい）
5. サービスの初期化は決してマニュアルではなく、ハッキングされています。

生産の利点：

1. クリーンコードを起動していない -
2. 循環依存関係が問題になることはありません何のハードコーディングされた依存関係。
3. サービスのローカルコピーを無効にし、要求を別のボックスにルーティングする機能。 （バックグラウンドバッチタ​​スクで使用）