1

私は本当に DI/IoC のことにはまってしまいました。ただし、必要なパラメーターなしのコンストラクターを持つクラスを実装する継承されたクラスがいくつかあるため、サービスロケーターを使用して必要なものを取得します。

MyMembershipProivder() : MyMembershipProvider(ServiceLocator.Current.GetInstance<...>){}
MyMembershipProivder(IMemberRepo memberRepo){...}

完璧に動作します。ただし、MVC3 DependencyResolver も使用しているため、次のことを行うしかありません。

var locator = new NinjectServiceLocator(kernel);
DependencyResolver.SetResolver(locator);
ServiceLocator.SetLocatorProvider(() => locator);

DependencyResolver は MVC アプリ内で使用され、ServiceLocator はさまざまなクラス ライブラリ全体で使用されます。

これはこれを行うための理想的な方法ですか？何か不足していますか？

アップデート

上記の例では、クラスはカスタム asp.net メンバーシップ プロバイダーです。asp.net メンバーシップ プロバイダー ファクトリでは、カスタム プロバイダーにパラメーターのないコンストラクターが必要なため、サービス ロケーターを使用して内部で使用するリポジトリを挿入する必要があります。

4

2 に答える 2

2

パラメータのないコンストラクタは必要ありません。依存関係リゾルバは、依存関係をコンストラクタに注入します。

MyMembershipProivder(IMemberRepo memberRepo){...}

デフォルトのコントローラーファクトリを置き換えることができます（コントローラーでパラメーターなしのコンストラクターを使用するため）。

ControllerBuilder.Current.SetControllerFactory(new NinjectControllerFactory());

デフォルトのコントローラーファクトリを置き換える必要はありません。以下のLinkgoronのコメントを参照してください。

とにかく、MVCアプリケーションにDependency Resolverを使用し、クラスライブラリにServiceLocatorを使用することは問題ないと思います。

お役に立てれば。

于 2011-02-26T20:04:06.197 に答える
0

最初から DI を使用するようにアプリケーションをリファクタリングできない限り、実際には選択の余地がないように思われます。したがって、カスタムの Service Locator を使用するのが最善の策だと思います。

ただし、「継承」したクラスがコントローラー クラスである場合は、MVC がすべてを処理するため、デフォルトのコンストラクターを削除するだけで完了できます。

ServiceLocator クラスを見たことがないのですが、これですか?

編集：

私が言ったように、デカップリングの選択肢は他にないと思います。サービスの場所は、肥大化や複雑化を招くことなく、おそらく最善の策です。

.Net FW に組み込まれたものとして実装されているものは、Membership Provider 用に提示されたような特定のソリューションを探す必要があります。

于 2011-02-26T21:00:00.020 に答える