dependency-injection dependency injection - Инверсия контроля против инъекции зависимостей





9 Answers

Короче говоря, IoC - это гораздо более широкий термин, который включает, но не ограничивается, DI

Термин «инверсия управления» (IoC) первоначально означал любой тип программирования, где общая структура или время выполнения контролировали поток программы

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

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

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

java пример управления

Согласно статье, написанной Мартином Фаулером , инверсия управления - это принцип, в котором управляющий поток программы инвертируется: вместо программиста, контролирующего поток программы, внешние источники (каркас, службы и другие компоненты) берут на себя управление Это. Это похоже на то, что мы подключаем что-то еще. Он упомянул пример EJB 2.0:

Например, интерфейс Session Bean определяет ejbRemove, ejbPassivate (хранится во вторичном хранилище) и ejbActivate (восстанавливается из пассивного состояния). Вы не можете контролировать, когда вызываются эти методы, только то, что они делают. Контейнер звонит нам, мы его не называем.

Это приводит к различию между каркасом и библиотекой:

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

Я думаю, точка зрения, что DI является IOC, означает, что зависимость объекта инвертирована: вместо этого он контролирует свои собственные зависимости, жизненный цикл ... что-то еще делает это для вас. Но, как вы рассказали мне о DI руками, DI не обязательно IOC. У нас все еще есть DI и нет МОК.

Однако в этой статье (из pococapsule, другой Framework IOC для C / C ++), это предполагает, что из-за IOC и DI контейнеры IOC и рамки DI намного превосходят J2EE, поскольку J2EE смешивает код структуры с компонентами , тем самым не делая его обычным старым Java / C ++ Object (POJO / POCO).

Инверсия контрольных контейнеров, отличных от шаблона инъекции зависимостей (ссылка на архив)

Дополнительное чтение, чтобы понять, в чем проблема со старой платформой разработки на основе компонентов, которая приводит ко второму документу выше: зачем и что из инверсии управления (ссылка на архив)

Мой вопрос : что такое IOC и DI? Я сбит с толку. Основанный на pococapsule, IOC является чем-то более значительным, чем просто инвертирует контроль между объектами или программистами и фреймворками.





source

IoC ( I nversion o f C ontrol): - Это общий термин и реализован несколькими способами (событиями, делегатами и т. Д.).

DI ( D ependency I njection): - DI является подтипом IoC и реализуется путем инъекции конструктора, инъекции установщика или инъекции интерфейса .

Но Spring поддерживает только следующие два типа:

  • Впрыск сеттера
    • Сеттер-основанный DI реализуется путем вызова методов setter в бобах пользователя после вызова конструктора без аргумента или статического заводского метода без аргументов для создания экземпляра их компонента.
  • Инъекция конструктора
    • Диск конструктора основан на вызове конструктора с несколькими аргументами, каждый из которых представляет собой соавтор. Используя это, мы можем проверить, что введенные компоненты не являются нулевыми и не работают быстро (время компиляции), поэтому при запуске самого приложения мы получаем NullPointerException: bean does not exist . Инъекция конструктора - лучшая практика для инъекций зависимостей.






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

Существует несколько базовых методов для реализации инверсии управления. Это:

  • Использование заводского шаблона
  • Использование шаблона локатора службы
  • Использование инъекции зависимостей любого из приведенных ниже типов:

    1). Впрыск конструктора
    2). Ввод установки
    3). Инъекция интерфейса



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

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

DI - это процесс обеспечения зависимостей объекта во время выполнения с помощью инъекции установщика или инъекции конструктора.




IOC (Inversion of Control) представляет собой концепцию шаблона проектирования для удаления зависимостей и их развязывания для обеспечения нелинейности потока и позволяет контейнеру / или другому объекту управлять предоставлением зависимостей. Это фактически следует за Голливудским директором «Не называй нас, мы позвоним тебе». Итак, суммируя различия.

Инверсия управления: - Это общий термин для развязки зависимостей и делегирования их подготовки, и это может быть реализовано несколькими способами (событиями, делегатами и т. Д.).

Инъекция зависимостей: - DI является подтипом IOC и реализуется путем инъекции конструктора, инъекции установщика или инъекции метода.

Следующая статья описывает это очень аккуратно.

source




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

В следующих примерах я пытаюсь объяснить обе эти концепции.

Раньше мы пишем такой код

Public MyClass{
 DependentClass dependentObject
 /*
  At somewhere in our code we need to instantiate 
  the object with new operator  inorder to use it or perform some method.
  */ 
  dependentObject= new DependentClass();
  dependentObject.someMethod();
}

При инъекции зависимостей инжекторы зависимостей будут заботиться о создании объектов

Public MyClass{
 /* Dependency injector will instantiate object*/
 DependentClass dependentObject

 /*
  At somewhere in our code we perform some method. 
  The process of  instantiation will be handled by the dependency injector
 */ 

  dependentObject.someMethod();
}

Вышеупомянутый процесс предоставления контроля над каким-либо другим (например, контейнером) для инстанцирования и инъекции можно назвать «инверсией управления», а процесс, в котором контейнер IOC вводит зависимость для нас, можно назвать инъекцией зависимости.

IOC - это принцип, в котором поток управления программой инвертируется: вместо программиста, управляющего потоком программы , программа управляет потоком, уменьшая накладные расходы программисту. И процесс, используемый программой для инъекционной зависимости, называется DI

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

Также рекомендуем читать.

Что такое инъекция зависимости?

Вы также можете проверить один из моих подобных ответов здесь

Разница между инверсией контроля и зависимостями инъекций




// ICO, DI, 10 лет назад, это было так:

public class  AuditDAOImpl implements Audit{

    //dependency
    AuditDAO auditDAO = null;
        //Control of the AuditDAO is with AuditDAOImpl because its creating the object
    public AuditDAOImpl () {
        this.auditDAO = new AuditDAO ();
    }
}

Теперь с весной 3,4 или последним, как показано ниже

public class  AuditDAOImpl implements Audit{

    //dependency

     //Now control is shifted to Spring. Container find the object and provide it. 
    @Autowired
    AuditDAO auditDAO = null;

}

В целом, управление инвертируется от старой концепции связанного кода с такими фреймами, как Spring, что делает объект доступным. Так что это IOC, насколько я знаю, и инъекция зависимостей, как вы знаете, когда мы добавляем зависимый объект в другой объект, используя конструктор или сеттеры. Inject в основном означает передачу его в качестве аргумента. Весной у нас есть конфигурация на основе XML и аннотаций, где мы определяем объект bean и передаем зависимый объект с помощью стиля инсталляции Constructor или setter.




1) DI - Child-> obj зависит от parent-obj. Важен глагол. 2) IOC - Child-> obj выполняет под платформой. где платформа может быть школа, колледж, танцевальный класс. Здесь выполняется действие с различной импликацией под любым провайдером платформы.

практический пример: `

//DI
child.getSchool();
//IOC
child.perform()// is a stub implemented by dance-school
child.flourish()// is a stub implemented by dance-school/school/

`

-AB






Related