Примеры контейнеров IoC

Ответ 1

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

Предположим, вы создали веб-сайт, который будет принимать платежи через PayPal. PayPal теперь является зависимым. Но вы не хотите кодировать конкретного провайдера PayPal.

Вместо этого вы должны создавать и кодировать интерфейс, подобный этому.

interface IPaymentProcessor
{
      bool ProcessPayment(amount, ....);
}

Весь ваш код PayPal будет находиться в классе, который реализует методы вашего интерфейса. PayPalPaymentProcessor например

Теперь у вас есть объект, который вы фактически будете использовать для обработки платежей. Это может быть контроллер (asp.net-mvc, ViewModel-wpf) или просто класс, как показано здесь.

class PaymentProcessor
{
    private IPaymentProcessor _processor = null;
    public PaymentProcessor(IPaymentProcessor processor)
    {
        _processor = processor;
    }

    public bool ProcessTransaction(Transaction trans)
    {
       _processor.ProcessPayment(trans.amount, ...);
    }
}

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

PaymentProcessor processor = ObjectFactory.GetInstance<PaymentProcessor>();

Этот фрагмент кода указывает на структуру структуры. Каждый раз, когда вы видите конструктор, который нуждается в IPaymentProcessor, верните новый PayPalPaymentProcessor ".

ObjectFactory.Initialize(x =>
{ 
 x.ForRequestedType<IPaymentProcessor>().TheDefaultIsConcreteType<PayPalPaymentProcessor>();
});

Все это сопоставление отдельно от вашего кода реализации, и вы можете поменять их на более позднем этапе с небольшим рефакторингом. Для IoCs намного больше, но это базовая концепция. Вы можете автоматизировать инъекцию конструкторов, чтобы избежать вызовов непосредственно в ObjectFactory.

Надеюсь, это поможет!

Ответ 2

Помните о следующих ограничениях контейнера IOC. Я должен предупреждать людей, потому что я живу с чертой поддержки системы, использующей ее:

• Исключения, вызванные конструкторами, проглатываются. Вы получаете только исключение "can not create dependency". Это означает, что вы не можете ловить ожидаемые исключения, если он вставляет конструктор.
• Невозможно выполнить конструкторы.
• Забывание регистрации интерфейса прерывается во время выполнения вместо времени компиляции.
• Все ваши классы могут иметь только один конструктор, и все они должны принимать интерфейсы в качестве параметров.
• Все зависимости создаются так, что вы не можете использовать экземпляры экземпляров, что означает, что использование вашей памяти может быстро увеличиться.
• Это способствует множеству взаимозависимостей, которые могут скрыть тот факт, что вы превратили код в спагетти. Упрощение установки всех этих взаимозависимостей просто маскирует, что существует потенциальная проблема.
• Вы не можете управлять своей "Группой работы" очень легко, потому что вы не можете управлять транзакцией через несколько зависимостей, так как у вас не было контроля над их копированием и передачей в контексте этой транзакции.

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

Ответ 3

Если вы хотите увидеть контейнер IoC под капотом, а также точку (Dependency Injection), там есть большой подкаст на DNR TV (Episode 126), который действительно подробно рассказывает о том, как их создавать, почему они вам нужны. Это действительно замечательный подкаст. Когда вы просмотрите это видео, вы сможете посмотреть Unity, Ninject, StructureMap и т.д. и сможете понять, что они делают

Ответ 4

Отметьте Spring IoC (.net) контейнер java/.net. Документация неплохое введение.

Вкратце: Вы можете думать о IoC как о архитектуре, которая поощряет: составление объектов и программирование на интерфейс.

Это дает вам следующее:

• возможность unit test вашего кода легко (вы можете легко тестировать свои объекты изолированно, издеваясь над всеми его зависимостями).

• Чрезвычайно продвинутая конфигурация (потому что ваша программа с IoC - это просто куча объектов и конфигурация, которая склеивает объекты вместе).

• Возможность расширения или изменения байтового скомпилированного приложения (это верно для Java, я не уверен, что это верно для .net).

Ответ 5

Мы используем Ninject из-за его простого API и быстрого разрешения объектов. Он очень хорошо документирован и использует возможности С# 3.0, такие как лямбда-выражения, чтобы упростить спецификацию.

Вы можете найти несколько скринкастов в Ninject здесь

Ответ 6

Обычно я использую StructureMap - в основном потому, что я знаком с синтаксисом. Я также слышал хорошие вещи о autofac, и я с нетерпением жду возможности опробовать Ninject, когда он попадает в v2.

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

Ответ 7

Вы пытаетесь создать контейнер IoC, почему бы не использовать один из доступных, например Spring.NET, StructureMap или Unity Application Block? Здесь - список проектов IoC с открытым исходным кодом

Ответ 8

Попробуйте прочитать Введение в блок приложений Unity и в ASP.NET StoreFront: Injection Dependency screencast вы можете увидеть больше о концепциях инъекций зависимостей.

Ответ 9

Я использую Unity для моего контейнера IoC, но разница между контейнерами заключается в том, что вы можете сделать с DI.

DI (Dependency Injection) - это, в основном, способ получить более свободную связь между разрозненными частями вашей программы. Итак, если вы написали игру, в которой вам нравится, как она работает, используя DI, вы можете изменить символы или физический движок в игре, не изменяя другие части игры, поэтому, если кто-то платит больше денег, они получают более реалистичный движок, или лучшими персонажами, но поскольку ничего другого не меняется, тестирование проще.

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

Если вы используете Spring.NET, например, вы получите доступ к очень мощной структуре, но это может сделать многое, что вы не будете использовать, поэтому ищите что-то меньшее. Я считаю, что лучшим правилом является поиск наименьшей, самой простой реализации, которая отвечает вашим потребностям и использует ее.