복붙노트

[SPRING] 의존성 주입 용기의 장점은 무엇입니까?

SPRING

의존성 주입 용기의 장점은 무엇입니까?

나는 의존성 주입 자체의 이점을 이해합니다. 예를 들어 Spring을 사용합시다. 나는 또한 다른 Spring features AOP, 다른 종류의 도우미 등의 이점을 이해한다. 다음과 같은 XML 구성의 이점은 무엇인가 궁금하다.

<bean id="Mary" class="foo.bar.Female">
  <property name="age" value="23"/>
</bean>
<bean id="John" class="foo.bar.Male">
  <property name="girlfriend" ref="Mary"/>
</bean>

같은 일반 자바 코드와 비교 :

Female mary = new Female();
mary.setAge(23);
Male john = new Male();
john.setGirlfriend(mary);

디버깅이 쉬우 며 컴파일 시간을 확인하고 java 만 아는 사람이라면 누구나 이해할 수 있습니다. 그렇다면 의존성 주입 프레임 워크의 주요 목적은 무엇입니까? (또는 이점을 보여주는 코드 조각).

최신 정보: 의 경우

IService myService;// ...
public void doSomething() {  
  myService.fetchData();
}

IoC 프레임 워크는 하나 이상의 myService 구현이 필요한 경우이를 주입 할 방법을 어떻게 추측 할 수 있습니까? 주어진 인터페이스의 구현이 하나 뿐이고 IoC 컨테이너가 자동으로 사용하도록 결정하면 두 번째 구현이 나타난 후에 인터페이스가 깨집니다. 인터페이스의 구현이 의도적으로 하나만 가능하다면 주입 할 필요가 없습니다.

IoC의 장점을 보여주는 작은 구성의 구성을 보면 정말 흥미로울 것입니다. 나는 잠시 동안 Spring을 사용 해왔고 그런 예를 제공 할 수 없습니다. 또한 최대 절전 모드, dwr 및 기타 사용하는 프레임 워크의 이점을 보여주는 단일 행을 표시 할 수 있습니다.

업데이트 2 : IoC 구성을 다시 컴파일하지 않고 변경할 수 있음을 알고 있습니다. 정말 좋은 생각입니까? 누군가가 언제 다시 컴파일하지 않고 DB 자격 증명을 변경하려고하는지 이해할 수 있습니다. 개발자가 아닐 수도 있습니다. 실습에서 개발자가 아닌 다른 사람이 IoC 구성을 변경하는 빈도는? 나는 개발자를 위해 구성을 변경하는 대신 특정 클래스를 다시 컴파일하지 않으려한다고 생각한다. 그리고 비 개발자를 위해 당신은 그의 인생을 더 쉽게 만들고 좀 더 간단한 설정 파일을 제공하기를 원할 것입니다.

업데이트 3 :

그것은 그것을 extenal하게 만드는 것이 무엇이 좋은가? 당신이 할 수있는 동안 당신은 모든 코드를 외부로 만들지 않고 ClassName.java.txt 파일에 배치하고, fly-wow에서 수동으로 읽고 컴파일하여 재 컴파일을 피할 수 있습니다. 왜 컴파일을 피해야합니까?!

선언적 접근 방식이 때로는 시간을 절약한다는 것을 이해합니다. 예를 들어 bean 속성과 DB 컬럼 사이의 매핑을 한 번만 선언하고 hibernate는 HSQL을 기반으로 SQL을로드, 저장, 빌드하는 동안이 매핑을 사용합니다. 이것이 선언적 접근 방식이 작동하는 곳입니다. Spring의 경우 (예제에서), 선언은 더 많은 라인을 가지며 대응 코드와 동일한 표현력을가집니다. 그러한 선언이 코드보다 짧을 때 예제가 있다면 - 그것을보고 싶습니다.

필자는 컨트롤 이점의 반전을 이해합니다. IoC가 더 일반적이기 때문에 여기서는 Dependency Injection으로 디자인 패턴을 호출하는 것을 선호합니다. 많은 종류의 컨트롤이 있으며 초기화 중 하나만 반전합니다. 왜 누군가가 프로그래밍 언어가 아닌 다른 것을 필요로하는지 묻고있었습니다. 코드를 사용하여 실제 구현을 가짜 구현으로 대체 할 수 있습니다. 그리고이 코드는 설정과 같은 것을 표현할 것입니다 - 그냥 가짜 값으로 필드를 초기화 할 것입니다.

mary = new FakeFemale();

DI의 이점을 이해합니다. 필자는 외부 XML 구성이 동일한 코드를 구성하는 것과 비교하여 어떤 이점이 추가되는지 이해하지 못합니다. 나는 컴파일을 피해야한다고 생각하지 않는다. 나는 매일 컴파일하고 나는 여전히 살아있다. DI의 구성은 선언적 접근의 나쁜 예라고 생각합니다. 선언은 한 번 선언되고 여러 번 다른 방식으로 사용되는 경우에 유용 할 수 있습니다. hibernate cfg와 같이 bean 속성과 DB 열 간의 매핑이 저장,로드, 검색 쿼리 작성 등에 사용됩니다. Spring DI 구성은 다음으로 쉽게 변환 할 수 있습니다. 이 질문의 시작 부분 에서처럼 코드를 구성 할 수 있습니까? 그리고 그것은 빈 초기화에만 사용됩니다, 안 그래요? 선언적 접근 방식이 여기에 아무 것도 추가하지 않는다는 것을 의미합니까?

최대 절전 모드 매핑을 선언 할 때, 나는 단지 최대 절전 모드로 약간의 정보를 제공하고 그것을 기반으로 작동한다. 봄의 경우, 내 선언은 봄에 정확히 할 말을합니다. 그래서 왜 선언합니까, 왜 그렇게하지 않습니까?

마지막 업데이트: 얘들 아, 많은 답변들이 내가 알고있는 의존성 주입에 대해 말하고있다. 문제는 코드를 초기화하는 대신 DI 구성의 목적에 관한 것입니다. 코드를 초기화하는 것이 더 짧고 명확 해지는 경향이 있습니다. 지금까지 내 질문에 대한 유일한 대답은 구성이 변경 될 때 다시 컴파일하지 않는 것입니다. 나는 내게 커다란 비밀이기 때문에 왜 다른 질문을 게시해야하는지, 왜이 경우에는 컴파일을 피해야하는지 생각해 본다.

해결법

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

    1.나 자신에게 IoC를 사용하고 (외부 구성을 사용하는) 주된 이유 중 하나는 다음 두 영역을 중심으로합니다.

    나 자신에게 IoC를 사용하고 (외부 구성을 사용하는) 주된 이유 중 하나는 다음 두 영역을 중심으로합니다.

    테스트

    테스트를 세 가지 시나리오 (큰 규모의 개발에서 상당히 일반적 임)로 나눈 경우 :

    마지막 두 가지 테스트 시나리오 (통합 및 블랙 박스)에 대한 작업은 응용 프로그램의 일부를 다시 컴파일하지 않기를 원할 것입니다.

    테스트 시나리오 중 하나라도 구성을 변경해야하는 경우 (즉, 다른 구성 요소를 사용하여 은행 통합을 모방하거나 성능로드를 수행하는 경우) 쉽게 처리 할 수 ​​있습니다 (이는 DI 구성 측면의 이점에 따른 것입니다. 그래도.

    또한 앱이 여러 사이트 (서버 및 구성 요소가 서로 다른 구성)에서 사용되거나 실제 환경에서 구성이 변경되는 경우 테스트의 나중 단계를 사용하여 앱이 이러한 변경 사항을 처리하는지 확인할 수 있습니다.

    생산

    개발자는 프로덕션 환경을 제어하지 않아야하며 (특히 앱이 여러 고객 또는 별도 사이트에 배포되는 경우), IoC와 외부 구성을 모두 사용하는 것이 좋습니다. 개발자와 테스트를 거치지 않고도 라이브 환경을 조정 및 조정할 수있는 인프라 / 프로덕션 지원에 달려 있습니다.

    개요

    IoC의 외부 구성이 다른 사람 (비 개발자)에게 응용 프로그램을 구성 할 수있는 권한을 부여하는 데서 얻는 주된 이점은 내 경험에 비추어 볼 때 제한된 환경에서만 유용합니다.

    실제로 나는 당신이 환경을 제어 할 수있는 무언가를 개발할 때조차도 계속 진행될 것이라고 생각했습니다. 시간이 지남에 따라 다른 사람에게 구성을 변경할 수있는 능력을 부여하는 것이 더 좋습니다.

    참고 : 응용 프로그램은 실행 파일뿐만 아니라 완전한 솔루션을 나타내므로 응용 프로그램을 실행하는 데 필요한 모든 파일이 필요합니다.

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

    2.의존성 주입은 객체 위임이 대개 객체 상속보다 더 유용한 디자인 패턴이라는 관측에 뿌리를 둔 코딩 스타일입니다 (즉, 객체가 갖는 관계 - 객체 관계보다 유용합니다 - 관계). 그러나 DI가 작동하기 위해서는 하나의 다른 요소가 필요합니다. 즉, 객체 인터페이스를 만드는 것입니다. 이 두 가지 강력한 디자인 패턴을 결합하여 소프트웨어 엔지니어는 유연한 느슨하게 결합 된 코드를 작성할 수 있다는 것을 빨리 깨달았고 따라서 종속성 삽입의 개념이 탄생했습니다. 그러나 DI가 정말로 이륙 한 특정 고수준 언어에서 객체 리플렉션이 가능해질 때까지는 아닙니다. 오늘날 DI 시스템의 핵심 요소 인 반사 요소는 DI의 정말 멋진 요소는 객체를 프로그래밍 방식으로 선택하고 객체 자체에 독립적이며 외부 시스템을 사용하여 객체를 구성하고 다른 객체에 주입 할 수있는 기능이 필요하기 때문입니다.

    의존성 주입은 객체 위임이 대개 객체 상속보다 더 유용한 디자인 패턴이라는 관측에 뿌리를 둔 코딩 스타일입니다 (즉, 객체가 갖는 관계 - 객체 관계보다 유용합니다 - 관계). 그러나 DI가 작동하기 위해서는 하나의 다른 요소가 필요합니다. 즉, 객체 인터페이스를 만드는 것입니다. 이 두 가지 강력한 디자인 패턴을 결합하여 소프트웨어 엔지니어는 유연한 느슨하게 결합 된 코드를 작성할 수 있다는 것을 빨리 깨달았고 따라서 종속성 삽입의 개념이 탄생했습니다. 그러나 DI가 정말로 이륙 한 특정 고수준 언어에서 객체 리플렉션이 가능해질 때까지는 아닙니다. 오늘날 DI 시스템의 핵심 요소 인 반사 요소는 DI의 정말 멋진 요소는 객체를 프로그래밍 방식으로 선택하고 객체 자체에 독립적이며 외부 시스템을 사용하여 객체를 구성하고 다른 객체에 주입 할 수있는 기능이 필요하기 때문입니다.

    언어는 일반적인 객체 지향 프로그래밍 기술뿐만 아니라 객체 인터페이스 및 객체 반영 (예 : Java 및 C #)에 대한 지원을 제공해야합니다. C ++ 시스템에서 DI 패턴을 사용하여 프로그램을 빌드 할 수 있지만 적절한 언어 내에서 반영을 지원하지 않으면 응용 프로그램 서버 및 다른 DI 플랫폼을 지원할 수 없으므로 DI 패턴의 표현력이 제한됩니다.

    DI 패턴을 사용하여 구축 된 시스템의 장점 :

    분명히 DI 코드가 더 복잡해 보입니다. 다른 객체에 주입 할 객체를 구성하는 모든 XML 파일의 단점은 어려워 보입니다. 그러나 이것은 DI 시스템의 요점입니다. 코드 오브젝트를 일련의 구성 설정으로 혼합하고 일치 시키면 최소한의 코딩으로 타사 코드를 사용하여 복잡한 시스템을 구축 할 수 있습니다.

    이 질문에서 제공된 예제는 적절하게 인수 분해 된 DI 객체 라이브러리가 제공 할 수있는 표현력의 표면 만 다루기 만합니다. 몇 가지 연습과 많은 자기 훈련으로 대부분의 DI 실무자는 응용 프로그램 코드의 100 % 테스트 적용 범위를 갖는 시스템을 구축 할 수 있음을 발견했습니다. 혼자서이 1 점은 특별합니다. 이것은 몇 백 줄의 작은 응용 프로그램에 대한 100 % 테스트 적용 범위가 아니라 수십만 줄의 코드를 포함하는 응용 프로그램에 대한 100 % 테스트 적용 범위입니다. 나는이 수준의 테스트 가능성을 제공하는 다른 디자인 패턴을 설명 할 수 없다는 것을 알고 있습니다.

    여러 객체와 일련의 XML 구성 파일보다 10 줄의 코드만으로 응용 프로그램을 이해하는 것이 쉽습니다. 그러나 가장 강력한 디자인 패턴과 마찬가지로 시스템에 새로운 기능을 계속 추가 할 때 그 이득이 발견됩니다.

    즉, 대규모 DI 기반 응용 프로그램은 디버그하기 쉽고 이해하기 쉽습니다. Xml 구성이 '컴파일 시간 검사'가 아니지만이 작성자가 알고있는 모든 응용 프로그램 서비스는 호환되지 않는 인터페이스를 가진 객체를 다른 객체에 주입하려고 시도하면 개발자에게 오류 메시지를 제공합니다. 그리고 대부분은 알려진 모든 개체 구성을 다루는 '확인'기능을 제공합니다. 이것은 주입 된 객체 A가 모든 구성된 객체 주입에 대해 객체 B가 요구하는 인터페이스를 구현하는지 확인함으로써 쉽고 빠르게 수행됩니다.

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

    3.이것은로드 된 질문의 비트이지만, 나는 막대한 양의 XML 설정이 많은 이익을 얻지는 않는다는 것에 동의하는 경향이있다. 무거운 프레임 워크를 포함하여 가능한 한 의존성에 대해 밝히기 위해 내 응용 프로그램을 좋아합니다.

    이것은로드 된 질문의 비트이지만, 나는 막대한 양의 XML 설정이 많은 이익을 얻지는 않는다는 것에 동의하는 경향이있다. 무거운 프레임 워크를 포함하여 가능한 한 의존성에 대해 밝히기 위해 내 응용 프로그램을 좋아합니다.

    그들은 코드를 많은 시간을 단순화하지만, 복잡성에 오버 헤드가있어 문제를 추적하기가 어렵습니다. (저는 처음부터 이러한 문제를 보았고 곧바로 Java를 다루는 편이 훨씬 편할 것입니다).

    내 생각에 스타일에 따라 약간 달라지며 편안함을 느낄 수 있습니다 ... 자신 만의 솔루션을 선택하고 내부적으로 파악하는 이점을 누리거나 구성이 올바르지 않을 때 어려울 수있는 기존 솔루션을 활용하는 것이 좋습니다. 그냥? 그것은 모두 단점입니다.

    그러나 XML 설정은 내 애완 동물이 아니므로 ... 나는 그것을 피하려고 노력한다.

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

    4.언제든지 코드를 데이터로 변경하여 올바른 방향으로 나아갈 수 있습니다.

    언제든지 코드를 데이터로 변경하여 올바른 방향으로 나아갈 수 있습니다.

    데이터를 코딩하는 것은 코드 자체가 더 일반적이고 재사용 가능하다는 것을 의미합니다. 또한 데이터가 정확하게 맞는 언어로 지정 될 수 있음을 의미합니다.

    또한 XML 파일을 GUI 또는 다른 도구로 읽어 들여 실용적인 방식으로 쉽게 조작 할 수 있습니다. 코드 예제를 통해 어떻게 할 수 있습니까?

    나는 대부분의 사람들이 코드를 데이터로 구현할 것이라는 것을 끊임없이 고려하고 있으며, 코드를 훨씬 더 깨끗하게 남겨 둡니다. 나는 사람들이 데이터가 아닌 코드로 메뉴를 생성한다는 것을 상상할 수 없다는 것을 알았습니다 - 코드에서 그것을하는 것이 보일러 플레이트 때문에 명백히 잘못되었다는 것이 명백해야합니다.

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

    5.DI 컨테이너를 사용하는 이유는 단순히 getters와 setter 인 코드에 사전 구성된 10 억 개의 속성을 가질 필요가 없기 때문입니다. 새로운 X ()로 모든 사람들을 정말로 하드 코딩하고 싶습니까? 물론 기본값을 가질 수 있지만 DI 컨테이너를 사용하면 매우 간단하고 코드의 세부 사항에만 집중할 수있는 싱글 톤 (singleton)을 만들 수 있습니다.

    DI 컨테이너를 사용하는 이유는 단순히 getters와 setter 인 코드에 사전 구성된 10 억 개의 속성을 가질 필요가 없기 때문입니다. 새로운 X ()로 모든 사람들을 정말로 하드 코딩하고 싶습니까? 물론 기본값을 가질 수 있지만 DI 컨테이너를 사용하면 매우 간단하고 코드의 세부 사항에만 집중할 수있는 싱글 톤 (singleton)을 만들 수 있습니다.

    예를 들어, Spring에서는 InitializingBean 인터페이스를 구현하고 afterPropertiesSet 메소드를 추가 할 수 있습니다 (코드를 Spring에 연결하지 않도록 "init-method"를 지정할 수도 있습니다). 이러한 메소드를 사용하면 클래스 인스턴스의 필드로 지정된 인터페이스가 시작시 올바르게 구성되었는지 확인한 다음 getter 및 setter를 더 이상 null 검사하지 않아도됩니다 (단원을 스레드로부터 안전하게 유지할 수 있다고 가정 할 경우) ).

    DI 컨테이너를 사용하는 대신 복잡한 초기화 작업을하는 것이 훨씬 쉽습니다. 예를 들어 XFire (CeltiXFire가 아니라 Java 1.4 만 사용)를 사용합니다. 이 응용 프로그램은 Spring을 사용했지만 불행히도 XFire의 services.xml 구성 메커니즘을 사용했습니다. 하나 이상의 인스턴스가 아닌 ZERO 이상의 인스턴스가 있다고 선언해야하는 요소 컬렉션이 있으면이 특정 서비스에 대해 제공된 XFire 코드 중 일부를 재정의해야했습니다.

    Spring Bean 스키마에 정의 된 특정 XFire 기본값이 있습니다. 따라서 스프링을 사용하여 서비스를 구성하는 경우 Bean을 사용할 수 있습니다. 대신, beans를 사용하는 대신 services.xml 파일에 특정 클래스의 인스턴스를 제공해야한다는 것이 발생했습니다. 이를 위해 생성자를 제공하고 XFire 구성에 선언 된 참조를 설정해야했습니다. 내가해야 할 진정한 변화는 하나의 클래스에 과부하가 걸리도록 요구했습니다.

    그러나 services.xml 파일 덕분에, 나는 생성자의 Spring 설정 파일에있는 기본값에 따라 기본값을 설정하여 4 개의 새로운 클래스를 만들어야했다. 우리가 Spring 설정을 사용할 수 있었다면, 나는 방금 언급했을 수있다 :

    <bean id="base" parent="RootXFireBean">
    <property name="secondProperty" ref="secondBean" />
</bean>

<bean id="secondBean" parent="secondaryXFireBean">
    <property name="firstProperty" ref="thirdBean" />
</bean>

<bean id="thirdBean" parent="thirdXFireBean">
    <property name="secondProperty" ref="myNewBean" />
</bean>

<bean id="myNewBean" class="WowItsActuallyTheCodeThatChanged" />

    대신 다음과 같이 보입니다.

    public class TheFirstPointlessClass extends SomeXFireClass {
    public TheFirstPointlessClass() {
        setFirstProperty(new TheSecondPointlessClass());
        setSecondProperty(new TheThingThatWasHereBefore());
    }
}

public class TheSecondPointlessClass extends YetAnotherXFireClass {
    public TheSecondPointlessClass() {
        setFirstProperty(TheThirdPointlessClass());
    }
}

public class TheThirdPointlessClass extends GeeAnotherXFireClass {
    public TheThirdPointlessClass() {
        setFirstProperty(new AnotherThingThatWasHereBefore());
        setSecondProperty(new WowItsActuallyTheCodeThatChanged());
    }
}

public class WowItsActuallyTheCodeThatChanged extends TheXFireClassIActuallyCareAbout {
    public WowItsActuallyTheCodeThatChanged() {
    }

    public overrideTheMethod(Object[] arguments) {
        //Do overridden stuff
    }
}

    따라서 결과적으로 하나의 추가 클래스와 몇 가지 간단한 종속성 컨테이너 정보를 얻는 데 영향을 미치기 위해 코드베이스에 추가적으로 4 개의 추가 Java 클래스를 추가해야했습니다. 이것은 "규칙을 입증하는 예외"가 아닙니다. 이것은 규칙입니다 ... 코드의 처리 단점은 속성이 DI 컨테이너에 이미 제공되어 있고 특별한 상황에 맞게 간단히 변경하는 경우 훨씬 더 깔끔합니다. 이것은 종종 발생하지 않습니다.

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

    6.나는 너의 대답이있다.

    나는 너의 대답이있다.

    각 접근 방식에는 분명히 상충 관계가 있지만 외부화 된 XML 구성 파일은 IDE가 아닌 코드를 컴파일하는 데 사용되는 빌드 시스템을 사용하는 엔터프라이즈 개발에 유용합니다. 빌드 시스템을 사용하면 코드에 특정 값 (예 : 빌드 버전)을 주입 할 수 있습니다 (컴파일 할 때마다 수동으로 업데이트해야 함). 빌드 시스템이 일부 버전 제어 시스템에서 코드를 가져올 때 고통이 더 커졌습니다. 컴파일 시간에 단순 값을 수정하려면 파일을 변경하고, 커밋하고, 컴파일 한 다음, 변경 될 때마다 되돌릴 것을 요구합니다. 이는 버전 관리에 커밋 할 변경 사항이 아닙니다.

    빌드 시스템 및 외부 구성과 관련된 기타 유용한 사용 사례 :

    최신 정보: 위의 모든 예는 반드시 클래스에 대한 종속성을 필요로하지 않는 것들에 관한 것입니다. 복잡한 객체와 자동화가 모두 필요한 경우를 쉽게 구축 할 수 있습니다 (예 :

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

    7.구성 할 때마다 코드를 다시 컴파일 할 필요가 없습니다. 프로그램 배포 및 유지 관리가 간단 해집니다. 예를 들어 구성 파일을 한 번만 변경하면 한 구성 요소를 다른 구성 요소로 바꿀 수 있습니다.

    구성 할 때마다 코드를 다시 컴파일 할 필요가 없습니다. 프로그램 배포 및 유지 관리가 간단 해집니다. 예를 들어 구성 파일을 한 번만 변경하면 한 구성 요소를 다른 구성 요소로 바꿀 수 있습니다.

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

    8.여자 친구를위한 새로운 구현을 할 수 있습니다. 따라서 새로운 여성은 코드를 다시 컴파일하지 않고 삽입 할 수 있습니다.

    여자 친구를위한 새로운 구현을 할 수 있습니다. 따라서 새로운 여성은 코드를 다시 컴파일하지 않고 삽입 할 수 있습니다.

    <bean id="jane" class="foo.bar.HotFemale">
  <property name="age" value="19"/>
</bean>
<bean id="mary" class="foo.bar.Female">
  <property name="age" value="23"/>
</bean>
<bean id="john" class="foo.bar.Male">
  <property name="girlfriend" ref="jane"/>
</bean>

    (위의 예에서는 여성과 인기있는 여성이 동일한 Girlfriend 인터페이스를 구현한다고 가정합니다)

  9. ==============================

    9..NET 세계에서 대부분의 IoC 프레임 워크는 XML 및 코드 구성을 제공합니다.

    .NET 세계에서 대부분의 IoC 프레임 워크는 XML 및 코드 구성을 제공합니다.

    예를 들어, StructureMap과 Ninject는 유창한 인터페이스를 사용하여 컨테이너를 구성합니다. 더 이상 XML 구성 파일을 사용하지 않아도됩니다. Spring은 .NET에도 존재하지만 역사적인 주 구성 인터페이스이기 때문에 XML 파일에 크게 의존하지만 프로그래밍 방식으로 컨테이너를 구성 할 수 있습니다.

  10. ==============================

    10.부분 구성을 최종 구성으로 쉽게 결합 할 수 있습니다.

    부분 구성을 최종 구성으로 쉽게 결합 할 수 있습니다.

    예를 들어 웹 응용 프로그램에서 모델, 뷰 및 컨트롤러는 일반적으로 별도의 구성 파일에 지정됩니다. 선언적 접근법을 사용하여로드 할 수 있습니다. 예를 들면 다음과 같습니다.   UI-context.xml   Model-context.xml   Controller-context.xml

    또는 다른 UI와 몇 가지 추가 컨트롤러로로드 :   AlternateUI-context.xml   Model-context.xml   Controller-context.xml   ControllerAdditions-context.xml

    코드에서 동일한 작업을 수행하려면 부분 구성을 결합하기위한 인프라가 필요합니다. 코드에서는 불가능하지만 IoC 프레임 워크를 사용하는 것이 더 쉽습니다.

  11. ==============================

    11.중요한 점은 프로그램 작성 후 누가 구성을 변경하는지입니다. 코드의 구성을 사용하면 코드를 변경하는 사람이 원래 작성자와 동일한 기술과 소스 코드에 액세스 할 수 있음을 암묵적으로 가정합니다.

    중요한 점은 프로그램 작성 후 누가 구성을 변경하는지입니다. 코드의 구성을 사용하면 코드를 변경하는 사람이 원래 작성자와 동일한 기술과 소스 코드에 액세스 할 수 있음을 암묵적으로 가정합니다.

    프로덕션 시스템에서 일부 하위 설정 (예 : 예를 들어)을 XML 파일로 추출하여 예를 들어 시스템 관리자 또는 개인을 지원하여 소스 코드 또는 기타 설정에 대한 완전한 권한을 부여하지 않고도 가치를 변경하거나 복잡성으로부터 격리 할 수 ​​있습니다.

  12. ==============================

    12.Spring의 관점에서 저는 두 가지 대답을 줄 수 있습니다.

    Spring의 관점에서 저는 두 가지 대답을 줄 수 있습니다.

    먼저 XML 구성 만 구성을 정의하는 유일한 방법은 아닙니다. 어노테이션을 사용하여 대부분 구성 할 수 있으며 XML로 수행해야하는 작업은 라이브러리에서 사용하는 연결 풀과 같이 어쨌든 작성하지 않는 코드에 대한 구성입니다. 스프링 3에는 예제에서 손으로 구르는 DI 구성과 비슷한 Java를 사용하여 DI 구성을 정의하는 방법이 포함되어 있습니다. 따라서 Spring을 사용한다고해서 XML 기반의 설정 파일을 사용해야한다는 의미는 아닙니다.

    두 번째로 Spring은 단순한 DI 프레임 워크 이상입니다. 그것은 트랜잭션 관리 및 AOP를 포함하여 많은 다른 기능을 가지고 있습니다. Spring XML 설정은 이러한 모든 개념을 결합합니다. 종종 동일한 설정 파일에서 나는 백그라운드에서 AOP를 사용하여 실제로 처리 한 세션 의존적 인 bean을 추가하고, 트랜잭션 설정과 bean 의존성을 지정합니다. 필자는 XML 구성이 이러한 모든 기능을 관리 할 수있는 더 나은 곳을 제공한다는 사실을 알고 있습니다. 또한 주석 기반 구성 및 XML 구성이 Java 기반 구성보다 규모가 더 큰 것으로 생각됩니다.

    하지만 당신의 요지를 보았고 Java에서 종속성 삽입 구성을 정의하는 데있어 잘못된 점이 없습니다. 나는 일반적으로 단위 테스트에서 나 자신을한다. 그리고 내가 DI 프레임 워크를 추가하지 않은만큼 작은 프로젝트를 수행 할 때. Java에서는 일반적으로 구성을 지정하지 않으므로 Spring을 사용하기 위해 선택했을 때 필자가 작성하려고했던 종류의 배관 코드입니다. 그것은 기본 설정이지만 XML 구성이 Java 기반 구성보다 우월하다는 것을 의미하지는 않습니다.

  13. ==============================

    13.Spring은 또한 특성 로더를 가지고있다. 환경에 의존하는 변수 (예 : 개발, 테스트, 인수, 생산 등)를 설정하는 데이 메소드를 사용합니다. 예를 들어 대기 할 대기열 일 수 있습니다.

    Spring은 또한 특성 로더를 가지고있다. 환경에 의존하는 변수 (예 : 개발, 테스트, 인수, 생산 등)를 설정하는 데이 메소드를 사용합니다. 예를 들어 대기 할 대기열 일 수 있습니다.

    속성이 변경되는 이유가 없으면이 방법으로 구성 할 이유가 없습니다.

  14. ==============================

    14.귀하의 사례는 매우 간단하므로 Spring과 같은 IoC (Inversion of Control) 컨테이너가 필요하지 않습니다. 반면에, "구현이 아닌 인터페이스 프로그래밍"(OOP의 우수 사례)에서는 다음과 같은 코드를 사용할 수 있습니다.

    귀하의 사례는 매우 간단하므로 Spring과 같은 IoC (Inversion of Control) 컨테이너가 필요하지 않습니다. 반면에, "구현이 아닌 인터페이스 프로그래밍"(OOP의 우수 사례)에서는 다음과 같은 코드를 사용할 수 있습니다.

    IService myService;
// ...
public void doSomething() {
  myService.fetchData();
}

    (myService의 유형은 IService, 즉 구체적인 구현이 아니라 인터페이스 임). 이제는 IoC 컨테이너가 초기화하는 동안 IService의 정확한 구체적인 인스턴스를 자동으로 제공하게하는 것이 편리 할 수 ​​있습니다. 많은 인터페이스와 구현이 많은 경우 수동으로 수행하는 것이 번거로울 수 있습니다. IoC 컨테이너 (의존성 주입 프레임 워크)의 주요 이점은 다음과 같습니다.

  15. ==============================

    15.XML 설정 파일에서 초기화하면 컴퓨터에 앱을 배포 한 클라이언트와의 디버깅 / 작업을 단순화 할 수 있습니다. (재 컴파일 + 바이너리 파일 대체가 필요 없기 때문에)

    XML 설정 파일에서 초기화하면 컴퓨터에 앱을 배포 한 클라이언트와의 디버깅 / 작업을 단순화 할 수 있습니다. (재 컴파일 + 바이너리 파일 대체가 필요 없기 때문에)

  16. ==============================

    16.가장 매력적인 이유 중 하나는 "할리우드 원칙"입니다. 전화하지 마시고 전화 드리겠습니다. 구성 요소는 다른 구성 요소 및 서비스 자체에 대한 검색을 수행 할 필요가 없습니다. 대신 자동으로 제공됩니다. Java에서는 구성 요소 내부에서 JNDI 조회를 수행 할 필요가 없다는 것을 의미합니다.

    가장 매력적인 이유 중 하나는 "할리우드 원칙"입니다. 전화하지 마시고 전화 드리겠습니다. 구성 요소는 다른 구성 요소 및 서비스 자체에 대한 검색을 수행 할 필요가 없습니다. 대신 자동으로 제공됩니다. Java에서는 구성 요소 내부에서 JNDI 조회를 수행 할 필요가 없다는 것을 의미합니다.

    또한 구성 요소를 단위 테스트하는 것이 훨씬 쉽습니다. 필요한 구성 요소의 실제 구현을 제공하는 대신 단순히 (자동으로 생성 된) 모의를 사용하기 만하면됩니다.

    17. from https://stackoverflow.com/questions/131975/what-are-the-benefits-of-dependency-injection-containers by cc-by-sa and MIT license

'SPRING' 카테고리의 다른 글

[SPRING] DAO 및 서비스 계층 (JPA / Hibernate + Spring) [duplicate]  (0) 2018.12.21
[SPRING] 스프링 보안을 이용한 유닛 테스트  (0) 2018.12.21
[SPRING] Spring-MVC 컨트롤러에서 트리거 404?  (0) 2018.12.21
[SPRING] Spring RESTful 애플리케이션을 위해 ResponseEntity <T>와 @RestController를 사용할 때  (0) 2018.12.21
[SPRING] Spring의 GA, RC 및 M2 릴리스의 차이점은 무엇입니까?  (0) 2018.12.21
,

티스토리툴바