Что такое инжекция зависимостей и инверсия управления в Spring Framework?

"Инъекция зависимостей" и "Инверсия управления" часто упоминаются в качестве основных преимуществ использования структуры Spring для разработки веб-фреймворков

Может ли кто-нибудь объяснить, что это очень просто, с примером, если это возможно?

ОТВЕТЫ

Ответ 1

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

Например: предположим, что у нас есть объект Employee и он зависит от объекта Address. Мы бы определили bean-компонент, соответствующий Employee, который определит его зависимость от Address объекта.

Когда Spring пытается создать объект Employee, он видит, что Employee зависит от Address, поэтому сначала он создает объект Address (зависимый объект), а затем внедряет его в объект Employee.

  • Инверсия управления (IOC) и инъекция зависимостей (DI) используются взаимозаменяемо. МОК достигается через DI. DI - это процесс предоставления зависимостей, а IOC - конечный результат DI. (Примечание: DI - не единственный способ достижения МОК. Есть и другие способы.)

  • С помощью DI ответственность за создание объектов переносится с кода нашего приложения на контейнер Spring; это явление называется МОК.

  • Внедрение зависимостей может быть выполнено с помощью метода ввода или конструктора.

Ответ 2

Я напишу мое простое понимание этих двух терминов:

For quick understanding just read examples*

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

При этом реализация объектов определяет их зависимости. И spring делает это доступным.
Это приводит к слабосвязанной разработке приложений.

Quick Example:EMPLOYEE OBJECT WHEN CREATED,IT WILL AUTOMATICALLY CREATE ADDRESS OBJECT (if address is defines as dependency by Employee object)*.<br>

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

QUICK EXAMPLE:Inversion of Control is about getting freedom, more flexibility, and less dependency. When you are using a desktop computer, you are slaved (or say, controlled). You have to sit before a screen and look at it. Using keyboard to type and using mouse to navigate. And a bad written software can slave you even more. If you replaced your desktop with a laptop, then you somewhat inverted control. You can easily take it and move around. So now you can control where you are with your computer, instead of computer controlling it.

Внедрив Inversion of Control, потребитель программного/объектного объекта получает больше элементов управления/опций над программным обеспечением/объектами вместо того, чтобы управлять им или иметь меньше опций.

Инверсия управления в качестве руководства по проектированию служит следующим целям:

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

Детальное объяснение

Ответ 3

В Spring объекты слабо связаны, т.е. Каждый класс не зависит друг от друга, так что все может быть проверено индивидуально. Но при использовании этих классов класс может зависеть от других классов, которые должны быть созданы в первую очередь.

Итак, мы сообщаем Spring, что класс A зависит от класса B. Итак, при создании bean-компонента (например, класса) для класса A он создает экземпляр класса B перед классом A и внедряет его в класс A с помощью методов DI-метода setter или конструктора. То есть мы говорим весенней зависимости во время выполнения. Это Д.И.

Поскольку мы возлагаем ответственность за создание объектов (bean-компонентов), поддержание их и их агрегатов на Spring вместо жесткого кодирования, мы называем это Inversion Of Control (IOC).

Ответ 4

Инверсия Контроля (МОК):

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

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

Инъекция зависимости (DI):

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

нажмите, чтобы увидеть больше

Ответ 5

Spring: Spring является контейнером "Инверсия управления" для платформы Java.

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

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

Ответ 6

Инверсия control- Это означает предоставление контроля над созданием и созданием экземпляров пружинных bean-компонентов в контейнере Spring IOC, и единственная работа, которую выполняет разработчик, это настройка bean-компонентов в весеннем XML файле.

Зависимость injection-

Рассмотрим класс Сотрудник

class Employee { 
   private int id;
   private String name;
   private Address address;

   Employee() {
     id = 10;
     name="name";
     address = new Address();
   }


}

и рассмотрим класс Address

class Address {
   private String street;
   private String city;

   Address() {
     street="test";
     city="test1";

  }
}

В приведенном выше коде значения класса адресов будут установлены только при создании экземпляра класса Employee, что является зависимостью класса Address от класса Employee. И Spring решает эту проблему, используя концепцию внедрения зависимостей, предоставляя два способа внедрения этой зависимости.

  1. Сеттер впрыска

Метод сеттера в классе Employee, который берет ссылку на класс Address

public void setAddress(Address addr) {
    this.address = addr;
}
  1. Конструктор инъекций

Конструктор в классе Employee, который принимает адрес

Employee(Address addr) {
      this.address = addr;
}

Таким образом, значения класса Address могут быть установлены независимо, используя либо инъекцию сеттера/конструктора.

Ответ 7

Inversion of Control - это общий принцип проектирования архитектуры программного обеспечения, который помогает создавать модульные программные структуры многократного использования, которые просты в обслуживании.

Это принцип разработки, при котором поток управления "принимается" из общей библиотеки или кода многократного использования.

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

print ("Please enter your name:");
scan (&name);
print ("Please enter your DOB:");
scan (&dob);

//More print and scan statements
<Do Something Interesting>

//Call a Library function to find the age (common code)
print Age

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

Например, в системе на основе Windows уже будет доступна инфраструктура для создания элементов пользовательского интерфейса, таких как кнопки, меню, окна и диалоговые окна. Когда я пишу бизнес-логику своего приложения, это будут каркасные события, которые будут вызывать мой код бизнес-логики (когда событие запускается), а НЕ наоборот.

Хотя код платформы не знает о моей бизнес-логике, он все равно будет знать, как вызывать мой код. Это достигается с помощью событий/делегатов, обратных вызовов и т.д. Здесь управление потоком является "инвертированным".

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

Внедрение зависимостей - это шаблон проектирования, который реализует принцип IoC для разрешения зависимостей объектов.

Проще говоря, когда вы пытаетесь написать код, вы будете создавать и использовать разные классы. Один класс (класс A) может использовать другие классы (класс B и/или D). Итак, класс B и D являются зависимостями класса A.

Простая аналогия будет классом автомобилей. Автомобиль может зависеть от других классов, таких как двигатель, шины и многое другое.

Внедрение зависимостей предполагает, что вместо зависимых классов (здесь Class Car), создающих свои зависимости (Class Engine и класс Tire), класс должен быть внедрен с конкретным экземпляром зависимости.

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

Class TextEditor
{

    //Lot of rocket science to create the Editor goes here

    EnglishSpellChecker objSpellCheck;
    String text;

    public void TextEditor()

    {   

        objSpellCheck = new EnglishSpellChecker();

    }

    public ArrayList <typos> CheckSpellings()
    {

        //return Typos;

    }

}

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

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

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

Здесь мы создали тесно связанный код с "английским" SpellChecker, тесно связанным с нашим классом TextEditor, что означает, что наш класс TextEditor зависит от EnglishSpellChecker, или, другими словами, EnglishSpellCheker является зависимостью для TextEditor. Нам нужно удалить эту зависимость. Кроме того, нашему текстовому редактору нужен способ хранить конкретную ссылку на любую проверку орфографии, основанную на усмотрении разработчика во время выполнения.

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

interface ISpellChecker
{

    Arraylist<typos> CheckSpelling(string Text);

}

Class EnglishSpellChecker : ISpellChecker

{

    public override Arraylist<typos> CheckSpelling(string Text)

    {

        //All Magic goes here.

    }

}



Class FrenchSpellChecker : ISpellChecker

{

    public override Arraylist<typos> CheckSpelling(string Text)

    {

        //All Magic goes here.

    }

}

В нашем примере класс TextEditor должен получить конкретный экземпляр типа ISpellChecker.

Теперь зависимость может быть введена в Constructor, Public Property или метод.

Давайте попробуем изменить наш класс, используя Constructor DI. Измененный класс TextEditor будет выглядеть примерно так:

Class TextEditor

{

    ISpellChecker objSpellChecker;

    string Text;



    public void TextEditor(ISpellChecker objSC)

    {

        objSpellChecker = objSC;

    }



    public ArrayList <typos> CheckSpellings()

    {

        return objSpellChecker.CheckSpelling();

    }

}

Чтобы вызывающий код при создании текстового редактора мог внедрить соответствующий тип SpellChecker в экземпляр TextEditor.

Вы можете прочитать полную статью здесь

Ответ 8

Традиционным способом получения экземпляра адреса в Employee будет создание нового экземпляра класса Address.Spring создает все зависимые объекты, поэтому мы не должны беспокоиться об объекте.

Итак, в Spring мы просто зависим от контейнера Spring, который предоставляет нам объект зависимостей.

Ответ 9

контейнер IoC

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

  • Чтобы создать экземпляр класса приложения
  • Чтобы настроить объект

  • Чтобы собрать зависимости между объектами Существует два типа контейнеров IoC. Это:

  • BeanFactory

  • ApplicationContext

Инъекция зависимостей (DI)

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

Структура

Spring обеспечивает два способа вставки зависимости

  • По конструктору
  • По методу Setter

Ответ 10

МОК - это техника, в которой вы позволяете кому-то другому создавать объект для вас. И кто-то еще в случае весны - контейнер МОК.

Внедрение зависимостей - это метод, при котором один объект обеспечивает зависимость другого объекта.