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

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 Resolve依存関係の挿入（インターフェイスへの実装の解決）、パッケージマネージャー（例：パッケージの依存関係の解決）、Web（例：ホスト名の解決）で、単語が使用される多くの場所で見ます。 では、コードのロジックを特別なものにして、誰かResolveが単純なConvert、Transformまたはさらには単語を選択するようにするのはGetなぜですか？

12 programming-practices  naming  dependency-injection  packages 

私は「依存性注入の原則、実践、およびパターン」という本を読んでおり、この本で十分に説明されているリークのある抽象化の概念について読んでいます。 最近では、依存関係の注入を使用してC＃コードベースをリファクタリングし、非同期呼び出しをブロックの代わりに使用しています。そうすることで、コードベースの抽象化を表し、非同期呼び出しを使用できるように再設計する必要があるいくつかのインターフェイスを検討しています。 例として、アプリケーションユーザーのリポジトリを表す次のインターフェースについて考えてみます。 public interface IUserRepository { Task<IEnumerable<User>> GetAllAsync(); } 本の定義によれば、リークの多い抽象化は特定の実装を念頭に置いて設計された抽象化であり、一部の実装は抽象化自体を通じて「リーク」します。 私の質問は次のとおりです。IUserRepositoryなどの非同期を念頭に置いて設計されたインターフェイスを、漏れやすい抽象化の例として検討できますか？ もちろん、可能なすべての実装が非同期と関係があるわけではありません。アウトプロセス実装（SQL実装など）だけが必要ですが、インメモリリポジトリは非同期を必要としません（実際にインメモリバージョンのインターフェイスを実装する方がおそらくインターフェースが非同期メソッドを公開している場合は困難です。たとえば、メソッドの実装でTask.CompletedTaskまたはTask.FromResult（users）のようなものを返す必要がある場合があります。 あれについてどう思う ？

12 c#  object-oriented  api-design  interfaces  dependency-injection 

Serviceコンストラクタを介して依存関係を受け取るが、使用する前にカスタムデータ（コンテキスト）で初期化する必要があると仮定します。 public interface IService { void Initialize(Context context); void DoSomething(); void DoOtherThing(); } public class Service : IService { private readonly object dependency1; private readonly object dependency2; private readonly object dependency3; public Service( object dependency1, object dependency2, object dependency3) { this.dependency1 = dependency1 ?? throw new ArgumentNullException(nameof(dependency1)); this.dependency2 = dependency2 …

11 dependency-injection  coupling 

任意のタイプのファイルの解析を担当するモジュールを検討してください。ここですでに説明したように、この問題に取り組むために戦略パターンを使用することを考えています。この質問に進む前に、リンクされた投稿を参照してください。 product.xmlファイルのコンテンツを必要とするクラスBを検討してください。このクラスは、XMLファイルを解析するために、Parserインターフェースの適切な具象実装者をインスタンス化する必要があります。適切な具象実装者のインスタンス化をファクトリに委任して、クラスBが「has-a」ファクトリになるようにすることができます。ただし、クラスBは、具体的な実装者をインスタンス化するためにファクトリに「依存」します。これは、クラスBのコンストラクターまたはセッターメソッドをFactoryに渡す必要があることを意味します。 したがって、ファイルを解析する必要があるファクトリとクラスBは、互いに密接に結合されます。私はこれまで説明してきたことについて完全に間違っている可能性があることを理解しています。私は、注入される依存関係がファクトリであるシナリオで依存関係の注入を使用できるかどうか、そしてこれを実装する正しい方法は何であるかを知りたいので、ユニットテストでファクトリをモックするなどの領域を活用できます。

11 java  design-patterns  dependency-injection 

私は依存関係の注入について学んでいるだけで、何かにこだわっています。依存性注入では、コンストラクターを介して依存クラスを送信することをお勧めしますが、これがデータオブジェクトに必要かどうかは疑問です。単体テストはDIの主な利点の1つであるため、データを格納するだけで、プロシージャを単体テストすることはなく、DIを不要な複雑なレイヤーにするデータオブジェクト、または依存関係の表示にも役立ちますデータオブジェクトで？ Class DO{ DO(){ DataObject2List = new List<DO2>(); } public string Field1; public string Field2; public List<DO2> DataObject2List; } Class DO2{ public DateTime Date; public double Value; }

11 c#  dependency-injection  class-design 

私はレイモンドヘッティンガーのPyconの講演「スーパー考慮スーパー」を見て、クラスの「親」クラスを決定論的な方法で線形化するPythonのMRO（メソッド解決順序）について少し学びました。これを使用して、以下のコードのように、依存性注入を行うことができます。だから今は当然、super何にでも使いたい！ 次の例では、Userクラスは、LoggingServiceとの両方から継承することで、依存関係を宣言していUserServiceます。これは特に特別なことではありません。興味深いのは、メソッド解決順序を使用して、単体テスト中に依存関係を模擬できることです。以下のコードは、モックしたいメソッドのMockUserService継承UserServiceと実装を提供するを作成します。以下の例では、の実装を提供していますvalidate_credentials。へのMockUserService呼び出しを処理validate_credentialsするにUserServiceは、MROの前に配置する必要があります。これは、User呼び出されるラッパークラスを作成し、MockUserそれをUserand から継承させることで行われMockUserServiceます。 これを実行するMockUser.authenticateと、次に、への呼び出しがメソッド解決順序のsuper().validate_credentials() MockUserService前UserServiceにあり、validate_credentialsこの実装の具体的な実装が提供されるため、これが使用されます。いいですね- UserService単体テストでうまく模倣しました。UserServiceコストのかかるネットワークやデータベースの呼び出しが発生する可能性があることを考慮してください。これにより、レイテンシ係数が削除されました。また、UserServiceライブ/製品データに触れるリスクもありません。 class LoggingService(object): """ Just a contrived logging class for demonstration purposes """ def log_error(self, error): pass class UserService(object): """ Provide a method to authenticate the user by performing some expensive DB or network operation. """ def validate_credentials(self, username, password): print('> UserService::validate_credentials') return username == …

11 object-oriented  python  dependency-injection  multiple-inheritance 

私のC ++アプリケーションには多くの車があり、すべてRaceTrackに含まれています。 各車は何百ものパーツで構成されています。各部分は他の部分に依存しています。 私はDIとMark Seemannの本で多くのSO質問を読みましたが、すべての自動車部品は相互に依存し、この部品のスープは自動車なので、自動車部品を保持するためだけにCarクラスを定義するべきではないようです。私は正しいですか？ したがって、すべてのレーシングカーをRaceTrackに配置すると、自動車の実体はなく、トラック上で互いにレーシングし合うことに依存する多くの自動車部品がありますか？私は正しいですか？ 編集： 車のロジックをプログラミングしている場合は車のクラスが必要であることは明らかだったので、長い間私は車のクラスをプログラミングしていました。しかし、DIでは、それは私にはそれほど明白ではありません。Carクラスが定義されていない場合にCarクラスを作成しないのは、DIの慣用句ですか？ つまり、運転用にSteeringWheelを、ピットクルー用にホイールにBoltsAndNutsを配置し、車全体を表すインスタンスがなくても、他のあらゆる種類の面白いインターフェースを配置しても問題ありませんか？

10 c++  dependency-injection 

例えば： var duckBehaviors = new Duckbehavior(); duckBehaviors.quackBehavior = new Quack(); duckBehaviors.flyBehavior = new FlyWithWings(); Duck mallardDuck = new Duck(DuckTypes.MallardDuck, duckBehaviors) Duckクラスにはすべての動作（抽象）が含まれているため、新しいクラスMallardDuck（拡張Duck）を作成する必要はないようです。 参照：ヘッドファーストデザインパターン、第1章。

10 design-patterns  dependency-injection  strategy-pattern 

過去1年間、私はすべてZendフレームワークに基づく一連のアプリケーションに取り組んでおり、すべてを使用しなくてもすべてのアプリケーションがアクセスする必要がある複雑なビジネスロジックを中心に（それぞれに複数のライブラリフォルダーを用意するよりも簡単です）それらはすべて共通のセンターでリンクされているため、アプリケーション）。 プロジェクトの詳細については詳しく説明しませんが、コードを "グループ化"する方法について（プロジェクトだけで作業しているので）いくつかの情報を探しています。私は、依存関係をできる限り取り除くような方法ですべてを分割しようとしました。 私はそれを論理的に可能な限り分離したままにしようとしているので、自分の時間がアップする12か月の時間で、他の誰かが私が作成したものを拡張するのに問題はありません。 構造例： applicationStorage\ (contains all applications and associated data) applicationStorage\Applications\ (contains the applications themselves) applicationStorage\Applications\external\ (application grouping folder) (contains all external customer access applications) applicationStorage\Applications\external\site\ (main external customer access application) applicationStorage\Applications\external\site\Modules\ applicationStorage\Applications\external\site\Config\ applicationStorage\Applications\external\site\Layouts\ applicationStorage\Applications\external\site\ZendExtended\ (contains extended Zend classes specific to this application example: ZendExtended_Controller_Action extends zend_controller_Action ) …

10 php  architecture  dependency-injection  zend-framework 

休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか？質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 4年前休業。 依存性注入をC＃のような言語に直接統合する方法を少し考えてきました。私はあなたの意見を聞きたいと思う潜在的な解決策を考え出しました。私は多くの依存関係注入フレームワークを使用していないので、見落としているものがあるかもしれません とにかく、キーワードを使用してプロパティを「注入可能」として宣言できるようにするという考えです。オブジェクトがインスタンス化され、そのプロパティがコンストラクターまたはオブジェクト初期化子を介して初期化されない場合、オブジェクトはいくつかのグローバルサービスからそのプロパティタイプのインスタンスを要求します。 同様に、さまざまなタイプのハンドラーをそのサービスに登録して、注入されたプロパティタイプをインスタンス化できるようにします。 この種のアーキテクチャーIMOを使用する利点は、かなり柔軟で使いやすいことです。欠点は、インジェクションを持つクラスを開始するたびにシングルトンへのコールアウトを実行するオーバーヘッドがある可能性があることです。 繰り返しになりますが、これは、高性能ソリューションで頻繁にインスタンス化されるクラスの問題にすぎないため、それほど問題にはなりません。おそらく、それらのインスタンスで何らかのファクトリを使用できます。 考え、問題、質問、より良いアイデア？ コード public class SomeClass { public SomeClass() { //implicit behavior if Animal is not set in constructor or initializer this.Animal = GlobalInjector.Get(this,typeof(Mammal)) } public injectable Mammal Animal { get; set; } } GlobalInjector.Register(typeof(Mammal), () => return new Mammal(someParameter));

10 programming-languages  dependency-injection  ioc-containers 

ドメインドリブンデザインについて初めて知ったとき、データベースに対する穴居人のようなSQLクエリを投げたクールな子供たちにとって、かつては一流であるように思われるリポジトリと作業単位パターンも紹介されました。EFやNHibernateのようなORMは、作業単位とリポジトリの両方を1つのAPI（セッションまたはコンテキストと呼ばれる）に実装するため、そのトピックを深く掘り下げれば読むほど、それらは必要なくなったように見えます。 今、私は何をすべきかわかりません。リポジトリするかしないか。このようなリークの多い抽象化は複雑すぎてデータアクセスを簡略化するものは一切追加しないという主張を本当に理解していますが、アプリケーションのあらゆる側面をEntity Frameworkなどに結合するのは適切ではないと感じます。通常、私はいくつかの簡単なガイドラインに従います： ドメイン層は、エンティティ、サービス、リポジトリを含むシステムの中心です... インフラストラクチャ層は、ファイル、データベース、プロトコルなどのインフラストラクチャ関連のドメインインターフェイスの実装を提供します。 アプリケーション層は、物事を結び付け、すべてをオーケストレーションするコンポジションルートをホストします。 私の解決策は通常次のようになります： Domain.Module1 Domain.Module2 IModule2Repo IModule2Service Module2 Infrastructure.Persistence Repositories EntityFrameworkRepositoryBase MyApp Boostrapper -> inject EntityFrameworkRepositoryBase into IRepository etc. 私は、IRepository<'T>データへのアクセス方法を教えてくれる他のものに依存しないドメインの問題でもあるを使用して、ドメインレイヤーをクリーンに保ちます。IModule2Serviceデータアクセスを必要とする具体的な実装を行うときは、注入DbContextし、これによってインフラストラクチャレイヤーに直接結合する必要があります。（Visual Studioプロジェクトに入ると、循環依存関係のために、これは本当にトリッキーになる可能性があります！） さらに、作品の保管庫やファックトンの代わりになるものは何ですか？CQRS？純粋なインフラストラクチャフレームワークを抽象化するにはどうすればよいですか？

10 design-patterns  database  domain-driven-design  dependency-injection  repository 

最近@ImplementedBy、Google Guiceで利用できるアノテーションについて読みました。プログラマーは、依存関係注入で将来使用するために、インターフェースとその実装の間のバインディングを指定できます。これは、ジャストインタイムバインディングの例です。 次の構文を使用して、モジュールで明示的なバインディングを定義することに慣れています。 bind(SomeInterface.class).to(SomeInterfaceImplementation.class); ドキュメントによると、これは次の@ImplementedByアノテーションの使用と同等です。 @ImplementedBy(SomeInterfaceImplementation.class) public interface SomeInterface { //method declarations } ここでわかる唯一の利点は、コードがわずかに短いことです。同時に、このアプローチには、同じドキュメントで正しく指摘されている欠点があります。 @ImplementedBy慎重に使用してください。インターフェイスからその実装にコンパイル時の依存関係を追加します。 そのような依存関係は多くの場合問題にはならないかもしれませんが、私は個人的にそれをコードのにおいとして見ています。 @ImplementedByアノテーションを使用する価値のあるユースケースは何ですか？ 1つの可能な方法は、ライブラリまたはフレームワークのコードで使用することです。ドキュメントで説明されているように、アノテーションは明示的なバインディングによって簡単にオーバーライドされるデフォルトのバインディングを提供できます。 タイプがbind()（最初の引数として）ステートメント内にあり、@ImplementedBy注釈がある場合、そのbind()ステートメントが使用されます。このアノテーションは、バインディングでオーバーライドできるデフォルトの実装を提案しています。 このようにして、ライブラリの開発者として、クライアントコードのどこかでカスタマイズできるすぐに使えるバインディングをユーザーに提供できます。 これが注釈が存在する唯一の理由ですか？それとも私が見逃しているものはありますか？ライブラリ/フレームワークを拡張するのではなく、いくつかのビジネスロジックを処理するアプリケーションだけのコードでそれを使用することで何かを得ることはできますか？

10 java  dependency-injection 

私は現在、制御の反転（IoC）コンテナーを既存のアプリケーションに統合することに直面しており、カップリングを減らし、それによってテスト容易性を高めるという最終的な目標でそれを最も簡単に達成できる方法に関するいくつかの推奨事項を探しています。私は通常、ほとんどのクラスを神のオブジェクトとして分類しませんが、静的、シングルトン、およびインターフェイスの欠如により、それぞれに責任が多すぎ、依存関係が隠されています。 以下は、直面する必要があるいくつかの課題の背景です。 依存性注入はほとんど使用されません 静的メソッドが豊富-ファクトリーメソッドとヘルパーメソッドの両方として シングルトンはかなり普及しています インターフェースを使用すると、きめ細かすぎない オブジェクトは多くの場合、基本クラスを通じて不要な依存関係を取り込みます 私たちの意図は、次に特定の領域で変更を加える必要があるときに、実際には存在するが、シングルトンやスタティックなどのグローバルの背後に隠されている依存関係を取り除くことを試みることです。 IoCコンテナが依存性注入の導入の副次的な要素になると思いますが、これらの依存関係を打開するのに役立つ、実行または推奨できる一連のプラクティスと推奨事項があると思います。

10 design  dependency-injection  maintenance 

データベースのISessionContext、ログ用のILogManager、および別のサービスとの通信に使用されるIServiceを必要とする多くのコアクラスがあります。すべてのコアクラスで使用されるこのクラスに依存性注入を使用したい。 2つの可能な実装があります。3つのクラスすべてのIAmbientContextを受け入れるか、3つのクラスすべてのクラスに注入するコアクラス。 public interface ISessionContext { ... } public class MySessionContext: ISessionContext { ... } public interface ILogManager { } public class MyLogManager: ILogManager { ... } public interface IService { ... } public class MyService: IService { ... } 最初の解決策： public class AmbientContext { private ISessionContext sessionContext; private ILogManager …

9 c#  dependency-injection 

問題 私は最近、シングルトンが悪いことと、依存性注入（「インターフェースを使用する」と理解しています）がどのように優れているかについて、多くのことを読みました。コールバック/インターフェース/ DIを使用してこの一部を実装し、インターフェース分離の原則に準拠した場合、結局は混乱しました。 基本的にそのすべての子の依存関係を組み合わせたUI親の依存関係。したがって、UI要素が階層の上位にあるほど、そのコンストラクターは肥大化していました。 UI階層の最上位にあるのはApplicationクラスで、現在の選択に関する情報と、変更を反映する必要のある3Dモデルへの参照を保持していました。アプリケーションクラスは8つのインターフェイスを実装していましたが、これは製品（/インターフェイス）の5分の1に過ぎません。 私は現在、現在の選択を保持するシングルトンと、自分自身を更新する機能を持つUI要素を使用しています。この関数は、UIツリーとUI要素を細流化し、必要に応じて現在の選択シングルトンにアクセスします。コードはこのように私にはきれいに見えます。 質問 このプロジェクトにはシングルトンが適切でしょうか？ そうでない場合、私の考えやDIの実装に根本的な欠陥があり、それが非常に煩雑になりますか？ プロジェクトに関する追加情報 タイプ：ベルとホイッスル付きのアパートメントのショッピングバスケット サイズ：コードとUIに2か月/月 メンテナンス：実行中の更新はありませんが、後で「バージョン2.0」になる可能性があります 環境：エンティティを使用するUnityでC＃を使用コンポーネントシステム ほとんどすべての場合、ユーザーの操作によっていくつかのアクションがトリガーされます。たとえば、ユーザーがアイテムを選択したとき そのアイテムとその説明を表示するUIパーツを更新する必要があります。このため、価格を計算するために、3Dモデルから情報を取得する必要もあります。 UIをさらに上に行くと、全体の合計価格を更新する必要があります 3dモデルのクラスの対応する関数を呼び出して、そこに変更を表示する必要があります

9 c#  dependency-injection  singleton