복붙노트

[SPRING] 스프링 프레임 워크에서 Dependency Injection과 Inversion of Control은 무엇입니까?

SPRING

스프링 프레임 워크에서 Dependency Injection과 Inversion of Control은 무엇입니까?

"Dependency Injection"과 "Inversion of Control"은 웹 프레임 워크를 개발하기 위해 Spring 프레임 워크를 사용하는 주된 이점으로 종종 언급됩니다

가능한 경우 예제를 통해 매우 간단한 용어로 설명 할 수 있습니까?

해결법

  1. ==============================

    1.예를 들면 다음과 같습니다. Employee 객체가 있고 객체 Address에 대한 종속성이 있다고 가정합니다. 우리는 객체 Address에 대한 의존성을 정의 할 Employee에 해당하는 bean을 정의 할 것입니다.

    예를 들면 다음과 같습니다. Employee 객체가 있고 객체 Address에 대한 종속성이 있다고 가정합니다. 우리는 객체 Address에 대한 의존성을 정의 할 Employee에 해당하는 bean을 정의 할 것입니다.

    Spring이 Employee 객체를 만들려고 할 때, Employee가 Address에 대한 의존성을 가지기 때문에 먼저 Address 객체 (종속 객체)를 생성 한 다음 Employee 객체에 삽입 할 것이다.

  2. ==============================

    2.나는이 두 용어에 대한 나의 간단한 이해를 적어 둘 것이다.

    나는이 두 용어에 대한 나의 간단한 이해를 적어 둘 것이다.

    For quick understanding just read examples*

    의존성 주입 (DI) : 의존성 주입은 일반적으로 메소드가 종속 객체를 생성하는 대신 종속 객체를 매개 변수로 메소드에 전달하는 것을 의미합니다. 실제로이 메소드가 특정 구현에 직접 의존하지 않는다는 것을 의미합니다. 요구 사항을 충족시키는 모든 구현을 매개 변수로 전달할 수 있습니다. 이 개체를 사용하면 종속성을 알 수 있습니다. 그리고 봄이 그것을 가능하게합니다. 이는 느슨하게 결합 된 응용 프로그램 개발로 이어집니다.

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

    Inversion of Control (IoC) 컨테이너 : 이것은 프레임 워크의 일반적인 특징이며, IOC는 BeanFactory를 통해 인스턴스 작성에서 파기까지 Java 오브젝트를 관리합니다. IoC 컨테이너에 의해 인스턴스화 된 Java 구성 요소는 Bean이라고하며 IoC 컨테이너는 Bean의 범위, 라이프 사이클 이벤트 및 구성되고 코딩 된 AOP 기능을 관리합니다.

    빠른 예제 : 제어 반전은 자유, 유연성 및 종속성 감소에 관한 것입니다. 데스크톱 컴퓨터를 사용하는 경우 사용자는 종속되어 있습니다 (말하면 제어 됨). 당신은 화면 앞에 앉아서 그것을 봐야합니다. 키보드를 사용하여 입력하고 마우스를 사용하여 탐색합니다. 그리고 나쁜 서면 소프트웨어는 당신을 훨씬 더 노예로 만들 수 있습니다. 바탕 화면을 노트북으로 교체 한 경우 다소 통제가 뒤집 혔습니다. 당신은 쉽게 가져 가서 이동할 수 있습니다. 이제 컴퓨터를 제어하는 ​​대신 컴퓨터를 사용하여있는 위치를 제어 할 수 있습니다.

    Inversion of Control을 구현함으로써 소프트웨어 / 객체 소비자는 제어되거나 옵션이 적게 드는 대신 소프트웨어 / 객체에 대한 더 많은 제어 / 옵션을 얻습니다.

    설계 가이드 라인으로서의 제어 반전은 다음과 같은 목적을 위해 사용됩니다.

    특정 작업의 실행을 구현과 분리하는 방법이 있습니다. 모든 모듈은 자신이 의도 한 것에 집중할 수 있습니다. 모듈은 다른 시스템이하는 일에 대한 가정을하지 않고 계약에 의존합니다. 모듈 교체는 다른 모듈에 부작용이 없습니다. 여기서는 추상적 인 것들을 유지할 것입니다. 주제에 대한 자세한 내용을 보려면 다음 링크를 방문하십시오. 보기 좋은 예

    상해

  3. ==============================

    3.Spring : Spring은 Java 플랫폼 용 "Inversion of Control"컨테이너입니다.

    Spring : Spring은 Java 플랫폼 용 "Inversion of Control"컨테이너입니다.

    IoC (Inversion of Control) : IoC (Inversion of Control)는 오브젝트 커플 링이 런타임에 "어셈블러"객체에 의해 바인드되고 일반적으로 정적 분석을 사용하여 컴파일 할 때 알 수없는 객체 지향 프로그래밍 연습입니다.

    DI (Dependency Injection) : "종속성 삽입은 하드 코딩 된 종속성을 제거 할 수있는 소프트웨어 디자인 패턴으로, 런타임 또는 컴파일 타임에 상관없이이를 변경할 수 있습니다." - 위키.

  4. ==============================

    4.Spring 객체는 느슨하게 결합됩니다. 즉, 각 클래스는 서로 독립적이므로 모든 것을 개별적으로 테스트 할 수 있습니다. 그러나 이러한 클래스를 사용할 때 클래스는 먼저 인스턴스화해야하는 다른 클래스에 종속 될 수 있습니다.

    Spring 객체는 느슨하게 결합됩니다. 즉, 각 클래스는 서로 독립적이므로 모든 것을 개별적으로 테스트 할 수 있습니다. 그러나 이러한 클래스를 사용할 때 클래스는 먼저 인스턴스화해야하는 다른 클래스에 종속 될 수 있습니다.

    그래서 클래스 A가 클래스 B에 의존한다는 것을 스프링에게 알려줍니다. 클래스 A와 같은 bean을 생성 할 때, 클래스 A보다 먼저 클래스 B를 인스턴스화하고이를 setter 또는 생성자 DI 메소드를 사용하여 클래스 A에 주입합니다. 즉, 런타임에 종속성을 봄으로 알려줍니다. 이것은 DI입니다.

    우리는 객체 (bean) 생성에 대한 책임을 할당하고, 하드 코딩하지 않고 Spring에 집계 및 유지 보수를 맡기 때문에 Inversion Of Control (IOC)라고 부릅니다.

  5. ==============================

    5.Inversion of Control (IOC) :

    Inversion of Control (IOC) :

    IoC는 시스템에서 제어 흐름을 반전하는 것을 설명하는 디자인 패턴이므로 실행 흐름은 중앙 코드로 제어되지 않습니다. 즉, 구성 요소는 다른 구성 요소의 추상화에만 의존해야하며 종속 객체 생성을 처리하지 않아야합니다. 대신 객체 인스턴스는 런타임에 IOC 컨테이너에서 DI (Dependency Injection)를 통해 제공됩니다.

    IoC는 재사용, 느슨한 결합 및 소프트웨어 구성 요소 테스트를 용이하게하는 우수한 소프트웨어 설계를 가능하게합니다.

    의존성 주입 (DI) :

    DI는 객체의 생성자에 종속성을 전달하는 기술입니다. 개체가 컨테이너에서로드 된 경우 해당 종속성은 컨테이너에서 자동으로 제공됩니다. 따라서 수동으로 인스턴스를 만들지 않고도 종속성을 사용할 수 있습니다. 이렇게하면 결합이 줄어들고 객체 인스턴스의 수명을보다 효과적으로 제어 할 수 있습니다.

    자세한 내용을 보려면 클릭하십시오.

  6. ==============================

    6.제어 - 이는 스프링 IOC 컨테이너에 스프링 빈을 생성하고 인스턴스화하는 것을 제어하는 ​​것을 의미하며, 개발자가 수행하는 유일한 작업은 스프링 xml 파일에서 빈을 구성하는 것입니다.

    제어 - 이는 스프링 IOC 컨테이너에 스프링 빈을 생성하고 인스턴스화하는 것을 제어하는 ​​것을 의미하며, 개발자가 수행하는 유일한 작업은 스프링 xml 파일에서 빈을 구성하는 것입니다.

    종속성 주입 -

    Employee 클래스를 고려해보십시오.

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

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


}

    수업 주소 고려

    class Address {
   private String street;
   private String city;

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

  }
}

    위의 코드에서 주소 클래스 값은 Employee 클래스가 인스턴스화 될 때만 설정됩니다. 이는 Employee 클래스에 대한 Address 클래스의 종속성입니다. 그리고 스프링은이 의존성을 주입하는 두 가지 방법을 제공함으로써 Dependency Injection 개념을 사용하여이 문제를 해결합니다.

    Address 클래스를 참조하는 Employee 클래스의 Setter 메소드

    public void setAddress(Address addr) {
    this.address = addr;
}

    Address를 수락하는 Employee 클래스의 생성자

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

    이런 식으로 Address 클래스 값은 setter / constructor injection을 사용하여 독립적으로 설정할 수 있습니다.

  7. ==============================

    7.Employee에서 주소 인스턴스를 가져 오는 전통적인 방법은 Address 클래스의 새 인스턴스를 만드는 것입니다 .Spring은 모든 종속 객체를 생성하므로 우리는 객체에 대해 걱정할 필요가 없습니다.

    Employee에서 주소 인스턴스를 가져 오는 전통적인 방법은 Address 클래스의 새 인스턴스를 만드는 것입니다 .Spring은 모든 종속 객체를 생성하므로 우리는 객체에 대해 걱정할 필요가 없습니다.

    그래서 스프링에서는 의존성 객체를 제공하는 스프링 컨테이너에 의존합니다.

  8. ==============================

    8.Inversion of Control은 유지 보수가 쉬운 재사용 가능한 모듈 식 소프트웨어 프레임 워크를 만드는 데 도움이되는 소프트웨어 아키텍처의 일반적인 디자인 원칙입니다.

    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 기반 시스템에서는 버튼, 메뉴, 창 및 대화 상자와 같은 UI 요소를 만들 수있는 프레임 워크가 이미 제공됩니다. 내 응용 프로그램의 비즈니스 논리를 작성할 때 프레임 워크의 이벤트가 비즈니스 논리 코드 (이벤트 발생시)를 호출하고 반대가 아닙니다.

    프레임 워크의 코드가 내 비즈니스 로직을 인식하지 못하더라도 내 코드를 호출하는 방법을 여전히 알고 있습니다. 이것은 이벤트 / 위임자, 콜백 등을 사용하여 수행됩니다. 여기에서 흐름 제어는 "반전 됨"입니다.

    따라서 정적으로 바인딩 된 객체에 대한 제어 흐름에 의존하는 대신 흐름은 전체 객체 그래프와 다른 객체 간의 관계에 따라 달라집니다.

    Dependency Injection은 객체의 의존성을 해결하기위한 IoC 원칙을 구현하는 디자인 패턴입니다.

    간단하게 말해서 코드를 작성하려고 할 때 다른 클래스를 작성하고 사용하게됩니다. 한 등급 (등급 A)은 다른 등급 (B 등급 및 / 또는 D 등급)을 사용할 수 있습니다. 따라서 클래스 B와 D는 클래스 A의 종속 관계입니다.

    간단한 유추는 클래스 자동차가 될 것입니다. 자동차는 엔진, 타이어 등과 같은 다른 클래스에 의존 할 수 있습니다.

    Dependent Injection은 Dependent 클래스 (여기서는 Class Car) 대신 종속성 (클래스 엔진 및 클래스 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 함수를 호출하고 사용자에게 표시 할 오타 목록을 찾습니다.

    한 명의 사용자가 편집자에게 불어 쓰기를 시작하면 좋은 하루가 오기 전에는 모든 것이 잘 작동하는 것 같습니다.

    더 많은 언어에 대한 지원을 제공하려면 더 많은 맞춤법 검사기가 필요합니다. 아마 프랑스어, 독일어, 스페인어 등.

    여기서는 "영어"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 또는 메소드에 삽입 될 수 있습니다.

    생성자 DI를 사용하여 클래스를 변경해 보겠습니다. 변경된 TextEditor 클래스는 다음과 같습니다.

    Class TextEditor

{

    ISpellChecker objSpellChecker;

    string Text;



    public void TextEditor(ISpellChecker objSC)

    {

        objSpellChecker = objSC;

    }



    public ArrayList <typos> CheckSpellings()

    {

        return objSpellChecker.CheckSpelling();

    }

}

    텍스트 편집기를 생성하는 동안 호출 코드가 해당 SpellChecker Type을 TextEditor의 인스턴스에 삽입 할 수 있도록합니다.

    여기에서 전체 기사를 읽을 수 있습니다.

    9. from https://stackoverflow.com/questions/9403155/what-is-dependency-injection-and-inversion-of-control-in-spring-framework by cc-by-sa and MIT license

'SPRING' 카테고리의 다른 글

[SPRING] 여러 프로젝트 / 모듈에서 PropertyPlaceholderConfigurer를 통해 여러 속성 파일 사용  (0) 2019.01.07
[SPRING] Spring Boot와 Spring Security로 REST API를 보호하는 방법은 무엇입니까?  (0) 2019.01.07
[SPRING] Spring 대 EJB. Spring이 EJB를 대체 할 수 있습니까? [닫은]  (0) 2019.01.07
[SPRING] 봄 데이터 JPA - 개체를 반환하는 가장 좋은 방법은?  (0) 2019.01.07
[SPRING] @ Cacheable with Ehcache, 유효한 객체에 대해 null을 찾습니다.  (0) 2019.01.07
,

티스토리툴바