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

依存関係の注入にUnityをC＃で使用していますが、この質問は、依存関係の注入を使用しているすべての言語とフレームワークに適用できます。 私はSOLID原理に従うようにしているので、多くの抽象化を得ました。しかし今、私は、1つのクラスが何回の注入を注入すべきかについてのベストプラクティスがあるかどうか疑問に思っていますか？ たとえば、9つの注入があるリポジトリがあります。これは他の開発者にとって読みにくいでしょうか？ 注射には次の責任があります。 IDbContextFactory-データベースのコンテキストを作成します。 IMapper-エンティティからドメインモデルへのマッピング。 IClock-DateTime.Nowを抽象化して、単体テストを支援します。 IPerformanceFactory-特定のメソッドの実行時間を測定します。 ILog-ロギング用のLog4net。 ICollectionWrapperFactory-コレクションを作成します（IEnumerableを拡張します）。 IQueryFilterFactory-dbをクエリする入力に基づいてクエリを生成します。 IIdentityHelper-ログインしたユーザーを取得します。 IFaultFactory-異なるFaultExceptionsを作成します（私はWCFを使用しています）。 私が責任を委任した方法に本当にがっかりしているわけではありませんが、読みやすさが気になり始めています。 だから、私の質問： クラスに必要な注射の回数に制限はありますか？もしそうなら、それを避ける方法は？ 多くの注入は読みやすさを制限しますか、それとも実際にそれを改善しますか？

9 dependency-injection 

多くの「アンチパターン」シングルトンを備えた大規模なコードベース、静的メソッドを含むユーティリティクラス、およびnewキーワードを使用して独自の依存関係を作成するクラスがあります。コードのテストが非常に困難になります。 依存性注入コンテナ（プロジェクトのGuice場合はGWT）にコードを徐々に移行したいと考えています。依存性注入についての私の理解から、それは全部かゼロかです。すべてのクラスは、Spring / Guiceによって管理されるか、まったく管理されません。コードベースが大きいので、コードを一晩で変換できません。ですから、徐々にそれを行う方法が必要です。 問題は、他のクラスに注入する必要のあるクラスから始めると、@Injectそれらのクラスがまだコンテナーによって管理されていないため、それらのクラスでシンプルを使用できないことです。したがって、これはどこにも挿入されない「トップ」クラスまでの長いチェーンを作成します。 私が見る唯一の方法は、Injector/アプリケーションコンテキストをシングルトンを通じてグローバルに利用できるようにすることです。これにより、他のクラスがそこからマネージドBeanを取得できるようになります。しかし、それcomposition rootはアプリケーションに明らかにしないという重要な考えと矛盾します。 もう1つのアプローチはボトムアップです。「高レベル」クラスから始めて、依存関係注入コンテナーにそれらを含め、ゆっくりと「小さい」クラスに移動します。しかし、まだグローバル/スタティックに依存しているこれらの小さなクラスをテストできるので、私は長い間待たなければなりません。 このような段階的な移行を実現する方法は何でしょうか？ PS 依存性注入への段階的アプローチという質問はタイトルは似ていますが、私の質問には答えません。

9 dependency-injection  spring  google-guice 

簡単な質問：C＃でのシリアル化にはデフォルトのコンストラクターが必要であることを理解しています。これは、コンストラクターで注入されたDIを使用する可能性を排除します（これは、私の読みでは、一般的に好ましいスタイルのDI です[引用が必要]）。それは本当にどちらか一方の状況ですか、それとも何か不足していますか？ （サイド質問）：IoCコンテナーはこのトレードオフをどうにかして回避しますか？

9 dependency-injection  serialization 

今週は、依存関係注入のためにTyphoonフレームワークを使用することを検討してきました。オブジェクトの構造を分離することは、単体テスト中に任意のコンポーネントをモックに置き換えるのに有益であることがわかりました。 しかし、何十ものヘッダーがインポートされた巨大なビューコントローラークラスがあった前に、何十ものヘッダーがインポートされた巨大なファクトリークラスができたと考えざるを得ません。大規模なファクトリークラスを避けるべきですか？

9 dependency-injection 

私はコードをテスト可能な状態に保ち、現在のMVCフレームワークの依存性注入戦略を採用することを決定しました。 しかし、デザインパターンのマスターとはほど遠いので、モデルをデータベースコネクタクラスから可能な限り疎結合に保つための適切な方法を理解するのに苦労しています。 これはどのように行うことができますか？ この質問では物理的なコードを提供していなかったので、上記の問題を理解する方向に私を導くことができるいくつかのロジック/コードの例または情報に本当に感謝します。

9 object-oriented  php  dependency-injection 

私は依存性注入について学んでいます。関数型ライブラリを作成するときにその魅力を見ることができますが、ライブラリを使用する人にもなると、それがどのように解決するのかわかりません。 テストするものがあまりないので、ライブラリのテストがはるかに簡単になります。 しかし、最終的には、ライブラリを使用するときに注入された関数をテストし、標準ライブラリの関数のモックとスタブを処理する必要があります。 これは、Node.jsで扱っている具体的なケースです。 function compile(options) { var files = options.files; var texCompiler = options.texCompiler; var pdfMerger = options.pdfMerger; return Promise.all(files.map(texCompiler(files))) .then(pdfMerger); } 注入：それはテストに簡単ですモックオブジェクトとして、あるいはスパイをtexCompilerし、pdfMerger機能が本当にすべてではあまり行っていないので、ケーキの一部です。私がテストできるのは、両方の関数が正しい順序で呼び出されることだけです。 とはいえ、最終的には私の関数texCompilerやpdfMerger関数をテストする必要はありません。彼らはそのようなものに見えます： var tex2Pdf = Promise.method(function tex2Pdf(tex_doc) { var latex_command = 'pdflatex'; var pdf_output_filename = path.parse(tex_doc).name + '.pdf'; var cmd = latex_command + ' ' + tex_doc; …

9 design-patterns  javascript  unit-testing  dependency-injection 

休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか？質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 10か月前に閉鎖。 依存性注入（DI）の概念を確実に理解したいと思います。まあ、私は実際にコンセプトを理解しています。DIは複雑ではありません。インターフェイスを作成し、それを使用するクラスにインターフェイスの実装を渡します。これを渡す一般的な方法はコンストラクターですが、セッターやその他のメソッドで渡すこともできます。 DIをいつ使用するかがよくわかりません。 使用法1：もちろん、インターフェースの実装が複数ある場合にDIを使用するのは論理的であるようです。SQL Serverのリポジトリがあり、次にOracleデータベースのリポジトリがあります。どちらも同じインターフェースを共有し、実行時に必要なインターフェースを「挿入」します（これが使用される用語です）。これはDIではありません。ここでは基本的なOOプログラミングです。 使用法2：特定のメソッドをすべて持つ多くのサービスを持つビジネスレイヤーがある場合、各サービスのインターフェイスを作成し、これが一意であっても実装を注入することをお勧めします。これはメンテナンスに適しているからです。これは私が理解できないこの2番目の使用法です。 私は50のビジネスクラスのようなものを持っています。それらの間で共通するものはありません。いくつかは、3つの異なるデータベースでデータを取得または保存するリポジトリです。一部のファイルの読み取りまたは書き込み。一部は純粋なビジネスアクションを行います。特定のバリデーターとヘルパーもあります。一部のクラスは異なる場所からインスタンス化されるため、課題はメモリ管理です。バリデーターは、いくつかのリポジトリーや、同じリポジトリーを再度呼び出すことができる他のバリデーターを呼び出すことができます。 例：ビジネスレイヤー public class SiteService : Service, ICrud<Site> { public Site Read(Item item, Site site) { return beper4DbContext.Site .AsNoTracking() .SingleOrDefault(y => y.SiteId == site.Id && y.ItemId == item.Id) } public Site Read(string itemCode, string siteCode) { using (var itemService = new ItemService()) …

8 c#  dependency-injection 

タイトルを少し拡張するために、他の関数またはクラスが依存する純粋な関数を明示的に宣言する（つまり注入する）必要があるかどうかについて、結論を出そうとしています。 それらが要求せずに純粋な関数を使用する場合、テスト可能性が低く、設計が悪い特定のコードはありますか？私は単純なものから純粋な機能の任意の種類のために、問題の結論に取得したいと思い、ネイティブ関数（例えばmax()、min()-言語に関係なく）今度は他の純粋な機能に暗黙的に依存してもよいことを習慣に、より複雑なもの。 通常の懸念は、一部のコードが依存関係を直接使用するだけの場合、それを単独でテストすることができない、つまり、あなたが黙って持ってきたものすべてを同時にテストすることです。しかし、これは、小さな関数ごとに実行する必要がある場合、かなりのボイラープレートを追加するので、これがまだ純粋な関数に当てはまるかどうか、なぜか、またはなぜそうでないのかと思います。

8 unit-testing  dependency-injection  pure-function 

シングルトンパターンとそれがどのように「悪い」のかについては、クラスをテストするのが難しくなるので避けてきました。シングルトンを依存性注入に置き換える方法を説明した記事をいくつか読んだことがありますが、それは不必要に複雑に思えます。 これがもう少し詳しく私の問題です。私はReact Nativeを使用してモバイルアプリを構築しています。サーバーと通信し、データを取得し、データを投稿し、ログインを処理するRESTクライアントを作成します（ログイントークンを保存し、ログイン後にリクエストごとに送信します）。 私の最初の計画は、アプリが最初にログインに使用し、必要に応じて資格情報の送信を要求するシングルトンオブジェクト（RESTClient）を作成することでした。DIのアプローチは本当に複雑に思えます（おそらくDIを使用したことがないためです）が、このプロジェクトを最大限に活用して、ここで最善を尽くしたいと思います。提案やコメントは大歓迎です。 編集：私は今、自分の質問の言葉遣いが不十分であることに気づきました。RNでシングルトンパターンを回避する方法についてのガイダンスが必要でした。幸運にも、サミュエルは私が望んでいたような答えをくれました。私の問題は、シングルトンパターンを避けてDIを使用したかったのですが、React Nativeで実装するのは本当に複雑に思えました。さらに調査を行い、Reactsコンテキストシステムを使用して実装しました。 ここに興味のある人のために、私はそれをしました。私が言ったように、私はプロップのようなものであるRNのコンテキストを使用しましたが、それはすべてのコンポーネントに伝搬されます。 ルートコンポーネントでは、次のような必要な依存関係を提供します。 export default class Root extends Component { getChildContext() { restClient: new MyRestClient(); } render() {...} } Root.childContextTypes = {restClient: PropTypes.object}; これで、restClientは、ルートの下のすべてのコンポーネントで使用できます。このようにアクセスできます。 export default class Child extends Component { useRestClient() { this.context.restClient.getData(...); } render() {...} } Child.contextTypes = {restClient: PropTypes.object} これにより、オブジェクトの作成がロジックから効果的に離れ、RESTクライアントの実装がコンポーネントから切り離されます。

8 design-patterns  architecture  dependency-injection  singleton  react 

この質問は数日間私を悩ませてきました、そしてそれはいくつかの実践が互いに矛盾しているように感じます。 例 反復1 public class FooDao : IFooDao { private IFooConnection fooConnection; private IBarConnection barConnection; public FooDao(IFooConnection fooConnection, IBarConnection barConnection) { this.fooConnection = fooConnection; this.barConnection = barConnection; } public Foo GetFoo(int id) { Foo foo = fooConection.get(id); Bar bar = barConnection.get(foo); foo.bar = bar; return foo; } } これをテストするとき、IFooConnectionとIBarConnectionを偽造し、FooDaoをインスタンス化するときに依存性注入（DI）を使用します。 機能を変更せずに実装を変更できます。 …

8 c#  unit-testing  api-design  dependency-injection  solid 

非常に最近の質問に対する現在最も支持されている回答は、 DIコンテナーは「エンタープライズソフトウェア」パターンであり、オブジェクトグラフが非常に大きく複雑な場合に使用されます。アプリケーションの95％はそれを必要としないと思います。 これは私が強く反対することです。多分私は間違った用語を持っているかもしれませんが、私にとってDIフレームワークは単に「オブジェクトを一緒に配線する何か」を意味します。何か不足していますか？ 非常に小さなプロジェクト（10クラスなど）でも、それらを簡略化するためにGuiceを使用しています。確かに、400 kBのJARファイルですが、これは私が気にすることではありません。小規模なプロジェクトの場合、設定はほとんど必要なく、唯一の「オーバーヘッド」は注釈の追加です。@Inject それで、私は本当に不思議に思います、DIフレームワークはどんな追加された複雑さを引き起こしますか？ 回答への対応を更新 82クラスのプロジェクトでは、 32 @Inject注釈 15 @Singletonと1の@ProvidedBy注釈 4プロバイダー（これらはすべて私の工場であるため、DIなしでも必要です） 1つの行を含むモジュール 0行XML !!! それで全部です。確かに、それは小さなプロジェクトですが、まさにこれが私のポイントでした。追加の作業は、行ではなく数語でした。 不変の「使いやすい」オブジェクトを取得するために、コンストラクター注入のみを使用しています。新しい依存関係が出現するたびに、最終フィールドを追加し、LombokのRequiredArgsConstructorが宣言を処理するようにし、Guiceがそれを適切に呼び出すようにします。

8 java  frameworks  dependency-injection  google-guice 

依存性注入で遊んでいますが、正しく実行されているかどうかはわかりません。特に、依存関係が注入されたクラスを構築するための正しい方法が何かはわかりません。 クラスBを作成するクラスAがあるとします。クラスBはクラスCに依存し、クラスCはクラスDに依存します。クラスDの作成を担当するのは誰ですか？ クラスAの場合もあります。ただし、大規模なシステムでは、クラスAが非常に多数のオブジェクトを作成してアセンブルする場合があります。 D、C、Bを作成する個別のビルダークラス。Aはこのビルダークラスを使用します。 その他のオプション。 また、DIコンテナーについてもよく読みました。ただし、C ++には主要なフレームワークがないようです。また、私が正しく理解すれば、コンテナーがなくてもDIはうまく実行できます。私は正しいですか？

8 design  c++  object-oriented  dependency-injection 

これが私のコードの仕組みです。サードパーティのショッピングAPIに保存されている、ショッピングカートの注文に似たものの現在の状態を表すオブジェクトがあります。私のコントローラーコードで、私は呼び出すことができるようにしたいです： myOrder.updateQuantity(2); 実際に、第三者にメッセージを送信するためには、第三者にも同様THISために固有のいくつかのことを、知っている必要がありorderID、かつloginID、アプリケーションの存続期間中に変化しないであろう。 私が作成したときにmyOrder、もともと、私は注射MessageFactory知っています、loginID。次に、updateQuantityが呼び出されると、Orderパスがを通過しorderIDます。制御コードは簡単に記述できます。別のスレッドがコールバックを処理し、Order変更が成功した場合は更新Orderし、変更が失敗した場合は変更が失敗したことを通知します。 問題はテストです。のでOrder、オブジェクトが依存するMessageFactory、それが必要MessageFactory実際返すようにMessageSを（それが呼び出すこと.setOrderID()例えば、上）、今私は非常に複雑に設定する必要がMessageFactoryモックを。さらに、「モックがモックを返すたびに妖精が死ぬ」ので、私は妖精を殺したくありません。 コントローラーのコードを単純に保ちながら、この問題を解決するにはどうすればよいですか？私はこの質問を読みました：https : //stackoverflow.com/questions/791940/law-of-demeter-on-factory-pattern-and-dependency-injectionしかし、それはテストの問題について話していなかったので助けにはなりませんでした。 私が考えたいくつかの解決策： どういうわけか、ファクトリメソッドが実際のオブジェクトを返す必要がないようにコードをリファクタリングします。おそらく、それは工場ではなく、MessageSender？ のテスト専用実装を作成しMessageFactory、それを注入します。 コードはかなり複雑です。sscceでの私の試みは次のとおりです。 public class Order implements UpdateHandler { private final MessageFactory factory; private final MessageLayer layer; private OrderData data; // Package private constructor, this should only be called by the OrderBuilder object. Order(OrderBuilder builder, OrderData initial) { this.factory = builder.getFactory(); …

8 java  unit-testing  dependency-injection 

Mark Seemannの 'Ploeh'ブログを含むいくつかのソースで、IoCコンテナーのコンポジションルートの適切な配置がアプリケーションのエントリポイントに可能な限り近いことについて読んだことがあります。 .NETの世界では、これらのアプリケーションは、一般的にWebプロジェクト、WPFプロジェクト、コンソールアプリケーション、一般的なUIを持つもの（読み取り：ライブラリプロジェクトではない）と考えられているようです。 構成ルートをライブラリプロジェクトのグループの論理的なエントリポイントを表し、このようなプロジェクトグループのクライアントが他の誰かの作業である場合、構成ルートをライブラリプロジェクトのエントリポイントに配置することは、この賢明なアドバイスに本当に反していますか？ 、その作者が自分のプロジェクト（UIプロジェクトまたはさらに別のライブラリプロジェクトでさえ）にコンポジションルートを追加できない、または追加しないだろう？ 私はIoCコンテナー実装としてNinjectに精通していますが、必要なすべてのバインディング構成を含むモジュールをスキャンできるという点で、他の多くも同じように機能すると思います。これは、バインディングモジュールを独自のライブラリプロジェクトに配置して、メインライブラリプロジェクトの出力でコンパイルできることを意味します。クライアントが構成を変更したい場合（私のケースではありえないシナリオ）、置換DLLをドロップして、バインディングモジュールを含むライブラリ。 これにより、最も一般的なクライアントが依存関係の注入とコンポジションのルートを処理する必要がなくなり、ライブラリプロジェクトグループのAPIが最もクリーンになります。 しかし、これはこの問題に関する従来の知恵に直面して飛んでいるようです。そこにあるほとんどのアドバイスは、開発者が自分のケースではなく、UIプロジェクトの開発にも何らかの調整を行っていることを前提としているだけですか？

8 design-patterns  .net  dependency-injection  architectural-patterns  ioc-containers 

私はさまざまな言語でまともな量のOOPを使用していますが、Javaはかなり新しいものです。 私はクラスのコード内に多数のオブジェクトが作成される多くのチュートリアルを読んでいますが、それらを実行しようとしていますが、チュートリアルでクラスのバージョンを構築します。クラス自体。 しかし、Javaは私が使用した他の言語とは異なり、ほとんどすべてがオブジェクトです。文字通りすべてを注入すると、結果は非常に複雑で追跡が困難になります。 明らかに、あなたはStringオブジェクトをインジェクトしないでしょう、そしてインジェクトしない他のオブジェクトがあると思いますが、行がどこに行くべきかわかりません。どの時点で、DIは正しいことをやめ、いつ負荷がかかり始めるのでしょうか？何を注入し、何をインスタンス化するかを実用的にどのように決定しますか？ 参考までに、私が実行しているチュートリアルは、単純なクライアントを構築するためのhttp://edn.embarcadero.com/article/31995およびhttp://docs.oracle.com/javase/tutorial/networking/sockets/clientServer.htmlです。サーバ。私はそれらを行ごとにコピーしていませんが、ベストプラクティスに従う同等のクラスを作成しようとしています

8 java  object-oriented  dependency-injection