IOCを使用している場合、ASP.NETプロバイダモデルに最適な代替方法は何ですか？

Question

ASP.NETプロバイダモデルは、ある人の機能の別の実装をWebアプリケーションに「プラグイン」できるようにするという問題を解決する素晴らしい技術でした。プロバイダーモデルは、一般に、必要な構成を実装するには少し痛いので、最小限に使用されます。

IOCは、アプリケーションの各レベルで懸念事項を確実に分離するための優れた方法です。そのため、すべてのコンポーネントのユニットテストを広範囲にサポートすることが有効です。

WebアプリケーションがIOCコンテナを使用している場合は、すでに抽象化されているものを抽象化しているため、2つのレベルの複雑さが生じます（既存のプロバイダ - 私はカスタムプロバイダの作成について話しています）。

（私のブログの記事で、この上でより多くを参照してください。http://healthedev.blogspot.com/2011/12/making-custom-built-applications.html）

私はIOCのためAutoFacを使用していますが、それはプロバイダモデルと同じソリューションを満たすために良い代替のように思えるので、それは、「設定の上書き」を許可することが可能ですしかし私は、MEFがこの要件をどのように満たすかもしれないか、そこに何か他のものがあるかどうかについて、私が不足していることについてたくさん知りませんか？

ASP.NET MVC Webアプリケーションをゼロから設計することができ、パッケージ化されたバージョンを販売しなければならないという要件があったため、他の人がデータアクセスの特定のビットを再接続せずに "プラグイン"コンパイル、それをどうやって実装するのですか？

Answer 1

これは、プラグ可能なコンポーネントが何であるかによって異なります。

いくつかのものはプロバイダーでなければなりません。たとえば、標準のASP.NETメンバーシッププロバイダの機能を使用している場合、その機能を派生させる必要があります。そのような状況では、依存関係の解決を行い、DIに登録されている実装への呼び出しを渡すような、ある種の「プロキシ」プロバイダを書くのは簡単であることが分かりました。あなたはAutofacは、あなたのメンバシッププロバイダに次のようなものが表示される場合がありますMVC DependencyResolverまで有線持っていると仮定すると例えば

、：私はあなたが分離することができます任意の自動機能を発見していない

public override bool ChangePassword(
    string username, 
    string oldPassword, 
    string newPassword) 
{ 
    var provider = DependencyResolver.Current.GetService<IMembershipService>(); 
    return provider.ChangePassword(username, oldPassword, newPassword); 
} 

ビルトインのプロバイダ。

プロバイダーでないものについては、通常どおりIoC機能を使用してください。オートファックのassembly scanning functionalityとmodulesを使って、config-less IoCを好むので、基本的にはオーバーライドしたアセンブリをbinフォルダに入れてアプリを再起動することができます。起動時に任意のモジュールをスキャンして登録します。あなたはそれよりもより明確になりたい場合は、独自のスタートアップ・インターフェースのような...

public interface IMyStartup 
{ 
    void Start(ContainerBuilder builder); 
} 

を作成...そしてちょうどあなたの特定のインターフェイスをスキャンし、その上のstartメソッドを呼び出すことができます。それを行う方法は数多くあります（アトリビュート、タイプ、特定の既知の場所にあるアセンブリなど）が、アセンブリスキャンに至るまで揃っています。

Answer 2

ユニティと構造マップも用意されています。 Unityはこれを行うためにauto.registrationモジュールを必要とします。