Как сравниваются основные платформы C # DI / IoC? [закрыто]

С риском вступления на территорию священной войны, каковы сильные и слабые стороны этих популярных систем DI / IoC, и можно ли их легко назвать лучшей? ..:

• Ninject
• Единство
• Castle.Windsor
• Autofac
• StructureMap

Существуют ли еще какие-либо рамки DI / IoC для C #, которые я не перечислил здесь?

В контексте моего варианта использования я создаю клиентское приложение WPF и инфраструктуру служб WCF / SQL, простоту использования (особенно с точки зрения ясного и краткого синтаксиса), согласованную документацию, хорошую поддержку сообщества и производительность - все это важные факторы по моему выбору.

Обновить:

Упомянутые ресурсы и повторяющиеся вопросы, по-видимому, устарели. Может ли кто-нибудь, обладающий знаниями обо всех этих рамках, выступить с реальными знаниями?

Я понимаю, что большинство мнений по этому вопросу, вероятно, будет предвзятым, но я надеюсь, что кто-то нашел время, чтобы изучить все эти рамки и провести хотя бы в целом объективное сравнение.

Я вполне готов провести собственное расследование, если это не было сделано ранее, но я предположил, что это было кое-что, по крайней мере, несколько человек уже сделали.

Второе обновление:

Если у вас есть опыт работы с несколькими контейнерами DI / IoC, пожалуйста, оцените и суммируйте все за и против, спасибо. Это не упражнение в обнаружении всех неясных маленьких контейнеров, которые сделали люди, я ищу сравнения между популярными (и активными) фреймворками.

Несмотря на то, что исчерпывающий ответ на этот вопрос занимает сотни страниц моей книги , я приведу краткий сравнительный график, над которым я все еще работаю:

Я столкнулся с другим сравнением производительности (последнее обновление 10 апреля 2014 года). Сравнивает следующее:

• AutoFac
• LightCore (сайт на немецком языке)
• Линьфу
• Ninject
• маленькая
• Простой Инжектор (самый быстрый из всех участников)
• Spring.NET
• StructureMap
• Единство
• Виндзор
• Хиро

Вот краткое резюме из поста:

Вывод

Ninject, безусловно, самый медленный контейнер.

MEF, LinFu и Spring.NET быстрее, чем Ninject, но все еще довольно медленно. Далее идут AutoFac, Catel и Windsor, за которыми следуют StructureMap, Unity и LightCore. Недостатком Spring.NET является то, что он может быть настроен только с XML.

SimpleInjector, Hiro, Funq, Munq и Dynamo предлагают лучшую производительность, они чрезвычайно быстры. Дай им попробовать!

Особенно прост Injector, кажется, хороший выбор. Он очень быстрый, имеет хорошую документацию, а также поддерживает сложные сценарии, такие как перехват и общие декораторы.

Вы также можете попробовать использовать библиотеку Common Service Selector Library и, надеюсь, попробовать несколько вариантов и посмотреть, что подходит вам лучше всего.

Некоторая информация о Common Service Selector Library с сайта:

Библиотека предоставляет абстракцию над контейнерами IoC и локаторами служб. Использование библиотеки позволяет приложению косвенно обращаться к возможностям, не полагаясь на жесткие ссылки. Надежда состоит в том, что с помощью этой библиотеки сторонние приложения и платформы могут начать использовать IoC / расположение службы без привязки к конкретной реализации.

Обновить

13.09.2011: Funq и Munq были добавлены в список участников. Графики также были обновлены, и Spring.NET был удален из-за его низкой производительности.

04.11.2011: «добавлен Simple Injector , производительность лучшая из всех конкурсантов».

Просто прочитайте этот замечательный блог сравнения сетей .Net DI от Филиппа Мата.

Он делает некоторые тщательные тесты сравнения производительности;

• Autofac
• StructureMap
• Ninject
• Единство
• Castle.Windsor
• Spring.Net

Он рекомендует Autofac, так как он маленький, быстрый и простой в использовании ... Я согласен. Похоже, что Unity и Ninject самые медленные в его тестах.

Отказ от ответственности: По состоянию на начало 2015, существует большое сравнение 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 <,> легко)
• Настройка для нескольких регистраций открытых дженериков (два или более 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;
}

• Открытые дженерики: да, неявно
• Несколько открытых дженериков: да, с пользовательским расширением
• Общая контравариантность: сумасшедший

Виндзор

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

• Открытые дженерики: да, неявно
• Несколько открытых дженериков: да, неявно
• Общая противоположность: да, с пользовательским расширением

На самом деле существует множество платформ IoC. Кажется, что каждый программист пытается написать один в какой-то момент своей карьеры. Может быть, не публиковать его, но изучить внутреннюю работу.

Лично я предпочитаю 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 года.

Меня интересует то, что люди, которые использовали DI / IoC Framework и любили / не любили его, StructureMap, кажется, выходят на первое место.

Также из опроса кажется, что Castle.Windsor и StructureMap оказываются наиболее популярными.

Интересно, что Unity и Spring.Net кажутся популярными опциями, которые обычно не нравятся . (Я рассматривал Unity из-за лени (и значка / поддержки Microsoft), но сейчас я более подробно рассмотрю Castle Windsor и StructureMap.)

Конечно, это (?) Не относится к Unity 2.0, выпущенному в мае 2010 года.

Надеюсь, кто-то еще может дать сравнение, основанное на непосредственном опыте.

Смотрите для сравнения net-ioc-frameworks в коде Google, включая linfu и spring.net, которых нет в вашем списке, пока я пишу этот текст.

Я работал с spring.net: у него много функций (aop, library, document, ...), и есть большой опыт работы с ним в dotnet и java-мире. Функции являются модульными, поэтому вам не нужно брать все функции. Функции представляют собой абстракции общих вопросов, таких как абстракция базы данных, абстракция логирования. однако сложно и отладить IoC-конфигурацию.

Из того, что я прочитал до сих пор: если бы мне пришлось выбирать для небольшого или среднего проекта, я бы использовал ninject, так как ioc-конфигурация выполнена и отлаживаема в c #. Но я еще не работал с этим. для большой модульной системы я бы остановился на spring.net из-за абстракционных библиотек.