依存性注入を使用する場合
この2、3日、依存性注入は本当に「決められない」パターンと呼ばれるべきだと感じました。これは馬鹿げているように聞こえるかもしれませんが、実際には、依存性注入（DI）を使用する必要がある理由についてです。多くの場合、より高いレベルの疎結合を実現するためにDIを使用する必要があると言われていますが、その部分を取得します。しかし、本当に...私の選択がMS SQLまたはMySQLに当てはまると、データベースをどのくらいの頻度で変更しますか？非常にまれですか？
誰かがDIが進むべき道である非常に説得力のある理由を持っていますか？
2つの単語単体テスト。
DIの最も説得力のある理由の1つは、データベースにアクセスして「テスト」データを設定することを心配する必要なく、ユニットテストを容易にすることです。
DIは、システムの分離に非常に役立ちます。データベースの実装をアプリケーションの残りの部分から切り離すことだけを使用している場合、アプリケーションはかなり単純であるか、問題ドメインでさらに多くの分析を行い、問題ドメイン内のコンポーネントを見つける必要があります変更される可能性が最も高く、システム内のカップリングが多いコンポーネント。
DIは、コードの再利用、汎用性、問題ドメインの変更に対する堅牢性を目指す場合に最も役立ちます。
プロジェクトとの関連性は、コードの予想される寿命に依存します。記述しているコードの大部分について、あるプロジェクトから次のプロジェクトへの再利用を行わない作業のタイプによっては、実際にはまったく問題ないかもしれません。
DIを使用する例は、DIを使用してクライアントのカスタマイズを注入する複数のクライアントに展開できるアプリケーションの作成です。これは、GOF戦略パターンとも呼ばれます。 GOFパターンの多くは、DIフレームワークを使用すると容易になります。
DIは、大量のコード、複雑なビジネス要件、およびシステムが何年または何十年も維持されることを期待（または希望）するエンタープライズアプリケーション開発により関連しています。
開発段階でプログラムの構造を変更しない場合でも、プログラムのさまざまな部分からいくつかのサブシステムにアクセスする必要があることがわかります。 DIを使用すると、クラスごとにサービスを要求するだけで、すべての配線を手動で提供する必要がなくなります。
これは、「誰か他の人が後でそれを必要とするために何を持ち運ぶ必要があるか」ではなく、ソフトウェア設計におけるものの相互作用に集中することに本当に役立ちます。
さらに、ボイラープレートコードを作成する作業の多くも節約できます。シングルトンが必要ですか？クラスを1つに構成するだけです。このような「シングルトン」でテストできますか？はい、まだ可能です（一度だけ存在するように構成しただけなので、テストでは代替実装をインスタンス化できます）。
しかし、DIを使用する前は、その価値を実際には理解していませんでしたが、実際に試してみると、以前よりずっとオブジェクト指向になっています。ちなみに、現在のアプリケーションでは単体テスト（悪い、悪い私）はしていませんが、DIと一緒に暮らすことはできません。物事を移動し、クラスを小さくシンプルに保つことは非常に簡単です。
私はDBの例に同意しますが、DIを使用するのに役立つと感じた大きな点の1つは、データベースの上に構築するレイヤーをテストするのに役立ちます。
ここに例があります...
データベースがあります。
データベースにアクセスしてオブジェクトを返すコードがあります
前のアイテムのオブジェクトを取得し、それらを使用していくつかのロジックを実行するビジネスドメインオブジェクトがあります。
データアクセスをビジネスドメインロジックとマージすると、ドメインオブジェクトのテストが困難になる可能性があります。 DIを使用すると、独自のデータアクセスオブジェクトをドメインに挿入して、テストやデモンストレーションをデータベースに依存しないようにすることができます（一部のデータがデータベースではなくxmlからプルされたデモを実行しました）。
このようなサードパーティのコンポーネントとフレームワークを抽象化することも役立ちます。
テストの例以外にも、契約による設計アプローチを通じてDIを使用できる場所がいくつかあります。挿入するオブジェクトのメソッドを呼び出すような処理エンジンを作成するのが適切な場合があります。本当に「処理する」ことはできないかもしれませんが、提供する各オブジェクトに異なる実装を持つメソッドを実行します。
すべてのビジネスドメインオブジェクトに、プロセッサに挿入された後に呼び出される「保存」関数が含まれている例を確認しました。プロセッサは構成情報でコンポーネントを変更し、保存はオブジェクトのプライマリ状態を処理しました。本質的に、DIは、インターフェイスに準拠したオブジェクトのポリモーフィックメソッド実装を補足しました。
疎結合のほかに、DIのおかげであらゆるタイプのテストがはるかに簡単に実現されます。テスト中のクラスの既存の依存関係をモック、ダミー、または別のバージョンで置き換えることができます。依存関係を直接インスタンス化してクラスを作成すると、必要に応じてクラスを「スタブ化」することが困難または不可能になる場合があります。
外部構成に基づいて実行時に実装を選択する必要があるサービス/コンポーネントが多数ある場合は、DIを使用する価値があると思います。 （このような構成は、XMLファイル、またはコード注釈と個別のクラスの組み合わせの形式をとることができます。より便利なものを選択してください。）
それ以外の場合は、DI全体のフレームワークよりもはるかに「軽量」で理解しやすいServiceLocatorを使用します。
ユニットテストでは、オブジェクトをテストからテスト対象のユニットに「注入」することを要求するのではなく、オンデマンドでオブジェクトをモックできるモックAPIを使用することを好みます。 Javaの場合、そのようなライブラリの1つは私自身のもの JMockit です。
今夜わかった。私にとって、依存性注入は、特定のコンテキストで機能するために多くのパラメーターを必要とするオブジェクトをインスタンス化する方法です。
ディペンデンシーインジェクションはいつ使用すべきですか？オブジェクトを静的な方法でインスタンス化する場合は、依存性注入を使用できます。たとえば、オブジェクトをXMLファイルまたはJSONファイルに変換できるクラスを使用していて、XMLファイルのみが必要な場合です。ディペンデンシーインジェクションを使用しない場合は、オブジェクトをインスタンス化して多くの設定を行う必要があります。
随時注入を使用すべきでないのはいつですか？オブジェクトが（送信フォームの後で）要求パラメーターでインスタンス化される場合、オブジェクトは静的な方法でインスタンス化されないため、依存性注入を使用しないでください。