2

これまで、カスタムメンバーシッププロバイダーへのインジェクションの可能性について読んで、それを行うための2つの可能な方法を見つけました。

1つは次のとおりです：http：//bugsquash.blogspot.com/2010/11/windsor-managed-membershipproviders.html

ここで、作成者は基本的にカスタムプロバイダーを登録し、メンバーシップ用にかなり疑わしいウィンザーアダプターを用意することを提案しています（プロバイダーが取得したコンテナーを使用してプロバイダーをインスタンス化する方法はあまり好きではありません。HttpApplication最終的にはウィンザーアダプターでラップされます。 ）。

これは別の同様のオプションです：http ：//code.google.com/p/webdotnet/source/browse/trunk/Steeg.Framework/Web/Security/MemberShipProvider.cs？r = 2

依存関係をオーバーライドInitialize()して手動でインスタンス化する場合。少なくとも最初のものでは、（プロバイダー自体を除いて）手動で依存関係をインスタンス化する必要はありません。

次に、ある種のサービスロケーター（MVCまたはその他）の使用を提案するものがいくつかあります。

Membership.Providerそれから私は、のようなものでかなり簡単にプロパティへの依存関係を注入するninjectに出くわしました_kernel.Inject(Membership.Provider)。これは私が望むものにはるかに近く、最初にDIを使用することに私を惹きつけたコンポジションルートの概念を維持しています。

Castleを使用して同様の結果を得るにはどうすればよいですか？

更新：明らかに、これにはライフサイクル管理に問題があります。 Ninjectを使用してカスタムメンバーシッププロバイダーにリポジトリを挿入します

それでは、オプション＃1を選択する必要がありますか？少なくともそれで、私はプロバイダーを自分でインスタンス化します。したがって、ライフサイクル管理は問題になりません。

4

1 に答える 1

2

タイプが（正しく）登録されていない場合、コンテナは高速で失敗するのではなく、プロパティをスキップするため、暗黙的なプロパティインジェクションは使用しません（詳細はこちら）。代わりに、Service Locatorを使用しますが、ロジックを含まないラッパーメンバーシッププロバイダーを作成し、サービスロケーターにメンバーシッププロバイダーを要求して、その実装を呼び出します。Jonas GauffinはMVC用に（DependencyResolverサービスロケーターを使用して）そのようなことを書きました。これは非常に優れています（ NuGetでも利用可能です）が、自分で行うのは簡単です。

サービスロケーターの使用はアンチパターンと見なされますが、メンバーシップモデルはweb.configを介して構成する必要があり、システムのこの部分はDependencyResolver.Currentそれ自体を使用しないことに注意してください。また、そのようなaを書くことDependencyResolverMembershipProviderはほんの少しの仕組みであり、アプリケーションではなく、コンポジションルートの一部と見なすことができます。コンポジションルート内のコンテナを呼び出すことは問題ではありません。

于 2012-04-17T07:23:00.573 に答える