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

タイトルには「Circular Dependency」と書かれていますが、それは正しい表現ではありません。私にはデザインがしっかりしているように見えるからです。 ただし、次のシナリオを検討してください。青い部分は外部パートナーから提供され、オレンジは私自身の実装です。またConcreteMain、複数あると仮定しますが、特定のものを使用したいと思います。（実際には、各クラスにはさらにいくつかの依存関係がありますが、ここでは単純化しようとしました） すべてをDepency Injection（Unity）でStackOverflowExceptionインスタンス化したいのですが、明らかに次のコードを取得します。これは、RunnerがConcreteMainのインスタンス化を試行し、ConcreteMainにはRunnerが必要だからです。 IUnityContainer ioc = new UnityContainer(); ioc.RegisterType<IMain, ConcreteMain>() .RegisterType<IMainCallback, Runner>(); var runner = ioc.Resolve<Runner>(); どうすればこれを回避できますか？これをDIで使用できるように構成する方法はありますか？私が今しているシナリオは、すべてを手動で設定することですが、ConcreteMainそれをインスタンス化するクラスに強い依存関係を置きます。これは私が回避しようとしているものです（構成にUnityの登録がある場合）。 以下のすべてのソースコード（非常に単純化された例！）; public class Program { public static void Main(string[] args) { IUnityContainer ioc = new UnityContainer(); ioc.RegisterType<IMain, ConcreteMain>() .RegisterType<IMainCallback, Runner>(); var runner = ioc.Resolve<Runner>(); Console.WriteLine("invoking runner..."); runner.DoSomethingAwesome(); Console.ReadLine(); } } public …

15 architecture  dependency-injection  architectural-patterns 

インジェクションを受け入れるのではなく、依存関係を直接構築するクライアントが1001人いるとします。上司によると、1001のリファクタリングはオプションではありません。実際には、ソースへのアクセスさえ許可されていません。クラスファイルだけです。 私たちがやるべきことは、これらの1001クライアントが通過するシステムを「近代化」することです。好きなことをリファクタリングできます。依存関係はそのシステムの一部です。そして、それらの依存関係のいくつかは、新しい実装を行うために変更することになっています。 私たちがやりたいことは、この多数のクライアントを満たすために、依存関係の異なる実装を構成する機能を持っていることです。悲しいことに、クライアントはコンストラクターまたはセッターによるインジェクションを受け入れないため、DIはオプションのようには見えません。 オプション： 1）クライアントが使用するサービスの実装をリファクタリングして、クライアントが現在必要としていることを行うようにします。完了です。柔軟ではありません。複雑ではありません。 2）実装をリファクタリングして、ファクトリを通じて取得したさらに別の依存関係に作業を委任します。これで、ファクトリをリファクタリングすることで、すべてが使用する実装を制御できます。 3）実装をリファクタリングして、作業をサービスロケーターを介して取得したさらに別の依存関係に委任します。これhashmapで、少しのキャストが行われたオブジェクトへの文字列である可能性のあるサービスロケーターを構成することで、すべてが使用する実装を制御できます。 4）まだ考えていないこと。 目的： 設計が不十分な古いクライアントコードを無意味な複雑さを加えることなく未来にドラッグすることによって引き起こされる設計の損傷を最小限に抑えます。 クライアントは依存関係の実装を知っていないか制御するべきではありませんが、で構築することを主張しますnew。制御することはできませんnewが、構築しているクラスを制御します。 私の質問： 何を考慮しなかったのですか？ Doc Brownからの質問 異なる実装間で構成する可能性が本当に必要ですか？何のために？ 機敏。未知の多く。経営陣は変化の可能性を望んでいます。外の世界への依存を失うだけです。またテスト。 実行時の仕組みが必要ですか、それとも異なる実装を切り替えるためにコンパイル時の仕組みが必要ですか？どうして？ コンパイルの時間の仕組みで十分です。テストを除く。 どの粒度で実装を切り替える必要がありますか？一斉に？モジュールごと（それぞれがクラスのグループを含む）？クラスごと？ 1001のうち、一度に実行されるのは1つだけです。すべてのクライアントが一度に使用するものを変更しても問題はないでしょう。ただし、依存関係を個別に制御することはおそらく重要です。 誰がスイッチを制御する必要がありますか？あなた/あなたの開発者チームのみ？管理者ですか？各クライアントは自分で？または、クライアントのコードのメンテナンス開発者ですか？それでは、メカニックはどれほど簡単/堅牢/完全に機能する必要があるのでしょうか？ テスト用の開発。外部ハードウェアの依存関係が変化するため、管理者。テストと構成が簡単である必要があります。 私たちの目標は、システムを迅速に作り直し、近代化できることを示すことです。 実装スイッチの実際の使用例 1つは、ハードウェアソリューションの準備が整うまで、一部のデータがソフトウェアによって提供されることです。

14 design  refactoring  dependency-injection  factory-method  service-locator 

テスト駆動開発（TDD）、依存性注入（DI）、および制御の反転（IoC）をすべて同時に行うことを学びました。TDDを使用してコードを記述するとき、クラスのコンストラクターで常にDIを使用します。これは、TDDをどのように学んだかによるものなのか、それともTDDの自然な副作用なのか疑問に思っています。 だから私の質問は次のとおりです：TDDプリンシパルに従って、外部サービスに依存しない単体テストを書くことは必然的にDIにつながりますか？

14 tdd  dependency-injection  inversion-of-control 

過去1年で、Dependency InjectionとIOCコンテナを使用して新しいシステムを作成しました。これは私にDIについて多くを教えてくれました！ ただし、概念と適切なパターンを学んだ後でも、コードを分離し、IOCコンテナーをレガシーアプリケーションに導入することは難しいと考えています。アプリケーションは、真の実装が圧倒されるほどの大きさです。値が理解され、時間が与えられたとしても。こんなことをする時間を与えられたのは誰ですか?? もちろん、単体テストをビジネスロジックに組み込むことが目標です！ テスト防止のデータベース呼び出しと絡み合っているビジネスロジック。 この記事を読みましたが、このLos Techiesの記事で説明されているように、Poor Man's Dependency Injectionの危険性を理解しています。私はそれが本当に何も切り離さないことを理解しています。 実装には新しい依存関係が必要になるため、システム全体で多くのリファクタリングが必要になることを理解しています。どんなサイズの新しいプロジェクトでも使用することは考えません。 質問： Poor ManのDIを使用して、レガシーアプリケーションにテスト容易性を導入し、ボールローリングを開始しても大丈夫ですか？ さらに、Poor ManのDIを真のDependency Injectionへの草の根アプローチとして使用することは、原則の必要性と利点を教育する価値のある方法ですか？ インターフェイスの背後でデータベース呼び出しの依存関係と抽象化を呼び出すメソッドをリファクタリングできますか？単純に抽象化することで、そのメソッドをテスト可能にします。これは、コンストラクターのオーバーロードを介してモック実装を渡すことができるためです。 今後、支援が得られると、プロジェクトを更新してIOCコンテナを実装し、抽象化を取り入れるコンストラクタを公開することができます。

14 architecture  dependency-injection  legacy  inversion-of-control 

というインターフェイスがありますIContext。この目的のために、以下を除いて、実際に何をするかは重要ではありません。 T GetService<T>(); このメソッドが行うことは、アプリケーションの現在のDIコンテナを調べ、依存関係を解決しようとすることです。かなり標準だと思います。 ASP.NET MVCアプリケーションでは、コンストラクターは次のようになります。 protected MyControllerBase(IContext ctx) { TheContext = ctx; SomeService = ctx.GetService<ISomeService>(); AnotherService = ctx.GetService<IAnotherService>(); } そのため、各サービスのコンストラクターに複数のパラメーターを追加するのではなく（アプリケーションを拡張する開発者にとってこれは非常に面倒で時間がかかるため）、このメソッドを使用してサービスを取得しています。 今、それは間違っていると感じています。しかし、私が現在頭の中でそれを正当化している方法はこれです- 私はそれをあざけることができます。 できます。IContextControllerをテストするためにモックアップすることは難しくありません。とにかくする必要があります： public class MyMockContext : IContext { public T GetService<T>() { if (typeof(T) == typeof(ISomeService)) { // return another mock, or concrete etc etc } // etc …

13 c#  unit-testing  asp.net-mvc  dependency-injection 

依存性注入を使用するように既存のシステムをリファクタリングしており、その作業は順調に進んでいます。 しばらくして、社内ライブラリの多くが、使用しているDIフレームワークに依存するようになったことに気付きました。その結果、プロジェクト全体がこのサードパーティフレームワークに依存するようになりました。 共有ライブラリに依存させることで、すべての依存関係を分離することに皮肉を感じました。 私の最初の反応は、依存関係フレームワークのラッパーライブラリを作成することでした。したがって、必要に応じてこのフレームワークを置き換えることができます。関連する作業を推定した後、結果のAPIは既存のフレームワークに似ているため、置き換えがより困難になることに気付きました。だから私はその考えを捨てました。 私の懸念は、使用しているDIフレームワークが時代遅れになるか、交換する必要があることです。 DIを操作するときに、プロジェクトとDIフレームワーク間の結合を減らす開発パターンがありますか？

13 frameworks  dependency-injection 

Google Guiceのような依存性注入フレームワークは、その使用（ソース）に次の動機を与えます。 オブジェクトを構築するには、まずその依存関係を構築します。しかし、各依存関係を構築するには、その依存関係などが必要です。したがって、オブジェクトを作成するときは、オブジェクトグラフを作成する必要があります。 手作業でオブジェクトグラフを作成するのは手間がかかり（...）、テストが困難になります。 しかし、私はこの議論を買いません。依存性注入フレームワークがなくても、インスタンス化が簡単で、テストが便利なクラスを作成できます。たとえば、Guiceの動機付けページの例を次のように書き換えることができます。 class BillingService { private final CreditCardProcessor processor; private final TransactionLog transactionLog; // constructor for tests, taking all collaborators as parameters BillingService(CreditCardProcessor processor, TransactionLog transactionLog) { this.processor = processor; this.transactionLog = transactionLog; } // constructor for production, calling the (productive) constructors of the collaborators public BillingService() …

13 design-patterns  object-oriented  dependency-injection  ioc-containers 

MVVMパターンを使用してWPFアプリケーションを構築しています。現在、私のビューモデルは、サービスレイヤーを呼び出してモデルを取得し（ビューモデルとは無関係です）、モデルをビューモデルに変換します。コンストラクター注入を使用して、必要なサービスをビューモデルに渡します。 簡単にテストでき、依存関係の少ないビューモデルでうまく機能しますが、複雑なモデルのviewModelを作成しようとするとすぐに、多くのサービスが挿入されたコンストラクターがあります（各依存関係と使用可能なすべての値のリストを取得するためのもの）たとえば、itemsSourceにバインドします）。そのような複数のサービスをどのように処理し、簡単にユニットテストできるビューモデルがまだあるのか疑問に思っています。 私はいくつかの解決策を考えています： 使用可能なすべてのサービスをインターフェイスとして含むサービスシングルトン（IServices）を作成します。例：Services.Current.XXXService.Retrieve（）、Services.Current.YYYService.Retrieve（）。そうすれば、大量のサービスパラメータを含む巨大なコンストラクタはありません。 viewModelによって使用されるサービスのファサードを作成し、このオブジェクトを私のviewmodelのctorに渡します。しかし、その後、複雑なビューモデルごとにファサードを作成する必要があります。 この種のアーキテクチャを実装する「正しい」方法は何だと思いますか？

13 architecture  dependency-injection  mvvm 

私はPHPアプリケーションをリファクタリングしていますが、可能な限り多くの依存性注入（DI）をしようとしています。 私はそれがどのように機能するかをよく理解しているように感じますし、クラスがかなりスリムで堅牢になっているのを確かに見ることができます。 クラス内に新しいオブジェクトを作成するのではなく依存関係を注入できるようにリファクタリングしていますが、ある時点でいくつかのオブジェクトを作成する必要があります。つまり、dreaded newキーワードを使用します。 私が今直面している問題は、どの時点で実際に新しいオブジェクトを作成できるかということです。私は最終的にトップレベルのクラスになり、他に行く場所がないため、新しいオブジェクトを大量に作成するように見えます。これは間違っているように感じます。 ファクトリクラスを使用してすべてのオブジェクトを作成するブログを読んだ後、ファクトリを他のクラスに注入します。その後、ファクトリメソッドを呼び出すと、ファクトリが新しいオブジェクトを作成します。 これを行うことに対する私の懸念は、今では私のファクトリークラスがnewすべて自由になることです！ファクトリクラスであるため、これで問題ないかもしれませんが、ファクトリパターンとDIを使用する場合に固執するいくつかのルールはありますか、それともここから外れますか？

13 php  dependency-injection 

まず、私は初心者レベルのプログラマーです。実際、私は夏の最後の絶頂プロジェクトでASの学位を取得しています。私の新しい仕事では、私がやるべきプロジェクトがないとき（彼らはチームにさらに新しい採用をするのを待っています）、私は待っている間に読んで学ぶための本を与えられました-いくつかの教科書、他のそれほど多くはありません（コード完了など）。これらの本を読んだ後、できる限り多くのことを学ぶためにインターネットに目を向け、SOLIDとDIについて学び始めました（Liskovの代替原理についてはいくらか話しましたが、SOLIDのアイデアについてはあまり話しませんでした）。それで、私が学んだように、私はよりよく学ぶために座って、DIを手動で利用するためのコードを書き始めました（開発コンピューターにはDIフレームワークはありません）。 私がやっているように、それは馴染みのあることに気づきます...そして、ポリモーフィズムを使った抽象クラスの構成を使って過去にやった仕事に非常に似ているようです。ここに大きな画像がありませんか？DIについて（少なくとも手で）それを超える何かがありますか？再コンパイルすることなく物事を変更する限り、いくつかの大きな利点を持つDIフレームワークのコードに設定がない可能性を理解していますが、手動で行う場合、上記と異なるかどうかはわかりません...これに関するいくつかの洞察は非常に役立つでしょう！

13 dependency-injection  abstraction  polymorphism  composition 

これは、純粋に技術的な質問というよりも、命名法（技術文書）です。私は、アプリケーションでの依存性注入の拡大を中心に、リファクタリングの提案を書いています（そして、それを自分に割り当てます）。Beanの自動配線にSpringを使用していますがMyClass obj = new MyClass(...)、を使用してBeanをインスタンス化するインスタンスがまだあります。私の提案では、エレガントな命名法を使用し、適切な用語でDIの反対のデザインパターンを参照したいと思います。 「密結合」は、DIの反意語として適切な用語ですか？

12 terminology  refactoring  dependency-injection 

依存性注入は初めてなので、アプリケーションでどのスタイルを使用すべきかについていくつか質問があります。Martin FowlerによるInversion of Control ContainersとDependency Injectionパターンを読んだばかりですが、コンストラクター、セッター、インターフェースインジェクションの実際の違いを理解することはできません。 どちらか一方を使用する理由は、コードのクリーニングおよび/または明快さの問題だけであるように思えます。違いはなんですか？あるものを他のものよりも使用することの強力な長所または短所はありますか、それとも前に述べたとおりですか？ 私の意見では、コンストラクター注入はすべての中で最も直感的であり、インターフェース注入は最も少ないです。一方、セッターインジェクションは中期ですが、最初にインジェクトした依存関係オブジェクトのインスタンスを変更できるはずですか？このスタイルの注入は、依存関係を必要とするオブジェクトが常に注入されることを保証しますか？私はそうは思わないが、私が間違っているなら私を修正してください。

12 design-patterns  dependency-injection  inversion-of-control 

現在、データアクセス戦略としてEntity Framework 5（.net 4）を使用しているn層ソリューションを設計していますが、依存性注入を組み込んでテスト可能/柔軟にする方法を検討しています。 私の現在のソリューションレイアウトは次のとおりです（私のソリューションはAlcatrazと呼ばれます）。 Alcatraz.WebUI：asp.net webformプロジェクト、フロントエンドユーザーインターフェイスは、プロジェクトAlcatraz.BusinessおよびAlcatraz.Data.Modelsを参照します。 Alcatraz.Business：クラスライブラリプロジェクト。ビジネスロジックを含み、プロジェクトAlcatraz.Data.Access、Alcatraz.Data.Modelsを参照します。 Alcatraz.Data.Access：クラスライブラリプロジェクトは、AlcatrazModel.edmxとAlcatrazEntitiesDbContextを収容し、プロジェクトAlcatraz.Data.Modelsを参照します。 Alcatraz.Data.Models：クラスライブラリプロジェクト。AlcatrazモデルのPOCOを含み、参照はありません。 このソリューションがどのように機能するかについての私のビジョンは、web-uiがビジネスライブラリ内のリポジトリをインスタンス化することです。このリポジトリは（コンストラクタを介して）接続文字列（AlcatrazEntitiesインスタンスではなく）の依存関係を持ちます。web-uiはデータベース接続文字列を知っていますが、それがエンティティフレームワーク接続文字列であることはわかりません。 ビジネスプロジェクトで： public class InmateRepository : IInmateRepository { private string _connectionString; public InmateRepository(string connectionString) { if (connectionString == null) { throw new ArgumentNullException("connectionString"); } EntityConnectionStringBuilder connectionBuilder = new EntityConnectionStringBuilder(); connectionBuilder.Metadata = "res://*/AlcatrazModel.csdl|res://*/AlcatrazModel.ssdl|res://*/AlcatrazModel.msl"; connectionBuilder.Provider = "System.Data.SqlClient"; connectionBuilder.ProviderConnectionString = connectionString; _connectionString = …

12 c#  .net  dependency-injection  entity-framework  n-tier 

ビューモデルでIValidatableObjectを実装し、カスタム検証を追加できるようにするMVCの拡張ポイントが気に入っています。 このコードを唯一の検証ロジックにして、コントローラーを無駄のないものにしようとしています。 if (!ModelState.IsValid) return View(loginViewModel); たとえば、ログインビューモデルはIValidatableObjectを実装し、コンストラクターインジェクションを介してILoginValidatorオブジェクトを取得します。 public interface ILoginValidator { bool UserExists(string email); bool IsLoginValid(string userName, string password); } ビューモデルにインスタンスを注入するNinjectは、実際には一般的な慣行ではないようです。 これは良いアプローチですか？より良いものはありますか？

12 architecture  asp.net-mvc  dependency-injection  validation  single-responsibility 

私は、依存性注入を使用して、クラスをユニットテスト可能にすることに取り組んでいます。しかし、これらのクラスの一部には多くのクライアントがあり、依存関係を渡すためにそれらすべてをリファクタリングする準備がまだできていません。だから私は徐々にそれをやろうとしている。現時点ではデフォルトの依存関係を維持しますが、テストのためにそれらをオーバーライドできます。 私が考えているアプローチの1つは、すべての「新しい」呼び出しを独自のメソッドに移動することです。たとえば、 public MyObject createMyObject(args) { return new MyObject(args); } 次に、単体テストでこのクラスをサブクラス化し、作成関数をオーバーライドして、代わりに偽のオブジェクトを作成します。 これは良いアプローチですか？欠点はありますか？ より一般的には、テストのために依存関係を置き換えることができる限り、ハードコードされた依存関係を使用しても大丈夫ですか？私は、コンストラクタで明示的にそれらを要求することが好ましいアプローチであることを知っており、最終的にそこに到達したいと思います。しかし、私はこれが良い最初のステップかどうか疑問に思っています。 私に発生した欠点の1つは、テストする必要がある実際のサブクラスがある場合、親クラス用に作成したテストサブクラスを再利用できないことです。実際のサブクラスごとにテストサブクラスを作成する必要があり、同じ作成関数をオーバーライドする必要があります。

12 unit-testing  dependency-injection