タグ付けされた質問 「dependency-injection」

最近、シングルトンの使用（および過剰使用）に関する問題について多くの議論がありました。私も私のキャリアの早い段階でそれらの人々の一人でした。現在、問題が何であるかを見ることができますが、良い選択肢を見つけることができない場合がまだ多くあります。反シングルトンの議論の多くは実際にそれを提供しません。 ここに私が関わった最近の主要なプロジェクトの実例があります： アプリケーションは、頻繁に更新されないサーバー状態からの大量のデータを使用する多くの個別の画面とコンポーネントを持つシッククライアントでした。このデータは基本的にシングルトンの「マネージャー」オブジェクト、つまり恐ろしい「グローバル状態」にキャッシュされていました。データの保存と同期を維持するアプリ内のこの場所を1つにして、サーバーからさまざまなサポートデータを繰り返し要求することなく、開いた新しい画面で必要なもののほとんどを照会できるようにするというアイデアでした。サーバーへの絶え間ないリクエストは帯域幅を使いすぎます-そして私は週に数千ドルの追加のインターネット請求書を話しているので、それは受け入れられませんでした。 基本的にこの種のグローバルデータマネージャーキャッシュオブジェクトを持つ以外に、ここで適切と思われる他のアプローチはありますか？もちろん、このオブジェクトは「シングルトン」である必要はありませんが、概念的には「シングルトン」であることが理にかなっています。ここできれいな代替品は何ですか？

554 design-patterns  dependency-injection  anti-patterns  caching 

そのため、私はJavaで新しいプロジェクトを開始し、Springの使用を検討しています。なぜ春を検討するのですか？多くの人が私にSpringを使うべきだと言っているからです！真剣に、私は人々にSpringが何であるか、それが何であるかを説明するように試みたときはいつでも、彼らは私にまっすぐな答えを与えることはできません。SpringSourceサイトでイントロを確認しましたが、それらは非常に複雑であるか、本当にチュートリアルに焦点を当てています。いずれも、私がそれを使用する理由、またはそれが私の生活を楽にする方法について良いアイデアを与えてくれません。時々、人々は「依存性注入」という用語をまき散らしますが、これは私をさらに混乱させるだけです。なぜなら、その用語の意味が違うと思うからです。 とにかく、私の背景とアプリについて少し説明します。 しばらくJavaで開発しており、バックエンドWeb開発を行っています。はい、私は大量の単体テストを行っています。これを容易にするために、私は通常、（少なくとも）2つのバージョンのメソッドを作成します。1つはインスタンス変数を使用し、もう1つはメソッドに渡される変数のみを使用します。インスタンス変数を使用する方は、もう一方を呼び出して、インスタンス変数を提供します。単体テストの時間になると、Mockitoを使用してオブジェクトをモックアップし、インスタンス変数を使用しないメソッドを呼び出します。これは私が常に「依存性注入」であると理解してきたことです。 私のアプリは、CSの観点からは非常にシンプルです。小規模なプロジェクト、1〜2人の開発者。主にCRUDタイプの操作で、大量の検索がスローされます。基本的には、一連のRESTful Webサービスに加えて、Webフロントエンド、そして最終的には一部のモバイルクライアントです。フロントエンドをストレートHTML / CSS / JS / JQueryで行うことを考えているので、JSPを使用する予定はありません。HibernateをORMとして使用し、Jerseyを使用してWebサービスを実装します。 私はすでにコーディングを始めており、デモを手に入れたいと思っています。したがって、明らかに時間が重要です。Springには学習曲線がかなりあることを理解していますが、それに加えて、多くのXML構成が必要なように見えますが、通常はペストのように避けるようにしています。しかし、それが私の生活を楽にすることができ、そして（特に）それが開発とテストをより速くすることができるなら、私は弾丸を噛んで春を学ぼうと思っています。 だからお願い。私を教育してください。Springを使用する必要がありますか？なぜですか？

237 java  frameworks  dependency-injection  spring 

自動テストを学習する（そして愛する）ので、ほとんどすべてのプロジェクトで依存性注入パターンを使用していることに気付きました。自動テストを使用する場合、このパターンを使用することは常に適切ですか？依存性注入の使用を避けるべき状況はありますか？

124 design-patterns  dependency-injection 

依存性注入（DI）は、よく知られた流行のパターンです。ほとんどのエンジニアは、次のような利点を知っています。 単体テストの分離を可能/簡単にする クラスの依存関係を明示的に定義する 優れた設計の促進（たとえば、単一責任原則（SRP）） すばやく切り替え実装を可能にする（DbLogger代わりにConsoleLogger例えば） DIは良い、有用なパターンであるという業界全体のコンセンサスがあると思います。現時点ではあまり批判はありません。コミュニティで言及されている欠点は、通常は軽微です。それらのいくつか： クラスの数が増えました 不要なインターフェイスの作成 現在、同僚とアーキテクチャ設計について話し合っています。彼はかなり保守的ですが、心を開いています。ITの多くの人々は最新のトレンドをコピーし、利点を繰り返し、一般的にはあまり考えすぎないため、あまり深く分析しないでください。 お願いしたいことは： 実装が1つしかない場合、依存性注入を使用する必要がありますか？ 言語/フレームワーク以外の新しいオブジェクトの作成を禁止すべきですか？ 特定のクラスの単体テストを計画しない場合、単一の実装をインジェクトするのは悪い考えです（実装が1つしかないため、「空の」インターフェースを作成したくないとしましょう）。

118 design-patterns  architecture  dependency-injection 

私は依存性注入（DI）と制御の反転（IOC）の多くの参照を見てきましたが、それらの間に違いがあるかどうかは本当にわかりません。 どちらかまたは両方を使い始めたいのですが、それらの違いについて少し混乱しています。

117 dependency-injection  inversion-of-control 

私は依存性注入（DI）について読んでいます。私にとって、それは制御の反転（IoC）を参照していることを読んでいたので、行うのは非常に複雑なことであり、私は旅に出るつもりだと感じました。 これは私の理解です：それを消費するクラスでモデルを作成する代わりに、モデルを（すでに興味深いプロパティで満たされている）必要な場所に渡します（注入します）コンストラクター）。 私には、これは単に引数を渡すだけです。私はポイントを理解し損ねたに違いない？おそらく、より大きなプロジェクトでより明白になりますか？ 私の理解は非DIです（擬似コードを使用）： public void Start() { MyClass class = new MyClass(); } ... public MyClass() { this.MyInterface = new MyInterface(); } DIは public void Start() { MyInterface myInterface = new MyInterface(); MyClass class = new MyClass(myInterface); } ... public MyClass(MyInterface myInterface) { this.MyInterface = myInterface; } 私はここで混乱していると確信しているので、誰かが光を当てることができますか？

109 dependency-injection 

クラス内で依存関係を直接インスタンス化することは悪い習慣と見なされることを理解しています。これは、すべてを密接に結合するため、テストが非常に困難になるため、理にかなっています。 私が出くわしたほとんどすべてのフレームワークは、サービスロケーターの使用よりもコンテナーでの依存性注入を好むようです。どちらも、クラスが依存関係を必要とするときに返されるオブジェクトをプログラマーが指定できるようにすることで、同じことを達成しているようです。 2つの違いは何ですか？なぜ私は一方をもう一方よりも選ぶのでしょうか？

107 dependency-injection  ioc-containers  service-locator 

自動化されたテストの価値を理解し、問題が十分に特定されていて、良いテストケースを思いつくことができる場所ならどこでもそれを使用します。ただし、こことStackOverflowの一部の人々は、依存関係ではなくユニットのみをテストすることを強調していることに気付きました。ここでは、利益が見られません。 テストの依存関係を回避するためのモッキング/スタブ化は、テストを複雑にします。実稼働コードに人為的な柔軟性/デカップリング要件を追加して、モックをサポートします。（これは良いデザインを促進すると言う人には賛成できません。余分なコードを書いたり、依存性注入フレームワークのようなものを導入したり、コードベースに複雑さを加えて実際のユースケースなしで物事をより柔軟/プラグ可能/拡張可能/分離することは、オーバーエンジニアリングではなく、良いデザイン。） 第二に、依存関係のテストとは、どこでも使用される重要な低レベルコードが、テストを明示的に考えた人以外の入力でテストされることを意味します。依存する低レベルの機能をモックアウトせずに、高レベルの機能で単体テストを実行することで、低レベルの機能に多くのバグを発見しました。理想的には、これらは低レベル機能の単体テストで発見されたはずですが、見逃されたケースは常に発生します。 これの反対側は何ですか？単体テストが依存関係もテストしないことは本当に重要ですか？もしそうなら、なぜですか？ 編集：データベース、ネットワーク、Webサービスなどの外部依存関係のモックの価値を理解できます（これを明確にする動機付けをしてくれたAnna Learに感謝します）。内部依存関係、つまり他のクラス、静的関数などに言及していました。直接的な外部依存関係はありません。

103 testing  unit-testing  dependency-injection  mocking 

私が依存性注入（DI）と自動テストの大ファンであることを知っておいてください。私はそれについて一日中話すことができました。 バックグラウンド 最近、私たちのチームは、ゼロから構築するこの大きなプロジェクトを手に入れました。複雑なビジネス要件を持つ戦略的アプリケーションです。もちろん、私はそれが素晴らしくてきれいであることを望んでいました。だから私はDIを使いたかった。 抵抗 問題は私たちのチームにありました、DIはタブーです。それは数回育てられましたが、神は承認しません。しかし、それは私を落胆させませんでした。 私の動き これは奇妙に聞こえるかもしれませんが、サードパーティのライブラリは通常、アーキテクトチームによって承認されていません（「あなたは指を切らないように、「Unity、Ninject、NHibernate、MoqまたはNUnitについて話さないでください」）。そのため、確立されたDIコンテナーを使用する代わりに、非常に単純なコンテナーを作成しました。基本的には、起動時にすべての依存関係を結び付け、依存関係（コンストラクター/プロパティ）を挿入し、Web要求の最後に使い捨てオブジェクトを破棄します。それは非常に軽量で、必要なことだけを行いました。そして、私は彼らにそれをレビューするように頼みました。 応答 まあ、短くするために。私は重い抵抗に会いました。主な議論は、「すでに複雑なプロジェクトにこの複雑さの層を追加する必要はありません」でした。また、「コンポーネントの異なる実装をプラグインするようなものではありません」。そして、「できる限りすべてを1つのアセンブリに詰め込んで、できるだけシンプルにしたいと考えています。DIは、メリットのない不必要な複雑さです」。 最後に、私の質問 私の状況をどのように処理しますか？私は自分のアイデアを提示するのが苦手で、人々が議論をどのように提示するかを知りたいと思います。 もちろん、私と同じように、DIの使用を好むと思います。同意しない場合は、その理由を言ってください。そうすれば、コインの反対側を見ることができます。同意しない人の視点を見るのは本当に面白いでしょう。 更新 みんなの回答ありがとうございます。それは本当に物事を見通しに入れます。フィードバックを提供するために別の目があれば十分ですが、15は本当に素晴らしいです！これは本当に素晴らしい答えであり、さまざまな側面から問題を見るのに役立ちましたが、私は1つの答えしか選択できないので、トップの投票されたものを選ぶだけです。答えてくれてありがとう。 私はおそらくDIを実装するのに最適な時期ではないと判断し、私たちはその準備ができていません。代わりに、設計をテスト可能にし、自動化された単体テストを提示することに努力を集中します。テストを書くことは追加のオーバーヘッドであり、追加のオーバーヘッドがそれだけの価値がないと判断されたとしても、デザインはまだテスト可能であるため、個人的にはそれを勝利の状況と見なします。また、将来的にテストまたはDIを選択する場合、設計で簡単に処理できます。

95 dependency-injection 

システムを設計するとき、他のモジュールで使用されているモジュール（ロギング、データベースアクセスなど）の問題にしばしば直面します。問題は、これらのコンポーネントを他のコンポーネントに提供する方法です。依存性の注入またはファクトリパターンの使用の2つの答えが考えられます。ただし、両方とも間違っているようです： 工場はテストを困難にし、実装の簡単な交換を許可しません。また、依存関係を明示しません（たとえば、データベースを使用するメソッドを呼び出すメソッドを呼び出すメソッドを呼び出すという事実を知らないメソッドを調べています）。 Dependecyインジェクションは、コンストラクター引数リストを大幅に膨張させ、コード全体にいくつかの側面を塗りつけます。典型的な状況は、半分以上のクラスのコンストラクターがこのように見える場合です(....., LoggingProvider l, DbSessionProvider db, ExceptionFactory d, UserSession sess, Descriptions d) 問題がある典型的な状況を次に示します。データベースからロードされたエラー記述を使用する例外クラスがあり、ユーザーセッションオブジェクトにあるユーザー言語設定のパラメーターを持つクエリを使用します。したがって、新しい例外を作成するには、データベースセッションとユーザーセッションを必要とする説明が必要です。したがって、例外をスローする必要がある場合に備えて、これらすべてのオブジェクトをすべてのメソッドにドラッグする運命にあります。 このような問題にどのように取り組むのですか？

81 design  dependency-injection  dependencies 

私はこれが熱い議論であることを知っており、意見はベストアプローチの実践に関して時間とともに変化する傾向があります。 コンストラクターインジェクションの利点についてさまざまなブログ（例：petrikainulainenとschauderhaftとfowler）を読み始めるまで、クラスではフィールドインジェクションのみを使用していました。それ以来、必要な依存関係にはコンストラクター注入を使用し、オプションの依存関係にはセッター注入を使用するように方法を切り替えました。 しかし、私は最近、モック作成フレームワークであるJMockitの作成者との議論に参加しました。彼は、コンストラクターとセッターの注入を悪い習慣と見なし、JEEコミュニティが彼に同意することを示しています。 今日の世界では、注射を行う好ましい方法はありますか？フィールドインジェクションは好ましいですか？ ここ数年フィールドインジェクションからコンストラクターインジェクションに切り替えたため、使用するのがはるかに明確になりましたが、自分の視点を再検討すべきかどうか疑問に思っています。JMockit（RogérioLiesenfeld）の著者はDIに精通しているため、コンストラクター/セッターインジェクションに対して非常に強く感じているので、私のアプローチを検討する義務があります。

62 java  dependency-injection  java-ee 

ここ数年、私たちは少しずつ一歩ずつ、より良い記述コードに徐々に切り替えてきました。私たちはついに、少なくともSOLIDに似たものへの切り替えを始めていますが、まだまだそこにはありません。切り替えを行って以来、開発者からの最大の不満の1つは、以前はすべてのタスクで開発者が5〜10個のファイルを操作するだけで十分だった数十個のファイルをピアレビューおよびトラバースできないことです。 切り替えを開始する前に、アーキテクチャは次のように編成されていました（1〜2桁以上のファイルが付与されています）。 Solution - Business -- AccountLogic -- DocumentLogic -- UsersLogic - Entities (Database entities) - Models (Domain Models) - Repositories -- AccountRepo -- DocumentRepo -- UserRepo - ViewModels -- AccountViewModel -- DocumentViewModel -- UserViewModel - UI ファイルに関しては、すべてが非常に線形でコンパクトでした。明らかにコードの重複、密結合、および頭痛の種がたくさんありましたが、誰もがそれを横断して理解することができました。完全な初心者、つまりVisual Studioを開いたことのない人は、わずか数週間でそれを理解できました。全体的なファイルの複雑さの欠如により、初心者の開発者や新規採用者も、あまり時間をかけずに貢献を始めることが比較的簡単になります。しかし、これはコードスタイルの利点が出てこないところです。 コードベースを改善するためのあらゆる試みを心から支持しますが、このような大規模なパラダイムシフトについて、チームの他のメンバーからプッシュバックを得るのは非常に一般的です。現在の最大のこだわりのポイントは次のとおりです。 単体テスト クラス数 ピアレビューの複雑さ ユニットテストは時間の無駄だと信じており、個々のコードよりも全体としてコードをはるかに迅速に処理テストできると信じているため、チームにとっては信じられないほど難しい販売でした。SOLIDの承認として単体テストを使用することはほとんど無益であり、この時点ではほとんど冗談になりました。 クラス数はおそらく克服すべき最大のハードルです。5〜10個のファイルを使用していたタスクは、70〜100個かかるようになりました。これらの各ファイルにはそれぞれ異なる目的がありますが、膨大な量のファイルが圧倒される場合があります。チームからの反応は、主にうめき声と頭を掻くものでした。以前は、タスクには1つまたは2つのリポジトリ、1つまたは2つのモデル、ロジックレイヤー、およびコントローラーメソッドが必要でした。 単純なファイル保存アプリケーションを構築するには、ファイルが既に存在するかどうかを確認するクラス、メタデータを書き込むクラスDateTime.Now、ユニットテストの時間を注入できるように抽象化するクラス、ロジックを含むすべてのファイルのインターフェイス、ファイルがあります各クラスの単体テストと、DIコンテナにすべてを追加するための1つ以上のファイルを格納します。 中小規模のアプリケーションの場合、SOLIDは非常に簡単に販売できます。誰もが保守性の利点と容易さを理解しています。ただし、非常に大規模なアプリケーションでは、SOLIDの価値提案が見られないだけです。だから私は、組織と管理を改善して、成長する痛みを乗り越える方法を見つけようとしています。 最近完了したタスクに基づいて、ファイルボリュームの例を少し強くしたいと思いました。ファイル同期要求を受信するために、新しいマイクロサービスのいずれかに機能を実装するタスクが与えられました。要求が受信されると、サービスは一連の検索とチェックを実行し、最終的にドキュメントをネットワークドライブと2つの個別のデータベーステーブルに保存します。 ドキュメントをネットワークドライブに保存するには、いくつかの特定のクラスが必要でした。 - …

50 c#  coding-style  dependency-injection  solid  single-responsibility 

（サービスロケーター）デザインパターンに関する記事を読みながら、コンストラクター注入と依存性注入という用語を見てきました。 コンストラクターインジェクションについてGoogleで検索した結果、結果が不明確だったため、ここでチェックインする必要がありました。 コンストラクター注入とは何ですか？これは特定の種類の依存性注入ですか？規範的な例は大きな助けになるでしょう！ 編集 1週間のギャップの後にこの質問を再訪すると、私がどれほど失われたかを見ることができます。コメント/修正してください。 コンストラクター注入とプロパティ注入は、依存性注入の2つのタイプです。

47 c#  dependency-injection 

私の同僚は、「ロギング/キャッシングなどが横断的な関心事である」と言ってから、対応するシングルトンをどこでも使用して進めます。それでも、彼らはIoCとDIが大好きです。 SOLI Dの原則を破ることは本当に正当な言い訳ですか？

43 dependency-injection  solid  anti-patterns  singleton 

現在、SOLIDを把握しようとしています。したがって、依存関係反転の原則は、任意の2つのクラスが直接ではなく、インターフェースを介して通信することを意味します。例：class Aメソッドがあり、typeのオブジェクトへのポインターを予期するclass B場合、このメソッドは実際にtypeのオブジェクトを予期する必要がありますabstract base class of B。これは、オープン/クローズにも役立ちます。 私が正しく理解していれば、私の質問は、これをすべてのクラスの相互作用に適用するのが良い習慣であるか、レイヤーの観点から考えてみるべきですか？ 私が懐疑的である理由は、この原則に従うためにいくらかの代価を払っているからです。たとえば、featureを実装する必要がありますZ。分析後Z、機能はA、Bおよびで構成されていると結論付けCます。私が作成ファサードクラスはZ、それは、インタフェースを介して、クラスを使用していますA、BとC。私は実装をコーディングを開始し、いくつかの点で私は、そのタスクを実現するZ実際の機能で構成されA、BそしてD。次に、Cインターフェイス、Cクラスプロトタイプを破棄し、Dインターフェイスとクラスを個別に記述する必要があります。インターフェイスがなければ、クラスのみを置き換える必要があります。 つまり、何かを変更するには、1。呼び出し元2.インターフェイス3.宣言4.実装を変更する必要があります。Python直接結合実装では、実装のみを変更する必要があります。

43 design  dependency-injection  solid