Зачем мне нужен контейнер IoC, а не простой код DI?

Вау, не могу поверить, что Джоэл одобрит это:

var svc = new ShippingService(new ProductLocator(), 
   new PricingService(), new InventoryService(), 
   new TrackingRepository(new ConfigProvider()), 
   new Logger(new EmailLogger(new ConfigProvider())));

через это:

var svc = IoC.Resolve<IShippingService>();

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

Да, контейнеры IoC могут быть сложными. Но в этом простом случае я показал, что это невероятно просто.

Хорошо, давайте еще больше оправдаем это. Допустим, у вас есть некоторые сущности или объекты модели, которые вы хотите привязать к интеллектуальному пользовательскому интерфейсу. Этот умный пользовательский интерфейс (назовем его Shindows Morms) требует, чтобы вы реализовали INotifyPropertyChanged, чтобы он мог отслеживать изменения и соответствующим образом обновлять пользовательский интерфейс.

«Хорошо, это звучит не так уж сложно», и вы начинаете писать.

Вы начинаете с этого:

public class Customer
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public DateTime CustomerSince { get; set; }
    public string Status { get; set; }
}

..и получится это:

public class UglyCustomer : INotifyPropertyChanged
{
    private string _firstName;
    public string FirstName
    {
        get { return _firstName; }
        set
        {
            string oldValue = _firstName;
            _firstName = value;
            if(oldValue != value)
                OnPropertyChanged("FirstName");
        }
    }

    private string _lastName;
    public string LastName
    {
        get { return _lastName; }
        set
        {
            string oldValue = _lastName;
            _lastName = value;
            if(oldValue != value)
                OnPropertyChanged("LastName");
        }
    }

    private DateTime _customerSince;
    public DateTime CustomerSince
    {
        get { return _customerSince; }
        set
        {
            DateTime oldValue = _customerSince;
            _customerSince = value;
            if(oldValue != value)
                OnPropertyChanged("CustomerSince");
        }
    }

    private string _status;
    public string Status
    {
        get { return _status; }
        set
        {
            string oldValue = _status;
            _status = value;
            if(oldValue != value)
                OnPropertyChanged("Status");
        }
    }

    protected virtual void OnPropertyChanged(string property)
    {
        var propertyChanged = PropertyChanged;

        if(propertyChanged != null)
            propertyChanged(this, new PropertyChangedEventArgs(property));
    }

    public event PropertyChangedEventHandler PropertyChanged;
}

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

Вы когда-нибудь слышали этот термин, работайте умнее, а не усерднее?

Представьте себе, что какой-то умный парень из вашей команды подошел и сказал: «Вот способ попроще».

Если вы сделаете свои свойства виртуальными (успокойтесь, это не так уж важно), тогда мы сможем вплетать в поведение этого свойства автоматически. (Это называется АОП, но не беспокойтесь о названии, сосредоточьтесь на том, что он сделает для вас)

В зависимости от того, какой инструмент IoC вы используете, вы можете сделать что-то вроде этого:

var bindingFriendlyInstance = IoC.Resolve<Customer>(new NotifyPropertyChangedWrapper());

Пуф! Вся эта ручная BS INotifyPropertyChanged теперь автоматически генерируется для вас на каждом средстве установки виртуальных свойств рассматриваемого объекта.

Это волшебство? ДА! Если вы можете доверять тому факту, что этот код выполняет свою работу, вы можете спокойно пропустить все это свойство, обертывающее мумбо-джамбо. Вам нужно решить бизнес-проблемы.

Некоторые другие интересные варианты использования инструмента IoC для АОП:

• Декларативные и вложенные транзакции базы данных
• Декларативная и вложенная единица работы
• логирование
• Условия до / после (Дизайн по контракту)

Я с тобой, Вадим. Контейнеры IoC используют простую, элегантную и полезную концепцию и делают ее тем, что вам нужно изучать в течение двух дней с помощью руководства на 200 страниц.

Я лично недоумеваю, как сообщество IoC восприняло красивую, элегантную статью Мартина Фаулера и превратил его в кучу сложных фреймворков, обычно с руководствами на 200–300 страниц.

Я стараюсь не осуждать (ХАХА!), Но я думаю, что люди, использующие контейнеры IoC, (А) очень умны и (Б) не сочувствуют людям, которые не так умны, как они. Для них все имеет смысл, поэтому им трудно понять, что многие обычные программисты сочтут эти концепции запутанными. Это проклятие знаний. Людям, разбирающимся в контейнерах IoC, трудно поверить, что есть люди, которые этого не понимают.

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

Я считаю, что если вы используете контейнеры IoC, ваш код, честно говоря, станет намного труднее читать. Количество мест, на которые вы должны смотреть, чтобы понять, что пытается сделать код, увеличивается как минимум на одно. И где-то на небесах ангел кричит.

По-видимому, никто не заставляет вас использовать фреймворк контейнера DI. Вы уже используете DI для разделения классов и улучшения тестируемости, поэтому вы получаете множество преимуществ. Короче говоря, вы предпочитаете простоту, что в целом хорошо.

Если ваша система достигает уровня сложности, когда ручное DI становится рутиной (то есть увеличивает обслуживание), сравните это с кривой обучения команды контейнерной инфраструктуры DI.

Если вам нужен больший контроль над управлением временем жизни зависимостей (то есть, если вы чувствуете необходимость реализовать шаблон Singleton), посмотрите на контейнеры DI.

Если вы используете контейнер DI, используйте только те функции, которые вам нужны. Пропустите файл конфигурации XML и настройте его в коде, если этого достаточно. Придерживайтесь внедрения конструктора. Основы Unity или StructureMap можно сократить до пары страниц.

По этому поводу есть отличное сообщение в блоге Марка Симанна: Когда использовать контейнер DI

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

Если вы в настоящее время используете инъекцию зависимостей, ваш код может выглядеть следующим образом

public class CustomerPresenter
{
  public CustomerPresenter() : this(new CustomerView(), new CustomerService())
  {}

  public CustomerPresenter(ICustomerView view, ICustomerService service)
  {
    // init view/service fields
  }
  // readonly view/service fields
}

Если вы использовали статический класс IoC, а не, IMHO, более запутанные файлы конфигурации, у вас могло бы быть что-то вроде этого:

public class CustomerPresenter
{
  public CustomerPresenter() : this(IoC.Resolve<ICustomerView>(), IoC.Resolve<ICustomerService>())
  {}

  public CustomerPresenter(ICustomerView view, ICustomerService service)
  {
    // init view/service fields
  }
  // readonly view/service fields
}

Тогда ваш статический класс IoC будет выглядеть так: здесь я использую Unity.

public static IoC
{
   private static readonly IUnityContainer _container;
   static IoC()
   {
     InitializeIoC();
   }

   static void InitializeIoC()
   {
      _container = new UnityContainer();
      _container.RegisterType<ICustomerView, CustomerView>();
      _container.RegisterType<ICustomerService, CustomerService>();
      // all other RegisterTypes and RegisterInstances can go here in one file.
      // one place to change dependencies is good.
   }
}

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

public void GetPresenter()
{
    var presenter = new CustomerPresenter(new CustomerService(new CustomerRepository(new DB())));
}

class CustomerPresenter
{
    private readonly ICustomerService service;
    public CustomerPresenter(ICustomerService service)
    {
        this.service = service;
    }
}

class CustomerService
{
    private readonly IRespository<Customer> repository;
    public CustomerService(IRespository<Customer> repository)
    {
        this.repository = repository;
    }
}

class CustomerRepository : IRespository<Customer>
{
    private readonly DB db;
    public CustomerRepository(DB db)
    {
        this.db = db;
    }
}

class DB { }

Если у вас были загружены все эти зависимости и контейнер IoC, вы можете разрешить CustomerService, и все дочерние зависимости будут автоматически разрешены.

Например:

public static IoC
{
   private IUnityContainer _container;
   static IoC()
   {
       InitializeIoC();
   }

   static void InitializeIoC()
   {
      _container = new UnityContainer();
      _container.RegisterType<ICustomerService, CustomerService>();
      _container.RegisterType<IRepository<Customer>, CustomerRepository>();
   }

   static T Resolve<T>()
   {
      return _container.Resolve<T>();
   }
}

public void GetPresenter()
{
   var presenter = IoC.Resolve<CustomerPresenter>();
   // presenter is loaded and all of its nested child dependencies 
   // are automatically injected
   // -
   // Also, note that only the Interfaces need to be registered
   // the concrete types like DB and CustomerPresenter will automatically 
   // resolve.
}

Я фанат декларативного программирования (посмотрите, на сколько вопросов по SQL я отвечаю), но контейнеры IoC, на которые я смотрел, кажутся слишком загадочными для их же пользы.

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

... или оба в той или иной степени верны.

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

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

Использование контейнера в основном связано с переходом от императивного / скриптового стиля инициализации и конфигурации к декларативному. Это может иметь несколько различных положительных эффектов:

• Сокращение количества процедур запуска основной программы hairball.
• Обеспечение достаточно глубоких возможностей реконфигурации во время развертывания.
• Сделать стиль с внедрением зависимостей путем наименьшего сопротивления для новой работы.

Конечно, могут возникнуть сложности:

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

Мне кажется, что вы уже создали свой собственный контейнер IoC (используя различные шаблоны, описанные Мартином Фаулером) и спрашиваете, почему чья-то реализация лучше вашей.

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

Плюсы при выборе стороннего контейнера IoC

• Вы получаете исправление ошибок бесплатно
• Дизайн библиотеки может быть лучше вашего
• Люди могут быть уже знакомы с конкретной библиотекой
• Библиотека может быть быстрее вашей
• В нем могут быть некоторые функции, которые вы хотели бы реализовать, но у вас никогда не было времени (у вас есть средство поиска сервисов?)

Минусы

• Вы получаете сообщения об ошибках бесплатно :)
• Дизайн библиотеки может быть хуже вашего
• Вы должны изучить новый API
• Слишком много функций, которыми вы никогда не воспользуетесь
• Обычно сложнее отлаживать код, который вы не писали
• Переход с предыдущего контейнера IoC может быть утомительным

Итак, взвесьте все за и против и примите решение.

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

Полученное вами значение будет зависеть от типа приложения, над которым вы работаете:

• Для мультитенантности контейнер IoC может позаботиться о некотором коде инфраструктуры для загрузки различных клиентских ресурсов. Когда вам нужен компонент, специфичный для клиента, используйте настраиваемый селектор для обработки логики и не беспокойтесь об этом из своего клиентского кода. Вы, конечно, можете построить это самостоятельно, но вот пример того, как IoC может помочь.

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

• Если вы хотите использовать АОП для решения общих задач, IoC предоставляет перехватчики для перехвата вызовов методов. Реже это делается специально для проектов, но IoC упрощает эту задачу.

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

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

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

Я выздоравливающий наркоман МОК. В наши дни мне трудно оправдать использование IOC для DI. Контейнеры IOC жертвуют проверкой времени компиляции и якобы взамен дают вам «легкую» настройку, сложное управление временем жизни и обнаружение зависимостей на лету во время выполнения. Я считаю, что потеря проверки времени компиляции и возникающие в результате магические действия / исключения во время выполнения в подавляющем большинстве случаев не стоят наворотов. В крупных корпоративных приложениях они могут затруднить отслеживание того, что происходит.

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

Почему бы не сделать статический DI без магии вот так:

interface IServiceA { }
interface IServiceB { }
class ServiceA : IServiceA { }
class ServiceB : IServiceB { }

class StubServiceA : IServiceA { }
class StubServiceB : IServiceB { }

interface IRoot { IMiddle Middle { get; set; } }
interface IMiddle { ILeaf Leaf { get; set; } }
interface ILeaf { }

class Root : IRoot
{
    public IMiddle Middle { get; set; }

    public Root(IMiddle middle)
    {
        Middle = middle;
    }

}

class Middle : IMiddle
{
    public ILeaf Leaf { get; set; }

    public Middle(ILeaf leaf)
    {
        Leaf = leaf;
    }
}

class Leaf : ILeaf
{
    IServiceA ServiceA { get; set; }
    IServiceB ServiceB { get; set; }

    public Leaf(IServiceA serviceA, IServiceB serviceB)
    {
        ServiceA = serviceA;
        ServiceB = serviceB;
    }
}


interface IApplicationFactory
{
    IRoot CreateRoot();
}

abstract class ApplicationAbstractFactory : IApplicationFactory
{
    protected abstract IServiceA ServiceA { get; }
    protected abstract IServiceB ServiceB { get; }

    protected IMiddle CreateMiddle()
    {
        return new Middle(CreateLeaf());
    }

    protected ILeaf CreateLeaf()
    {
        return new Leaf(ServiceA,ServiceB);
    }


    public IRoot CreateRoot()
    {
        return new Root(CreateMiddle());
    }
}

class ProductionApplication : ApplicationAbstractFactory
{
    protected override IServiceA ServiceA
    {
        get { return new ServiceA(); }
    }

    protected override IServiceB ServiceB
    {
        get { return new ServiceB(); }
    }
}

class FunctionalTestsApplication : ApplicationAbstractFactory
{
    protected override IServiceA ServiceA
    {
        get { return new StubServiceA(); }
    }

    protected override IServiceB ServiceB
    {
        get { return new StubServiceB(); }
    }
}


namespace ConsoleApplication5
{
    class Program
    {
        static void Main(string[] args)
        {
            var factory = new ProductionApplication();
            var root = factory.CreateRoot();

        }
    }

    //[TestFixture]
    class FunctionalTests
    {
        //[Test]
        public void Test()
        {
            var factory = new FunctionalTestsApplication();
            var root = factory.CreateRoot();
        }
    }
}

Конфигурация вашего контейнера - это ваша абстрактная реализация фабрики, ваши регистрации - это реализации абстрактных членов. Если вам нужна новая одноэлементная зависимость, просто добавьте еще одно абстрактное свойство в абстрактную фабрику. Если вам нужна временная зависимость, просто добавьте еще один метод и вставьте его как Func ‹>.

Преимущества:

• Все настройки и настройки создания объектов централизованы.
• Конфигурация - это просто код
• Проверка времени компиляции упрощает обслуживание, так как вы не можете забыть обновить свои регистрации.
• Никакой магии отражения во время выполнения

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

Самым большим преимуществом использования контейнеров IoC для меня (лично я использую Ninject) было устранение передачи настроек и других типов объектов глобального состояния.

Я не программирую для Интернета, у меня консольное приложение, и во многих местах глубоко в дереве объектов мне нужен доступ к настройкам или метаданным, указанным пользователем, которые создаются в совершенно отдельной ветви дерева объектов. С помощью IoC я просто говорю Ninject рассматривать Настройки как единичный объект (потому что всегда есть только один их экземпляр), запрашиваю Настройки или Словарь в конструкторе и готово ... они волшебным образом появляются, когда они мне нужны!

Без использования контейнера IoC мне пришлось бы передать настройки и / или метаданные через 2, 3, ..., n объектов, прежде чем они будут фактически использованы объектом, который в них нуждался.

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

Фреймворки IoC отлично подходят, если вы хотите ...

• ... выбросить безопасность типа. Многие (все?) Фреймворки IoC заставляют вас выполнять код, если вы хотите быть уверенным, что все подключено правильно. «Эй! Надеюсь, у меня все настроено, поэтому мои инициализации этих 100 классов не потерпят неудачу в производстве, вызывая исключения с нулевым указателем!»

• ... засоряйте свой код глобальными переменными (фреймворки IoC все предназначены для изменения глобальных состояний).

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

Проблема с IoC в том, что люди, которые их используют, раньше писали такой код.

public class Foo {
    public Bar Apa {get;set;}
    Foo() {
        Apa = new Bar();
    }
}

что явно ошибочно, поскольку зависимость между Foo и Bar жестко запрограммирована. Потом они поняли, что лучше писать такой код, как

public class Foo {
    public IBar Apa {get;set;}
    Foo() {
        Apa = IoC<IBar>();
    }
}

что также ошибочно, но менее очевидно. В Haskell тип Foo() будет IO Foo, но вам действительно не нужна IO-часть, и это должно быть предупреждающим знаком о том, что что-то не так с вашим дизайном, если вы его получили.

Чтобы избавиться от него (IO-части), получить все преимущества IoC-frameworks и ни одного из его недостатков, вы могли бы вместо этого использовать абстрактную фабрику.

Правильным решением будет что-то вроде

data Foo = Foo { apa :: Bar }

или, может быть

data Foo = forall b. (IBar b) => Foo { apa :: b }

и ввести (но я бы не назвал это инъекцией) Bar.

Также: посмотрите это видео с Эриком Мейджером (изобретателем LINQ), где он говорит, что DI предназначен для людей, не разбирающихся в математике (и я не могу с этим согласиться): http://www.youtube.com/watch?v=8Mttjyf-8P4

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

Я обнаружил, что правильная реализация внедрения зависимостей заставляет программистов использовать множество других методов программирования, которые помогают улучшить тестируемость, гибкость, ремонтопригодность и масштабируемость кода: такие практики, как принцип единой ответственности, разделение проблем и кодирование. против API. Такое ощущение, что я вынужден писать больше модульных классов и методов небольшого размера, что упрощает чтение кода, потому что его можно обрабатывать небольшими фрагментами.

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

var merger = new SimpleWorkflowInstanceMerger(
    new BitFactoryLog(typeof(SimpleWorkflowInstanceMerger).FullName), 
    new WorkflowAnswerRowUtil(
        new WorkflowFieldAnswerEntMapper(),
        new ActivityFormFieldDisplayInfoEntMapper(),
        new FieldEntMapper()),
    new AnswerRowMergeInfoRepository());

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

Потратив некоторое время на изучение ответов и комментариев по этому вопросу, я убежден, что люди, которые выступают против использования контейнера IoC, не практикуют истинную инъекцию зависимостей. Я видел примеры практик, которые обычно путают с внедрением зависимостей. Некоторые люди жалуются на трудности с «чтением» кода. Если все сделано правильно, подавляющая часть вашего кода должна быть идентична при использовании DI вручную, как при использовании контейнера IoC. Разница должна полностью заключаться в нескольких «точках запуска» внутри приложения.

Другими словами, если вам не нравятся контейнеры IoC, вы, вероятно, не выполняете внедрение зависимостей так, как предполагалось.

Еще один момент: внедрение зависимостей действительно невозможно сделать вручную, если вы где-то используете отражение. Хотя я ненавижу то, что отражение делает с навигацией по коду, вы должны признать, что есть определенные области, где этого действительно нельзя избежать. Например, ASP.NET MVC пытается создать экземпляр контроллера через отражение для каждого запроса. Чтобы выполнить внедрение зависимостей вручную, вам нужно сделать каждый контроллер «корнем контекста», например:

public class MyController : Controller
{
    private readonly ISimpleWorkflowInstanceMerger _simpleMerger;
    public MyController()
    {
        _simpleMerger = new SimpleWorkflowInstanceMerger(
            new BitFactoryLog(typeof(SimpleWorkflowInstanceMerger).FullName), 
            new WorkflowAnswerRowUtil(
                new WorkflowFieldAnswerEntMapper(),
                new ActivityFormFieldDisplayInfoEntMapper(),
                new FieldEntMapper()),
            new AnswerRowMergeInfoRepository())
    }
    ...
}

Теперь сравните это с тем, что инфраструктура DI может сделать это за вас:

public MyController : Controller
{
    private readonly ISimpleWorkflowInstanceMerger _simpleMerger;
    public MyController(ISimpleWorkflowInstanceMerger simpleMerger)
    {
        _simpleMerger = simpleMerger;
    }
    ...
}

Используя структуру DI, обратите внимание, что:

• Я могу провести модульное тестирование этого класса. Создав макет ISimpleWorkflowInstanceMerger, я могу проверить, используется ли он так, как я предполагаю, без необходимости подключения к базе данных или чего-то еще.
• Я использую гораздо меньше кода, и его гораздо легче читать.
• Если изменяется одна из моих зависимостей, мне не нужно вносить какие-либо изменения в контроллер. Это особенно приятно, если учесть, что несколько контроллеров могут использовать одни и те же зависимости.
• Я никогда явно не ссылаюсь на классы из моего уровня данных. Мое веб-приложение может просто включать ссылку на проект, содержащий интерфейс ISimpleWorkflowInstanceMerger. Это позволяет мне разбивать приложение на отдельные модули и поддерживать настоящую многоуровневую архитектуру, что, в свою очередь, делает вещи более гибкими.

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

Каждый раз, когда вы используете ключевое слово «new», вы создаете конкретную зависимость класса, и в вашей голове должен прозвучать сигнал тревоги. Становится труднее тестировать этот объект изолированно. Решение состоит в том, чтобы запрограммировать интерфейсы и внедрить зависимость, чтобы объект можно было модульно протестировать с помощью всего, что реализует этот интерфейс (например, имитирует).

Проблема в том, что вам нужно где-то строить объекты. Шаблон Factory - это один из способов избавиться от связывания ваших POXO (Plain Old "вставьте здесь свой объектно-ориентированный язык" Объекты). Если вы и ваши коллеги пишете такой код, то контейнер IoC - это следующее «дополнительное улучшение», которое вы можете внести в свою кодовую базу. Он уберет весь этот неприятный шаблонный код Factory из ваших чистых объектов и бизнес-логики. Они получат это и полюбят это. Черт возьми, расскажите компании, почему вам это нравится, и вызовите у всех энтузиазм.

Если ваши коллеги еще не занимаются DI, я предлагаю вам сначала сосредоточиться на этом. Расскажите, как писать чистый код, который легко тестировать. Чистый код DI - это сложная часть: как только вы там окажетесь, перенос логики подключения объектов из классов Factory в контейнер IoC должен быть относительно тривиальным.

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

Вам не нужен контейнер IoC.

Но если вы строго следуете шаблону DI, вы обнаружите, что его наличие удалит тонну избыточного и скучного кода.

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

Я просто так случайно выдернул самодельный код DI и заменил его на IOC. Я, вероятно, удалил более 200 строк кода и заменил его примерно 10. Да, мне пришлось немного узнать, как использовать контейнер (Winsor), но я инженер, работающий над интернет-технологиями в 21 век, так что я к этому привык. Я, наверное, потратил около 20 минут, просматривая инструкции. Это стоило моего времени.

По мере того как вы продолжаете отделять классы и инвертировать зависимости, классы продолжают оставаться небольшими, а «граф зависимостей» продолжает расти в размерах. (Это неплохо.) Использование основных функций контейнера IoC делает подключение всех этих объектов тривиальным, но выполнение этого вручную может оказаться очень обременительным. Например, что, если я хочу создать новый экземпляр «Foo», но ему нужен «Бар». А «Бар» нужны «А», «В» и «С». И каждому из них нужны еще 3 вещи и т. Д. (Да, я не могу придумать хороших фальшивых имен :)).

Использование контейнера IoC для построения графа объектов значительно снижает сложность и переводит ее в одноразовую конфигурацию. Я просто говорю «создайте мне« Фу »», и он выясняет, что нужно для его создания.

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

То же о Unity. Если стать слишком большим, можно услышать скрип стропил.

Меня никогда не удивляет, когда люди начинают рассуждать о том, насколько чистым выглядит код IoC, - это те же люди, которые когда-то говорили о том, что шаблоны на C ++ были элегантным способом вернуться в 90-е годы, но в настоящее время осуждают их как загадочные . Ба!

В мире .NET АОП не слишком популярен, поэтому для DI фреймворк - ваш единственный реальный вариант, независимо от того, пишете ли вы его сами или используете другой фреймворк.

Если вы использовали АОП, вы можете внедрить его при компиляции приложения, что чаще встречается в Java.

У DI есть много преимуществ, таких как уменьшение связи, что упрощает модульное тестирование, но как вы его реализуете? Вы хотите использовать отражение, чтобы сделать это самостоятельно?

Итак, прошло уже почти 3 года, а?

1. 50% тех, кто высказался в пользу фреймворков IoC, не понимают разницы между фреймворками IoC и IoC. Я сомневаюсь, что они знают, что вы можете писать код без развертывания на сервере приложений.

2. Если мы возьмем самый популярный фреймворк Java Spring, это конфигурация IoC, перенесенная из XMl в код и теперь выглядит так

`@Configuration общедоступный класс AppConfig {

public @Bean TransferService transferService() {
    return new TransferServiceImpl(accountRepository());
}

public @Bean AccountRepository accountRepository() {
    return new InMemoryAccountRepository();
}

} `И для этого нам нужен фреймворк, почему именно?

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

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

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

Кто сказал, что интерфейс все равно лучше наследования? Скажем, вы тестируете Сервис. Почему бы не использовать конструктор DI и не создавать имитации зависимостей с помощью наследования? Большинство служб, которые я использую, имеют лишь несколько зависимостей. Такой способ модульного тестирования предотвращает поддержку множества бесполезных интерфейсов и означает, что у вас нет необходимости для использования Resharper для быстрого поиска объявления метода.

Я считаю, что для большинства реализаций утверждение, что контейнеры IoC удаляют ненужный код, является мифом.

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

У кого-нибудь есть мысли по этому поводу?

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

Вот почему. Проект называется IOC-with-Ninject. Вы можете скачать и запустить его с помощью Visual Studio. В этом примере используется Ninject, но ВСЕ «новые» операторы находятся в одном месте, и вы можете полностью изменить способ работы вашего приложения, изменив используемый модуль привязки. Пример настроен так, что вы можете выполнить привязку к фиктивной версии служб или к реальной версии. В небольших проектах это может не иметь значения, но в больших проектах это важно.

Чтобы было ясно, преимущества, как я их вижу: 1) ВСЕ новые операторы в одном месте в корне кода. 2) Полностью модифицируйте код с одним изменением. 3) Дополнительные баллы за «крутой фактор», потому что это ... ну: круто. :п

Я попытаюсь понять, почему МОК может не подходить с моей точки зрения.

Как и все остальное, контейнер IOC (или, как выразился Эйнштейн, I = OC ^ 2) - это концепция, которую вы должны решить для себя, нужно вам это или нет в вашем коде. Недавний модный протест против МОК - это только мода. Не поддавайтесь моде, это первое. Существует множество концепций, которые вы можете реализовать в своем коде. Прежде всего, я использую внедрение зависимостей с тех пор, как начал программировать и выучил сам термин, когда он был популяризирован под этим именем. Контроль зависимостей - очень старая тема, и до сих пор к ней обращались триллионами способов, в зависимости от того, что отделялось от чего. Отсоединять все от всего - нонсенс. Проблема с контейнером IOC в том, что он пытается быть таким же полезным, как Entity Framework или NHibernate. Хотя создание объектно-реляционного сопоставителя просто необходимо, поскольку вам нужно связать любую базу данных с вашей системой, контейнер IOC не всегда необходим. Итак, когда контейнер IOC полезен:

1. Когда у вас есть ситуация с множеством зависимостей, вы хотите организовать
2. Когда вы не заботитесь о связывании вашего кода со сторонним продуктом
3. Когда ваши разработчики хотят научиться работать с новым инструментом

1: Это не так часто, что у вас есть так много зависимостей в вашем коде или вы знаете о них на ранней стадии проектирования. Абстрактное мышление полезно, когда необходимо абстрактное мышление.

2: Связывание вашего кода со сторонним кодом - проблема HuGe. Я работал с кодом, которому более 10 лет, и который следовал в то время модным и продвинутым концепциям ATL, COM, COM + и так далее. Теперь вы ничего не можете сделать с этим кодом. Я говорю о том, что продвинутая концепция дает очевидное преимущество, но в долгосрочной перспективе это отменяется из-за самого устаревшего преимущества. Это просто сделало все это дороже.

3: Разработка программного обеспечения достаточно сложна. Вы можете расширить его до неузнаваемых уровней, если позволите какой-то продвинутой концепции укорениться в вашем коде. Проблема с IOC2. Хотя это разъединяет зависимости, он также разъединяет логический поток. Представьте, что вы нашли ошибку и вам нужно установить перерыв, чтобы изучить ситуацию. IOC2, как и любая другая продвинутая концепция, усложняет эту задачу. Исправить ошибку в рамках концепции сложнее, чем исправить ошибку в более простом коде, потому что, когда вы исправляете ошибку, концепция должна быть соблюдена снова. (Чтобы привести вам пример, C ++ .NET постоянно меняет синтаксис настолько, что вам нужно хорошенько подумать, прежде чем рефакторинг какой-нибудь старой версии .NET.) Так в чем же проблема с IOC? Проблема в разрешении зависимостей. Логика решения обычно скрыта в самом IOC2, написана, возможно, необычным способом, который вам нужно изучить и поддерживать. Появится ли ваш сторонний продукт через 5 лет? Microsoft не было.

В отношении IOC2 повсюду пишут о синдроме «мы знаем как». Это похоже на автоматическое тестирование. Замечательный термин и на первый взгляд идеальное решение: вы просто запускаете все свои тесты в течение ночи и видите результаты утром. Действительно болезненно объяснять компании за компанией, что на самом деле означает автоматическое тестирование. Автоматическое тестирование определенно не является быстрым способом уменьшить количество ошибок, которые вы можете внести в одночасье для повышения качества вашего продукта. Но мода делает это понятие раздражающе доминирующим. IOC2 страдает тем же синдромом. Считается, что вам нужно внедрить его, чтобы ваше программное обеспечение было хорошим. В каждом недавнем интервью меня спрашивали, внедряю ли я IOC2 и автоматизацию. Это примета моды: у компании есть часть кода, написанная на MFC, от которой они не откажутся.

Вам необходимо изучить IOC2, как и любую другую концепцию программного обеспечения. Решение о том, нужно ли использовать IOC2, принимается командой и компанией. Однако перед принятием решения необходимо упомянуть как минимум ВСЕ приведенные выше аргументы. Только если вы видите, что положительная сторона перевешивает отрицательную, вы можете принять положительное решение.

В IOC2 нет ничего плохого, за исключением того, что он решает только те проблемы, которые он решает, и вводит проблемы, которые он создает. Ничего больше. Однако пойти против моды очень сложно, у них потный рот, приверженцы чего-либо. Странно, как никого из них нет, когда проблема с их причудливостью становится очевидной. Многие концепции в индустрии программного обеспечения были защищены, потому что они приносят прибыль, пишутся книги, проводятся конференции, создаются новые продукты. Это мода, обычно недолговечная. Как только люди находят что-то еще, они полностью от этого отказываются. IOC2 полезен, но он показывает те же признаки, что и многие другие исчезнувшие концепции, которые я видел. Не знаю, выживет ли оно. Для этого нет правила. Вы думаете, что если это будет полезно, оно выживет. Нет, так не бывает. Достаточно одной большой богатой компании, и концепция может умереть в течение нескольких недель. Посмотрим. NHibernate выжил, EF занял второе место. Может быть, IOC2 тоже выживет. Не забывайте, что большинство концепций в разработке программного обеспечения не имеют ничего особенного, они очень логичны, просты и очевидны, и иногда сложнее запомнить текущее соглашение об именах, чем понять саму концепцию. Делает ли знание IOC2 лучшим разработчиком? Нет, потому что, если разработчик не смог придумать концепцию, аналогичную по своей природе IOC2, ему или ей будет сложно понять, какую проблему решает IOC2, использование этого будет выглядеть искусственно, и он или она может начать использовать его. ради какой-то политкорректности.

Лично я использую IoC как своего рода структурную карту своего приложения (да, я тоже предпочитаю StructureMap;)). Это позволяет легко заменить мои обычные реализации интерфейса реализациями Moq во время тестов. Создание тестовой установки может быть таким же простым, как создание нового init-вызова моей IoC-структуры, заменяющей любой класс, который является моей тестовой границей, на макет.

Вероятно, это не то, для чего существует IoC, но это то, что я использую чаще всего ...

КОНТЕЙНЕР МОК РЕШАЕТ ПРОБЛЕМУ, КОТОРОЙ МОЖЕТ НЕ БЫТЬ, НО ЭТО ПРИЯТНАЯ ПРОБЛЕМА ИМЕТЬ

http://kozmic.net/2012/10/23/ioc-container-solves-a-problem-you-might-not-have-but-its-a-nice-problem-to-have/

вам не нужен фреймворк для внедрения зависимостей. Вы также можете сделать это с помощью основных концепций Java. http://en.wikipedia.org/wiki/Dependency_injection#Code_illustration_using_Java

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

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

1) Наличие сторонней библиотеки, управляющей временем жизни ваших объектов "автоматически", может привести к неожиданным результатам. Мы обнаружили, что, особенно в крупных проектах, у вас может быть гораздо больше копий объекта, чем вы ожидаете, и больше, чем если бы вы управляли жизненными циклами вручную. Я уверен, что это зависит от используемого фреймворка, но, тем не менее, проблема существует. Это также может быть проблематично, если ваш объект содержит ресурсы, подключения к данным и т. Д., Поскольку объект иногда может жить дольше, чем вы ожидаете. Таким образом, контейнеры IoC неизбежно увеличивают использование ресурсов и объем памяти приложения.

2) Контейнеры IoC, на мой взгляд, являются формой «программирования черного ящика». Я обнаружил, что, в частности, наши менее опытные разработчики склонны злоупотреблять ими. Это позволяет программисту не думать о том, как объекты должны соотноситься друг с другом или как их разделить, потому что он предоставляет им механизм, с помощью которого они могут просто захватить любой объект, который они хотят, из воздуха. Например, может быть веская причина, по которой ObjectA никогда не должен знать об ObjectB напрямую, но вместо того, чтобы создавать фабрику, мост или локатор сервисов, неопытный программист просто скажет: «Нет проблем, я просто возьму ObjectB из контейнера IoC. ". На самом деле это может привести к усилению связи между объектами, что должно помочь предотвратить IoC.

Внедрение зависимостей в проект ASP.NET может быть выполнено с помощью нескольких строк кода. Я полагаю, что есть некоторое преимущество в использовании контейнера, когда у вас есть приложение, которое использует несколько интерфейсов и нуждается в модульных тестах.