問題タブ [simple-injector]

数週間、Simple Injector依存性注入コンテナーを使用して大きな成功を収めています。簡単に設定できるところが気に入っています。しかし、現在、構成方法がわからないデザインがあります。多くの型が派生する基本クラスがあり、基本クラスのプロパティに依存関係を挿入したいのですが、派生クラスごとに構成する必要はありません。属性でこれを実行しようとしましたが、Simple Injector は属性をサポートしていません。これは私のデザインの縮小版です。

私の構成は次のようになります。

BaseHandler にプロパティを挿入するにはどうすればよいですか?

助けてくれてありがとう。

このメソッドを使用して、RegisterInitializer次のように基本タイプにプロパティを挿入します。

これはうまく機能しますがRegisterInitializer、BaseHandlerから継承するすべての登録済みタイプで起動されるわけではありません。私が自分自身を呼んだとき、それは実行されていないようですnew：

それはなぜですか、そしてどうすればこれを解決できますか？

私は DI と IoC が初めてで、どの IoC コンテナーを学習するかを決めようとしています。参照されている 3 つのコンテナーのパフォーマンスが非常に優れているように見えるいくつかのパフォーマンス比較を見てきました。ただし、Hiro または Simple Injector を含む機能比較は見つかりませんでした。Autofac のコミュニティは最大のようですが、Hiro と Simple Injector はベンチマークで非常に高速であり、特に Simple Injector は非常に習得が容易であると主張しています。とはいえ、機能セットが限られているため、1 つを学習して別のものに切り替える必要はありません。そのため、Autofac はかなり成熟しており、機能が充実しているため、私は Autofac に傾倒しています (良い記事はこちらとこちら)。) だけでなく、利用可能な最速の IoC コンテナーの 1 つでもあります。これらの 3 つのコンテナーのうち少なくとも 2 つを使用した経験のある人はいますか? 機能の比較を提供できますか?

Autofac にはモジュールがあり、Windsor にはインストーラーと StructureMap Registries があります。Simple Injector を使用すると、構成ロジックを再利用可能なクラスにどのようにパックできますか?

私が試してみました：

そして、私はコンポジションルートでそれを使用します:

ただし、FooModuleコンテナーに依存し、おそらく良い方法ではありません... http://code.google.com/p/autofac/wiki/BestPracticesを参照してください:

コンポーネントがコンテナーに依存している場合は、コンテナーを使用してサービスを取得する方法を確認し、代わりにそれらのサービスをコンポーネントの (依存関係が挿入された) コンストラクター引数に追加します。

私は今次のことをしています

でもこういうことをしたい

これはどういうわけか可能ですか？

コマンド ハンドラーの装飾に関するこの記事を読んだ後、今日は興味深い話題に乗り出しました。SimpleInjectorの代わりに Unity を使用してパターンを実装できるかどうかを確認したかったのですが、これまでのところ非常に難しいことがわかっています。

最初にやらなければならなかったことは、 UnityAutoRegistrationをインストールして、開いている汎用ICommandHandler<TCommand>インターフェイスを解決することでした。その側面に対する現在の解決策は次のとおりです。

これは最初の部分で機能し、単一の ICommandHandler<TCommand>. これまでのところイライラすることが証明されているのは、装飾ハンドラーの実装です。デコレーターとして1 秒追加するとすぐにICommandHandler<TCommand>、Unity は StackOverflowException をスローします。Unity の内部についてはよくわかりませんが、どちらのインスタンスもICommandHandler<TCommand>インターフェイスを実装しているため、どちらのインスタンス (コマンド ハンドラーまたはコマンド ハンドラー デコレーター) に解決するかを判断できないためだと推測しています。

グーグルで調べたところ、最初にこの記事にたどり着きました。これは、私がブルートフォースメソッドと見なす方法でそれを行う方法を説明しています. これらの 関連 ページも見つけましたが、どれも私の問題に対する完全な解決策ではありません (そして、私は無知すぎて自分でそれを理解できません)。

その後、同じ懸念に対処しているように見えるこの記事を見つけました。ただし、beefy のソリューションでは、オープン ジェネリックの処理が考慮されていません。現在、ほとんどの依存関係は .config ファイルの unity セクションから読み込まれているため、ハンドラーやデコレーターごとに大量のコンパイル済みコードを書きたくありません。ある種の UnityContainerExtension と DecoratorBuildStrategy を使用するのが正しい方法のようですが、わかりません。私はビーフィーのコードでしばらく遊んでいて、完全に立ち往生しています。ジェネリックを考慮して彼のコードを変更しようとすると、BadImageFormatExceptions が発生しました (正しくない形式のプログラムを読み込もうとしました (HRESULT からの例外: 0x8007000B))。

デコレーター チェーンを実装するためにこれを行うというアイデアが気に入っています。これは短く、懸念ごとに 1 行しかないからです。

...しかし、必要がなければ、コンテナーを Unity から Simple Injector に変更したくありません。

だから私の質問は、ユニティ（プラス）を使用してオープンジェネリックデコレータチェーンを実装するにはどうすればよいUnityAutoRegistrationですか?

インターフェイスにラップされたEFを使用してDbContext、Webリクエストごとに依存性を注入し、リクエスト全体が同じコンテキストを処理するようにします。また、認証サービスをカスタマイズRoleProviderするためにbyインターフェースを使用するカスタムもあります。DbContext

これまで、サービスロケーターパターンを使用してDbContext、カスタムRoleProviderの引数なしコンストラクターでインスタンスを解決してきました。は単調であるため、これによりいくつかの小さな問題が発生しました。そのため、無期限RoleProviderに保持される可能性がDbContextありますが、他の要求では、の間にそれを破棄する必要がありApplication_EndRequestます。

ウィンザーとは異なるiocコンテナーを使用していますが、これに基づくソリューションがあります。DIを使用して、RoleProviderhttpリクエストごとにカスタムインスタンスを作成できます。

私の質問は、私がすべきですか？

オープンにDbContextぶら下がっているのRoleProviderは無駄に思えます。一方、私はすべてのMVCAuthorizeAttributeがヒットすることを知っているのでRoleProvider（null以外のプロパティがある場合、ほとんどの場合そうです）、すでに待機Rolesしていると便利だと思います。DbContext

別の方法は、 Webリクエストごとではないものに別DbContextのものを注入することです。RoleProviderこのようにDbContextして、Webリクエストに対してのみ存在するは、シングルトニーに影響を与えることなく、最後に破棄できRoleProviderます。

どちらのアプローチが優れていますか、そしてその理由は何ですか？

コメント後に更新

スティーブン、これは本質的に私がしたことです。唯一の違いは、に依存しないことSystem.Web.Mvc.DependencyResolverです。代わりに、私は基本的に自分のプロジェクトにまったく同じものを持っていますが、名前が異なります。

これらのクラスはプロジェクトのコアAPIの一部であり、MVCとは異なるプロジェクトにあります。System.Web.Mvcこのように、他のプロジェクト（およびドメインプロジェクト）は、そのプロジェクトに対してコンパイルするために依存関係をとる必要はありませんDependencyResolver。

そのフレームワークを考えると、UnityをSimpleInjectorと交換することはこれまでのところ簡単です。多目的シングルトンRoleProviderセットアップは次のようになります。

Web.config：

IoCコンテナ：

CUDに関しては、私の実装されているメソッドは1つだけCustomRoleProviderです。

これはMVC AuthorizeAttribute（およびIPrincipal.IsInRole）で使用される唯一のメソッドであり、他のすべてのメソッドから、私は単に

プロバイダーにはCUDopsの役割がないため、トランザクションについては心配していません。

AbstractValidatorsを使用してFluentValidation を登録できFluentValidatorFactoryます。ただし、すべての IoC コンテナー登録がブートストラップ/コンポジション ルート中に行われるわけではないため、適切ではありません。代わりに、流暢なバリデーターは別の factory によって登録されます。

コンポジションルート:

IServiceProvider のみに依存する抽象流暢バリデータ ファクトリ

SimpleInjectorの流暢なバリデータ ファクトリの実装

SimpleInjector はオープン ジェネリックを適切にサポートしており、流暢なバリデータ クラスはすべて次のような署名を持っています。

それで、流暢なバリデーターファクトリーを使用する代わりに、バリデーターをブートストラップ/コンポジションルートに登録するより良い方法はありますか?

PS @DotNetJunkie - simpleinjector.codeplex.comにこれに関する wiki ページがあれば素晴らしいでしょう。

GetInstance(Of TService)Simple Injector に、返されるたびに例外のスローを停止するオプションがあるかどうか疑問に思っていましたNothingか? インスタンスを取得するための2つのリクエストがあり、そこになく、例外がスローされるため、現在それらをスローしているようです。

デフォルトの動作、どこかの設定、または何か他のものを防ぐ方法はありますか?

私は を持っておりObjectA、これには のプロパティがありObjectB、 には のプロパティがありますObjectC。これらはすべてSimple Injectorコンテナにあります。を作成するときObjectAに呼び出すInjectPropertiesと、 が読み込まれObjectBます。ただし、現時点ではObjectC、新しく作成された 内への参照はロードされませんObjectB。オブジェクトの「深いビルドアップ」と呼ばれるものは実行しません。

これを有効にする方法はありますか？

編集

私はクラスオブジェクトAを持っています:

次のプロパティがありますObjectB。

すべては、コンテナーで標準の登録メソッドを使用して登録されています。を取得するにはObjectA、使用GetInstance<ObjectA>(),しますが、これは正常に戻ります。作成時にすべてのオブジェクトを構築するための初期化子も作成しました。

これは に注入ObjectBされますが、解決時に に注入されObjectAません。ObjectCObjectBObjectB

回避策はありますか? ありがとう。