主要なC＃DI / IoCフレームワークはどのように比較されますか？[閉まっている]

聖戦領域に足を踏み入れるリスクがある場合、これらの一般的なDI / IoCフレームワークの長所と短所は何ですか？..：

• Ninject
• ユニティ
• Castle.Windsor
• Autofac
• StructureMap

ここに記載していない他のC＃のDI / IoCフレームワークはありますか？

私のユースケースのコンテキストでは、クライアントWPFアプリとWCF / SQLサービスインフラストラクチャを構築しています。使いやすさ（特に明確で簡潔な構文に関して）、一貫したドキュメント、優れたコミュニティサポートとパフォーマンスはすべて重要な要素です私の選択で。

更新：

引用されているリソースと重複する質問は古くなっているようですが、これらすべてのフレームワークについての知識を持つ誰かが前に出て、実際の洞察を提供できますか？

私はこのテーマに関するほとんどの意見が偏っている可能性があることを理解していますが、誰かがすべてのこれらのフレームワークを研究するために時間をかけ、少なくとも一般的に客観的な比較を持つことを望んでいます。

これまでに行われていない場合は、自分で調査することをいといませんが、これは少なくとも数人がすでに行っていることだと思いました。

2回目の更新：

複数のDI / IoCコンテナの経験がある場合は、それらの長所と短所をランク付けして要約してください。ありがとうございます。これは、人々が作成したあいまいな小さなコンテナーをすべて発見するための演習ではありません。人気のある（そしてアクティブな）フレームワークの比較を探しています。

この質問に対する包括的な回答は私の本の数百ページを占めますが、ここでは私がまだ取り組んでいる簡単な比較表を示します。

別のパフォーマンス比較に遭遇しました（最新の更新2014年4月10日）。以下を比較します。

• AutoFac
• LightCore（サイトはドイツ語）
• LinFu
• Ninject
• 小柄
• Simple Injector （すべての競技者の中で最速）
• Spring.NET
• StructureMap
• ユニティ
• ウィンザー
• ヒロ

これが投稿の簡単な要約です：

結論

Ninjectは間違いなく最も遅いコンテナです。

MEF、LinFu、Spring.NETはNinjectより高速ですが、それでもかなり低速です。次にAutoFac、Catel、Windsorが続き、StructureMap、Unity、LightCoreが続きます。Spring.NETの欠点は、XMLでのみ構成できることです。

SimpleInjector、Hiro、Funq、Munq、およびDynamoは最高のパフォーマンスを提供し、非常に高速です。それらを試してみてください！

特にSimple Injectorは良い選択のようです。これは非常に高速で、優れたドキュメントがあり、傍受や一般的なデコレータなどの高度なシナリオもサポートしています。

また、Common Service Selector Libraryを使用してみて、うまくいけば複数のオプションを試してみて、何が最適かを確認することもできます。

サイトからのCommon Service Selector Libraryに関するいくつかの情報：

ライブラリは、IoCコンテナーとサービスロケーターの抽象化を提供します。ライブラリを使用すると、ハード参照に依存することなく、アプリケーションが機能に間接的にアクセスできます。このライブラリを使用すると、サードパーティのアプリケーションやフレームワークが特定の実装に縛られることなくIoC / Service Locationを活用できるようになることが期待されます。

更新

13.09.2011： FunqとMunqが出場者のリストに追加されました。グラフも更新され、Spring.NETはパフォーマンスが低いため削除されました。

2011年4月11日：「シンプルインジェクターを追加し、パフォーマンスはすべての競技者の中で最高です」。

Philip Matによるこの素晴らしい.Net DIコンテナー比較ブログを読んでください。

彼はいくつかの徹底的なパフォーマンス比較テストを行っています。

• Autofac
• StructureMap
• Ninject
• ユニティ
• Castle.Windsor
• Spring.Net

Autofacは小さく、高速で、使いやすいので、彼は推奨しています... と思わユニティとNinjectは彼のテストで最も遅いです。

免責事項： 2015年の初めの時点で、Jimmy Bogardの IoCコンテナー機能の優れた比較があります。ここに要約を示します。

比較されるコンテナ：

• Autofac
• Ninject
• シンプルなインジェクター
• StructureMap
• ユニティ
• ウィンザー

シナリオは次のとおりです。インターフェイスIMediatorがあり、単一の要求/応答または通知を複数の受信者に送信できます。

public interface IMediator 
{ 
    TResponse Send<TResponse>(IRequest<TResponse> request);

    Task<TResponse> SendAsync<TResponse>(IAsyncRequest<TResponse> request);

    void Publish<TNotification>(TNotification notification)
        where TNotification : INotification;

    Task PublishAsync<TNotification>(TNotification notification)
        where TNotification : IAsyncNotification; 
}

次に、リクエスト/レスポンス/通知の基本セットを作成しました。

public class Ping : IRequest<Pong>
{
    public string Message { get; set; }
}
public class Pong
{
    public string Message { get; set; }
}
public class PingAsync : IAsyncRequest<Pong>
{
    public string Message { get; set; }
}
public class Pinged : INotification { }
public class PingedAsync : IAsyncNotification { }

ジェネリックのコンテナーサポートに関して、いくつかの点に興味がありました。

• オープンジェネリックのセットアップ（IRequestHandler <、>を簡単に登録）
• オープンジェネリックの複数登録のセットアップ（2つ以上のINotificationHandlers）

一般的な分散の設定（ベースINotificationのハンドラーの登録/リクエストパイプラインの作成）私のハンドラーは非常に単純で、コンソールに出力するだけです。

public class PingHandler : IRequestHandler<Ping, Pong> { /* Impl */ }
public class PingAsyncHandler : IAsyncRequestHandler<PingAsync, Pong> { /* Impl */ }

public class PingedHandler : INotificationHandler<Pinged> { /* Impl */ }
public class PingedAlsoHandler : INotificationHandler<Pinged> { /* Impl */ }
public class GenericHandler : INotificationHandler<INotification> { /* Impl */ }

public class PingedAsyncHandler : IAsyncNotificationHandler<PingedAsync> { /* Impl */ }
public class PingedAlsoAsyncHandler : IAsyncNotificationHandler<PingedAsync> { /* Impl */ }

Autofac

var builder = new ContainerBuilder();
builder.RegisterSource(new ContravariantRegistrationSource());
builder.RegisterAssemblyTypes(typeof (IMediator).Assembly).AsImplementedInterfaces();
builder.RegisterAssemblyTypes(typeof (Ping).Assembly).AsImplementedInterfaces();

• ジェネリックを開く：はい、暗黙的に
• 複数のオープンジェネリック：はい、暗黙的に
• 一般的な逆分散：はい、明示的に

Ninject

var kernel = new StandardKernel();
kernel.Components.Add<IBindingResolver, ContravariantBindingResolver>();
kernel.Bind(scan => scan.FromAssemblyContaining<IMediator>()
    .SelectAllClasses()
    .BindDefaultInterface());
kernel.Bind(scan => scan.FromAssemblyContaining<Ping>()
    .SelectAllClasses()
    .BindAllInterfaces());
kernel.Bind<TextWriter>().ToConstant(Console.Out);

• ジェネリックを開く：はい、暗黙的に
• 複数のオープンジェネリック：はい、暗黙的に
• 一般的な矛盾：はい、ユーザーが作成した拡張機能を使用

シンプルなインジェクター

var container = new Container();
var assemblies = GetAssemblies().ToArray();
container.Register<IMediator, Mediator>();
container.Register(typeof(IRequestHandler<,>), assemblies);
container.Register(typeof(IAsyncRequestHandler<,>), assemblies);
container.RegisterCollection(typeof(INotificationHandler<>), assemblies);
container.RegisterCollection(typeof(IAsyncNotificationHandler<>), assemblies);

• ジェネリックを開く：はい、明示的に
• 複数のオープンジェネリック：はい、明示的に
• 一般的な矛盾：はい、暗黙的に（更新3.0で）

StructureMap

var container = new Container(cfg =>
{
    cfg.Scan(scanner =>
    {
        scanner.AssemblyContainingType<Ping>();
        scanner.AssemblyContainingType<IMediator>();
        scanner.WithDefaultConventions();
        scanner.AddAllTypesOf(typeof(IRequestHandler<,>));
        scanner.AddAllTypesOf(typeof(IAsyncRequestHandler<,>));
        scanner.AddAllTypesOf(typeof(INotificationHandler<>));
        scanner.AddAllTypesOf(typeof(IAsyncNotificationHandler<>));
    });
});

• ジェネリックを開く：はい、明示的に
• 複数のオープンジェネリック：はい、明示的に
• 一般的な逆分散：はい、暗黙的に

ユニティ

container.RegisterTypes(AllClasses.FromAssemblies(typeof(Ping).Assembly),
   WithMappings.FromAllInterfaces,
   GetName,
   GetLifetimeManager);

/* later down */

static bool IsNotificationHandler(Type type)
{
    return type.GetInterfaces().Any(x => x.IsGenericType && (x.GetGenericTypeDefinition() == typeof(INotificationHandler<>) || x.GetGenericTypeDefinition() == typeof(IAsyncNotificationHandler<>)));
}

static LifetimeManager GetLifetimeManager(Type type)
{
    return IsNotificationHandler(type) ? new ContainerControlledLifetimeManager() : null;
}

static string GetName(Type type)
{
    return IsNotificationHandler(type) ? string.Format("HandlerFor" + type.Name) : string.Empty;
}

• ジェネリックを開く：はい、暗黙的に
• 複数のオープンジェネリック：はい、ユーザーが作成した拡張機能
• 一般的な反変性：derp

ウィンザー

var container = new WindsorContainer();
container.Register(Classes.FromAssemblyContaining<IMediator>().Pick().WithServiceAllInterfaces());
container.Register(Classes.FromAssemblyContaining<Ping>().Pick().WithServiceAllInterfaces());
container.Kernel.AddHandlersFilter(new ContravariantFilter());

• ジェネリックを開く：はい、暗黙的に
• 複数のオープンジェネリック：はい、暗黙的に
• 一般的な逆分散：はい、ユーザーが作成した拡張機能を使用

実際、IoCフレームワークはたくさんあります。すべてのプログラマーがキャリアのある時点で1つを作成しようとするようです。多分それを公開するためではなく、内部の仕組みを学ぶためです。

autofacは非常に柔軟性があり、自分に合った構文を持っているので個人的に好みます（ただし、すべての登録メソッドが拡張メソッドであることは本当に嫌いです）。

他のいくつかのフレームワーク：

• https://simpleinjector.org/
• http://microioc.codeplex.com/
• http://munq.codeplex.com/
• http://funq.codeplex.com/

まあ、私がこれまでに見つけた最良の比較を見回した後、次のとおりです。

• http://www.sturmnet.org/blog/2010/03/04/poll-ioc-containers-for-net

• http://www.sturmnet.org/blog/2010/03/04/poll-results-ioc-containers-for-net

2010年3月に行われた投票です。

私にとって興味深い点の1つは、DI / IoCフレームワークを使用していて、フレームワークが好き/嫌いだった人々が、StructureMapを最上位に表示しているように見えることです。

また、投票結果から、Castle.WindsorとStructureMapが最も支持されているようです。

興味深いことに、UnityとSpring.Netは最も一般的に嫌われる人気のあるオプションのようです。（私は怠惰（およびMicrosoftバッジ/サポート）からUnityを検討していましたが、今はキャッスルウィンザーとストラクチャーマップをさらに詳しく見ていきます。）

もちろん、これはおそらく（？）2010年5月にリリースされたUnity 2.0には当てはまりません。

うまくいけば、他の誰かが直接の経験に基づいて比較を行うことができます。

このテキストを書いている間、リストにないlinfuとspring.netを含むGoogleコードのnet-ioc-frameworksの比較については、を参照してください。

私はspring.netを使用しました：これには多くの機能（aop、libraries、docuなど）があり、dotnetとjava-worldでの経験はたくさんあります。機能はモジュール化されているため、すべての機能を使用する必要はありません。機能は、データベース抽象化、ロギング抽象化などの一般的な問題を抽象化したものです。ただし、IoC構成を実行してデバッグすることは困難です。

これまでに読んだことから：小規模または中規模のプロジェクトを選択する必要があった場合、ioc構成が行われ、c＃でデバッグできるため、ninjectを使用します。しかし、私はまだそれを扱っていません。大規模なモジュール式システムの場合、抽象化ライブラリーがあるため、spring.netのままにします。