問題タブ [dependency-injection]

依存性注入のためにアプリケーション内で IoC を使用する最善の方法について頭を悩ませようとしていますが、少し問題があります。

WPF アプリで MVP パターンの緩やかな実装を使用しています。基本的に、プレゼンター クラスがインスタンス化され、ビューとタスク (EmployeePresenter の IEmployeeView と IEmployeeTask など) がプレゼンターに挿入されます。

これらのインスタンスを手動で注入する代わりに、IoC コンテナーを使用したいと思います (Unity を試していますが、これは ninject や Structure Map などの他のものでも発生すると思います)。 IoC コンテナー) を非同期デリゲート呼び出し、またはイベント スレッド (例: STA スレッドではない) で呼び出してから、WPF ウィンドウの新しいインスタンスを作成すると、次の例外がスローされます。

現在のビルド操作 (ビルド キー Build Key[ namespace .Window1, null]) が失敗しました: 多くの UI コンポーネントがこれを必要とするため、呼び出しスレッドは STA でなければなりません。

さて、新しいウィンドウ インスタンスなどを STA にする必要があることはわかっていますが、UI を STA スレッドで作成する必要がある場合でも、IoC コンテナーを使用して依存関係の挿入を行うことは可能ですか?

この問題を見ると、解決されているクラス/タイプは、登録時ではなく、解決時にインスタンス化されているように見えます...

わかりましたので、おおよそ次のようなコードを探しています。

ここで、1 つのアプローチはo、パラメーターとして使用されるすべてのオブジェクトに、次のようなインターフェイスを実装させることです。

しかし、これの問題は、すべてのオブジェクトにこのインターフェイスを実装させたくないということです。何かを行うメソッドのロジックは、実際にはオブジェクトに属していません。これに対処するには、どのパターンを使用する必要がありますか?

の一連の実装のようなものを疑っています

良いかもしれません。実装したいオブジェクトの種類ごとに実装する必要がありますが、この新しい問題が発生します。私は時点で次のような方法が必要です

しかし、これには大規模なスイッチが必要ですか? 次のようなメソッドがたくさんあるクラスを定義する必要がありますか

これには、実行時に新しい型を追加できないという一般的なバージョンと比較して問題があります。コンテナーを解決するために、GetPropsGeneric の DI コンテナーでできる狡猾な何かがありますか? ありがとう！

Apache Felix とその Declarative Services (SCR) を使用して、バンドル間のサービス依存関係を結び付けています。

たとえば、java.util.Dictionary にアクセスする必要がある場合は、次のように言って SCR に提供させることができます。

現在、複数の辞書サービスが利用可能であり、「name」サービス プロパティを使用してそれらをフィルター処理したいと考えています (「name=myDictionary」のみが必要です)。これはコードで (ServiceTracker を使用して) 行うことができますが、代わりに @scr アノテーションでフィルターを指定したいと思います。

Interface Builder は Cocoa アプリの基本的な依存性注入に使用できますが、NIB ファイルでオブジェクトをインスタンス化したくない場合に備えて、Objective-C/Cocoa のより完全な依存性注入フレームワークを知っている人はいますか?

編集

明確にするために、IBは基本的なDIに使用できることを認識していますが、GroovyまたはSpringsのラインに沿って、個別の運用構成とテスト構成を含む、より完全な機能を備えたフレームワークを探しています.

私は一見非常に単純なことを達成しようとしています:私の単体テストから、解決されている型をモック/偽のオブジェクトに置き換えたいと思っています。

例: xml 構成は、サービス IInterface のコンポーネントが ClassA に解決される必要があることを示しています。それは問題ありませんが、単体テストから、代わりに型を FakeClassA に解決したいと考えています。「指定されたキーに対してすでにコンポーネントが登録されている...」ため、これには container.AddComponent を使用できません。

コンテナに複数の実装がある場合、どのようにして城のウィンザーが実行時にインターフェイスの適切な実装を選択することができるでしょうか。

たとえば、IExamCalc と呼ばれる単純なインターフェイスを使用して、その試験で誰かがどのように成績を上げたかを計算するとします。

いいえ、たとえば、次のようないくつかの実装があります。

ExamMarkService が Windor を介して reslove されているとします。正しい実装がコンストラクターに挿入されていることを確認するにはどうすればよいですか? これはマルチテナンシーの問題の例ですか?

すべてが理にかなっていることを願っています

コリン・G

私は、以前にプロジェクトで使用されていたDI/IOCコンテナーの概念に比較的精通しています。ただし、この新しいプロジェクトでは、既存のフレームワークがないため、フレームワークを選択する必要があります。

簡単に言うと、特定のインターフェイスに対していくつかの実装を構成するシナリオがいくつかあります。Webを一瞥すると、主流のフレームワークのいずれかを使用して、実装の1つに選択的にバインドするのは非常に簡単なようです。

ただし、構成されたすべての実装を実行する必要があるコンテキストがあります。私はここですべてのIOCタグ付き投稿を精査し、主要なフレームワークのドキュメント（これまでのところ、Unity、Ninject、およびWindsorを調べています）を調べようとしていますが、ドキュメントはまばらであることが多く、調査する時間がありません。すべてのパッケージのソース。

それで、私のサービスの1つに対して構成されたすべての具象タイプにバインドできるようにする主流のIOCコンテナーはありますか？

アノテーションを介してクラスパスから取得されるSpring Beanがたくさんあります。

Spring XML ファイルには、PropertyPlaceholderConfigurerが定義されています。

app.properites のプロパティの 1 つを上記の Bean に注入したいと考えています。私は単に次のようなことはできません

PersonDaoImpl は Spring XML ファイルに含まれていないためです (アノテーションを介してクラスパスから取得されます)。私は次の限り持っています：

しかし、興味のあるプロパティにどのようにアクセスするかは明確ではありませんかppc?

私が見つけた例では、コントローラがデータ アクセス レイヤのリポジトリ クラスを直接使用する 2 レイヤ アーキテクチャを使用しています。ここまたはここを参照してください。

コンポーネントを使用するサービスまたはビジネス ロジック層がある場合、データ アクセス層からコンポーネントをどこに登録しますか? データ アクセス層は、理想的にはユーザー インターフェイス層から参照されるべきではありませんよね? したがって、Application_Start は適切な場所ではありません。

より良い方法は何でしょうか？

ありがとうございました！

私はシステムの新しいコンポーネントを設計しており、DIに関するさまざまなガイドラインに従おうとしているので、分離、モックなどの点で見返りが得られます。

したがって、次のコンポーネントがあります（抽象化として示されています）。

• Fetcher-特定のデータソースからデータをフェッチするIFetcherをサポートします。IDataSourceを返します。
• Builder-IDataSourceから構造を構築するIBuilderをサポートします。

これらを「Performer」（より良い名前が必要な場合）コンポーネントにまとめたいと思います。これにより、次のようになります。

依存性注入とLoDのガイドラインに準拠するために（とにかく理解している限り）、IFetcherコンポーネントとIBuilderコンポーネントの両方をに渡します。

私の質問-これは許容できる設計のように聞こえますか？同僚との会話は「ええ、いいですね」の線に沿っていますが、パフォーマークラスによるカプセル化を100％確信しているわけではありません。

私の見方では、パフォーマーは、いくつかの異なるコンポーネントを接着する複合コントロールであり、許容できるはずです。唯一の疑問符は、「Performer Factory」が必要かどうかですが、実際のコンポーネント（IFetcherとIBuilder）がモックされる可能性があることを考えると、これはやり過ぎのようです。

どんな考えでもありがたいです、ありがとう。