Корпоративная библиотека Unity vs Other IoC Containers

Ответ 1

Я готовлю презентацию для группы. Таким образом, я просто прошел через их группу. А именно: AutoFac, MEF, Ninject, Spring.Net, StructureMap, Unity и Windsor.

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

Таким образом, существует несколько ключевых отличий:

• Инициализация
• Поиск объектов

У каждого из них есть и другие функции (у некоторых есть AOP и лучшие вещицы, но, как правило, все, что я хочу сделать, это создавать и извлекать объекты для меня)

Примечание: различия между поиском объектов разных библиотек можно скрыть с помощью CommonServiceLocator: http://www.codeplex.com/CommonServiceLocator

Это оставляет нам инициализацию, которая выполняется двумя способами: через код или через конфигурацию XML (app.config/web.config/custom.config). Некоторые поддерживают оба, некоторые поддерживают только один. Я должен отметить: некоторые используют атрибуты, чтобы помочь IoC.

Итак, вот моя оценка различий:

Ninject

Только инициализация кода (с атрибутами). Надеюсь, тебе нравятся лямбды. Код инициализации выглядит следующим образом:

 IKernel kernel = new StandardKernel(
                new InlineModule(
                    x => x.Bind<ICustomerRepository>().To<CustomerRepository>(),
                    x => x.Bind<ICustomerService>().To<CustomerService>(),
                    x => x.Bind<Form1>().ToSelf()
                    ));

StructureMap

Код инициализации или XML или атрибуты. v2.5 также очень лямбдаи. В общем, это один из моих любимых. Некоторые очень интересные идеи о том, как StructureMap использует атрибуты.

ObjectFactory.Initialize(x =>
{
    x.UseDefaultStructureMapConfigFile = false;
    x.ForRequestedType<ICustomerRepository>()
        .TheDefaultIsConcreteType<CustomerRepository>()
        .CacheBy(InstanceScope.Singleton);

    x.ForRequestedType<ICustomerService>()
        .TheDefaultIsConcreteType<CustomerService>()
        .CacheBy(InstanceScope.Singleton);

    x.ForConcreteType<Form1>();
 });

Unity

Инициализационный код и XML. Хорошая библиотека, но конфигурация XML - это боль в прикладе. Отличная библиотека для Microsoft или шоссейных магазинов. Инициализация кода проста:

 container.RegisterType<ICustomerRepository, CustomerRepository>()
          .RegisterType<ICustomerService, CustomerService>();

Spring.NET

XML только как можно ближе. Но для функциональности Spring.Net делает все под солнцем, которое может сделать IoC. Но поскольку единственный способ унифицировать это через XML, его обычно избегают магазины .net. Хотя, многие .net/Java-магазин используют Spring.Net из-за сходства между .net-версией проекта Spring.Net и Java Spring.

Примечание. Конфигурация в коде теперь возможна с введением Spring.NET CodeConfig.

Windsor

XML и код. Подобно Spring.Net, Windsor сделает все, что вы можете пожелать. Виндзор, вероятно, является одним из самых популярных контейнеров IoC.

IWindsorContainer container = new WindsorContainer();
container.AddComponentWithLifestyle<ICustomerRepository, CustomerRepository>("CustomerRepository", LifestyleType.Singleton);
container.AddComponentWithLifestyle<ICustomerService, CustomerService>("CustomerService",LifestyleType.Singleton);
container.AddComponent<Form1>("Form1");

Autofac

Может смешивать как XML, так и код (с v1.2). Хорошая простая библиотека IoC. Кажется, делать основы с не очень суетным. Поддерживает вложенные контейнеры с локальным определением компонентов и четко определенным временем жизни.

Вот как вы его инициализировали:

var builder = new ContainerBuilder();
builder.Register<CustomerRepository>()
        .As<ICustomerRepository>()
        .ContainerScoped();
builder.Register<CustomerService>()
        .As<ICustomerService>()
        .ContainerScoped();
builder.Register<Form1>();

Если бы мне пришлось выбирать сегодня: я бы, вероятно, пошел с StructureMap. Он имеет лучшую поддержку языковых функций С# 3.0 и большую гибкость при инициализации.

Примечание. Крис Брандсма включил свой оригинальный ответ в сообщение .

Ответ 2

Насколько я видел, они почти одинаковы, за исключением нескольких деталей реализации здесь и там. Самое большое преимущество, которое Unity имеет в конкуренции, заключается в том, что оно предоставляется Microsoft, есть много компаний, которые боятся OSS.

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

Сказав это, вы можете проверить это.

Ответ 3

Старый поток, но поскольку это первое, что показал мне Google, когда я набрал единство против spring.net...

Spring делает CodeConfig сейчас, если вам не нравится XML config

http://www.springframework.net/codeconfig/doc-latest/reference/html/

Кроме того, Spring намного больше, чем просто контейнер DI, если вы посмотрите раздел "Модули" в документах, контейнер DI является основой огромного множества вещей, которые он делает.

Ответ 4

Исправьте меня, если я ошибаюсь, но я думаю, что Autofac сам поддерживает конфигурацию XML, указанную в этой ссылке: Конфигурация XML Autofac

Ответ 5

Spring имеет одну функцию, которая может вставлять параметры в конструктор или свойство, основанное на имени или позиции параметра. Это очень полезно, если параметр или свойство является простым типом (например, целое число, логическое значение). См. пример здесь. Я не думаю, что это действительно компенсирует Spring невозможность выполнить конфигурацию в коде.

Windsor также может это сделать и может делать это в коде не config. (исправьте меня, если я ошибаюсь, я просто иду через то, что я здесь слышал).

Я хотел бы знать, сможет ли Unity сделать это.

Ответ 6

Одно замечание: Ninject - единственный контейнер IoC, который поддерживает инъекции контекстной зависимости (в соответствии с их веб-сайтом). Однако, поскольку у меня нет опыта работы с другими контейнерами IoC, я не могу сказать, поддерживает ли это.

Ответ 7

Просто чтобы добавить мои 2 цента, я попробовал как StructureMap, так и Unity. Я обнаружил, что StructureMap плохо документирован/плохо описана, боль в прикладе для настройки и неуклюжая в использовании. Аналогично, он, похоже, не поддерживает сценарии, такие как переопределение аргументов конструктора во время разрешения, что было ключевым моментом использования для меня. Поэтому я бросил его и пошел с Unity, и он делал то, что хотел, примерно через 20 минут.

Ответ 8

Я лично использую Unity, но только потому, что это от Microsoft. Я сожалею о решении по одной причине: самая большая вещь, которую он имеет против, имеет одну большую "ошибку", которая заставляет ее постоянно выдавать исключения. Вы можете игнорировать исключения во время отладки. Тем не менее это замедляет ваше приложение чрезвычайно, если вы столкнетесь с ним, поскольку бросание исключения - дорогостоящая операция. Например, я в настоящее время "исправляю" это исключение в одном месте в моем коде, где исключения Unity добавляют дополнительные 4 секунды к времени визуализации страницы. Для получения дополнительной информации и обходного пути см.

Можно ли заставить Unity не генерировать SynchronizationLockException все время?