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

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

의존성 주입의 장점 자체는 이해한다.봄을 예로 들어보자.또한 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>

다음과 같은 기존 Java 코드와 비교합니다.

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

디버깅이 용이하고 컴파일 시간이 체크되어 자바만 아는 사람이라면 누구나 이해할 수 있습니다.그렇다면 의존성 주입 프레임워크의 주요 목적은 무엇일까요?(또는 그 장점을 나타내는 코드 조각)

---

★★★★★★★
★★★의

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

여러 개의 MyService 구현이 있는 경우 IoC 프레임워크는 어떤 구현을 삽입해야 하는지 어떻게 추측할 수 있습니까?특정 인터페이스의 구현이 1개뿐이고 IoC 컨테이너가 자동으로 사용 여부를 결정하게 하면 두 번째 구현이 나타난 후 중단됩니다.또, 인터페이스의 실장이 의도적으로1개 밖에 없는 경우는, 인터페이스를 삽입할 필요가 없습니다.

IoC의 장점을 보여주는 작은 구성을 보면 매우 흥미로울 것입니다.스프링을 사용한 지 꽤 됐는데 그런 예를 들어줄 수 없어요.또한 휴지 상태, dwr 및 내가 사용하는 다른 프레임워크의 장점을 보여주는 한 줄을 표시할 수 있습니다.

---

2 데: 2 :
IoC를 이용하다말말그 렇렇 ??? ???재컴파일하지 않고 DB 자격 증명을 변경하려는 경우를 이해할 수 있습니다. 이치노실제로 개발자가 아닌 다른 사용자가 IOC 구성을 얼마나 자주 변경합니까?개발자의 경우 구성을 변경하는 대신 특정 클래스를 다시 컴파일하는 작업이 필요하지 않다고 생각합니다.또한 개발자가 아닌 경우, 개발자의 생활을 보다 쉽게 하고 보다 간단한 구성 파일을 제공해야 합니다.

---

업데이트 3:

인터페이스와 그 구체적인 실장 간의 매핑의 외부 설정

그것을 정상화하는 것이 무엇이 그렇게 좋은가?모든 코드를 외부로 만들지는 않지만 ClassName.java.txt 파일에 저장하여 바로 수동으로 읽고 컴파일할 수 있습니다.와, 재컴파일을 피할 수 있었습니다.컴파일을 피해야 하는 이유는 무엇입니까?

절차 코드가 아닌 선언적으로 매핑을 제공하므로 코딩 시간이 절약됩니다.

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

Inversion of Control 원칙은 실제 구현을 가짜 구현으로 대체할 수 있기 때문에 유닛 테스트가 용이합니다(예를 들어 SQL 데이터베이스를 메모리 내 데이터베이스로 교체).

제어의 이점 반전을 이해하고 있습니다(여기서 설명하는 설계 패턴을 의존성 주입이라고 부릅니다. 왜냐하면 IoC는 보다 일반적이고 여러 종류의 제어가 있으며 그 중 한 가지인 초기화의 제어만 반전시키고 있기 때문입니다).왜 프로그래밍 언어가 아닌 다른 언어가 필요하냐고 물어본 거야코드를 사용하여 실제 구현을 가짜로 대체할 수 있습니다.또한 이 코드는 구성과 동일한 것을 나타냅니다. 즉, 가짜 값으로 필드를 초기화합니다.

mary = new FakeFemale();

나는 DI의 장점을 이해한다.외부 XML 설정에 의해, 같은 기능을 하는 코드를 설정하는 것에 비해, 어떠한 메리트가 추가되는지를 이해할 수 없습니다.나는 편찬이 피해야 한다고 생각하지 않는다 - 나는 매일 편찬하고 있고 여전히 살아있다.나는 DI의 구성이 선언적 접근의 나쁜 예라고 생각한다.선언은 한 번 선언되고 빈 속성과 DB 열 간의 매핑이 검색 쿼리를 저장, 로드, 빌드하는 데 사용되는 등 여러 가지 방법으로 여러 번 사용되는 경우 유용합니다.스프링 DI 의 설정은, 이 질문의 선두와 같이, 간단하게 코드의 설정으로 변환할 수 있습니다.그리고 그것은 콩 초기화에만 사용되죠?선언적 접근은 여기에 아무것도 추가하지 않는다는 뜻이죠, 그렇죠?

휴지 상태 매핑을 선언할 때 휴지 상태 정보를 제공하기만 하면 됩니다.동면 상태에 따라 동작합니다.어떻게 해야 하는지 지시하지 않습니다.봄의 경우, 나의 선언은 정확히 무엇을 해야 하는지 봄에게 말한다 - 그렇다면 왜 그것을 선언하고, 왜 그냥 하지 않는가?

---

UPDATE : 종종 last last last :
여러분, 많은 답변들이 의존성 주입에 대해 말해주고 있어요. ★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★문제는 코드를 초기화하는 것이 아니라 DI 설정의 목적에 관한 것입니다.코드 초기화가 더 짧고 명확하다고 생각하는 경향이 있습니다.지금까지 질문에 대한 답변은 구성이 변경되었을 때 재컴파일을 피할 수 있다는 것뿐입니다.이 경우 컴파일을 피해야 하는 이유는 저에게 큰 비밀이기 때문에 질문을 하나 더 올려야 할 것 같습니다.

IOC(및 외부 구성 사용)를 사용하는 주된 이유 중 하나는 다음 두 가지 영역입니다.

• 테스트
• 생산 유지 보수

테스트

테스트를 3개의 시나리오로 분할하는 경우(대규모 개발에서는 매우 일반적입니다).

1. 유닛 테스트
2. 통합 테스트
3. 블랙박스 테스트

마지막 2개의 테스트 시나리오(연동 및 블랙박스)에서는 어플리케이션의 어떤 부분도 재컴파일하지 않습니다.

테스트 시나리오 중 하나라도 구성을 변경해야 하는 경우(즉, 다른 컴포넌트를 사용하여 뱅킹 통합을 모방하거나 성능 부하를 수행함)에는 쉽게 대처할 수 있습니다(이는 IOC의 DI 측을 구성하는 이점에도 해당됩니다).

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

생산.

개발자는 실제 운영 환경을 제어할 수 없습니다(특히 애플리케이션이 여러 고객 또는 별도의 사이트에 배포되는 경우). IOC와 외부 구성을 모두 사용하는 것이 진정한 장점입니다. 라이브 환경을 조정하고 조정하는 것은 인프라스트럭처/실운영 지원에 달려 있기 때문입니다.테스트(컴포넌트 이동만 원하는 경우 비용 절감)를 통해 개발자에게 돌아갈 필요가 없습니다.

요약

IoC의 외부 구성의 주된 이점은 개발자가 아닌 다른 사람에게 애플리케이션을 구성할 수 있는 권한을 부여하는 것입니다.제 경험상, 이것은 다음과 같은 한정된 상황에서만 도움이 됩니다.

• 애플리케이션은 환경이 다른 여러 사이트/클라이언트에 배포됩니다.
• 실가동 환경 및 셋업에 대한 개발 제어/입력 제한
• 테스트 시나리오

실제로 환경을 제어할 수 있는 것을 개발하더라도 실행이 이루어지므로 시간이 지남에 따라 다른 사용자에게 구성을 변경할 수 있는 기능을 제공하는 것이 좋습니다.

• 개발 시에는 언제 바뀔지 모릅니다(어플리케이션은 매우 유용하기 때문에 다른 사람에게 판매합니다).
• 좋은 설정 모델을 셋업하고 사용함으로써 처리할 수 있었던 약간의 변경이 요구될 때마다 코드를 변경하는 것에 얽매이고 싶지 않습니다.

주의: 어플리케이션이란 완전한 솔루션(실행 파일뿐만 아니라)을 의미하므로 어플리케이션 실행에 필요한 모든 파일을 말합니다.

의존성 주입은 객체 위임이 일반적으로 객체 상속보다 더 유용한 설계 패턴이라는 관찰에 뿌리를 둔 코딩 스타일입니다(즉, 객체가 가지고 있는 관계가 객체가 있는 관계보다 더 유용합니다).그러나 DI가 작동하기 위해서는 오브젝트인터페이스 작성이라는 다른 요소가 필요합니다.이 두 가지 강력한 설계 패턴을 결합함으로써 소프트웨어 엔지니어는 유연하고 느슨하게 결합된 코드를 만들 수 있다는 것을 금방 깨닫고 의존성 주입의 개념이 탄생했습니다.그러나 특정 고급 언어로 물체 반사가 가능해진 후에야 DI가 실제로 성공했습니다.반사 컴포넌트는 오늘날 대부분의 DI 시스템에서 핵심입니다.DI의 정말 멋진 측면에는 프로그래밍 방식으로 객체를 선택하고 객체 자체와 독립적인 시스템을 사용하여 객체를 구성하고 다른 객체에 주입할 수 있는 기능이 필요하기 때문입니다.

언어는 일반 객체 지향 프로그래밍 기술뿐만 아니라 객체 인터페이스와 객체 리플렉션(Java 및 C# 등)을 지원해야 합니다.C++ 시스템에서는 DI 패턴을 사용하여 프로그램을 구축할 수 있지만 언어 내에서 리플렉션이 지원되지 않기 때문에 응용 프로그램서버 및 기타 DI 플랫폼을 지원할 수 없기 때문에 DI 패턴의 표현성이 제한됩니다.

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

1. DI 코드는, 「확장」기능이 올바르게 정의된 인터페이스에 외삽되어 적절한 애플리케이션 플랫폼에 의해서 처리되는 개별의 오브젝트를 자유롭게 다른 오브젝트에 접속할 수 있기 때문에, 재이용이 훨씬 쉬워집니다.
2. DI 코드는 테스트하기 훨씬 쉽습니다.오브젝트에 의해 표현되는 기능은 어플리케이션 로직에서 기대되는 인터페이스를 구현하는 'mock' 오브젝트를 빌드함으로써 블랙박스에서 테스트할 수 있습니다.
3. DI 코드는 유연성이 높다.이것은 본질적으로 느슨하게 결합된 코드입니다. 극단적으로요.이를 통해 프로그래머는 한쪽 끝의 필수 인터페이스와 다른 한쪽 끝의 표현된 인터페이스를 기반으로 오브젝트가 어떻게 연결되어 있는지를 선택하고 선택할 수 있습니다.
4. DI 오브젝트의 외부(Xml) 설정은 다른 사용자가 예기치 않은 방향으로 코드를 커스터마이즈할 수 있음을 의미합니다.
5. 외부 설정은 오브젝트 초기화 및 오브젝트 상호의존관리의 모든 문제를 어플리케이션서버가 처리할 수 있는 문제 패턴의 분리이기도 합니다.
6. DI 패턴을 사용하기 위해서 외부 설정이 필요 없는 것에 주의해 주세요.단순한 상호 접속에서는 소형 빌더 오브젝트가 적절합니다.그 둘 사이에는 유연성의 트레이드오프가 있다.빌더 개체는 외부에서 볼 수 있는 구성 파일만큼 유연한 옵션이 아닙니다.DI 시스템 개발자는 컨피규레이션파일에 나타난 바와 같이 오브젝트 구조에 대한 소규모 미세 제어로 혼란과 유지보수 비용이 증가할 수 있다는 점에 유의하면서 유연성의 이점을 고려해야 합니다.

확실히 DI 코드가 더 번거로워 보입니다.다른 오브젝트에 삽입할 오브젝트를 설정하는 모든 XML 파일을 가지고 있는 것의 단점은 어려워 보입니다.그러나 이것이 DI 시스템의 포인트입니다.코드 객체를 일련의 구성 설정으로 조합할 수 있기 때문에 최소한의 코딩으로 서드파티 코드를 사용하여 복잡한 시스템을 구축할 수 있습니다.

질문에서 제시된 예는 적절한 계수를 가진 DI 객체 라이브러리가 제공할 수 있는 표현력의 표면만을 다루고 있습니다.많은 DI 실무자들은 어느 정도 연습과 자기 훈련을 통해 애플리케이션 코드를 100% 테스트 대상으로 하는 시스템을 구축할 수 있다는 것을 알게 되었습니다.이 한 점만으로도 대단합니다.이는 수백 줄의 코드로 이루어진 소규모 애플리케이션에 대한 100% 테스트 적용 범위가 아니라 수십만 줄의 코드로 구성된 애플리케이션에 대한 100% 테스트 적용 범위입니다.이 정도 수준의 테스트 가능성을 제공하는 다른 디자인 패턴을 설명할 수 없습니다.

10s 행의 코드만 적용해도 여러 개체와 일련의 XML 구성 파일보다 이해하기 쉽다는 점에서 정답입니다.그러나 가장 강력한 설계 패턴과 마찬가지로 새로운 기능을 시스템에 계속 추가할 때 이점을 얻을 수 있습니다.

즉, 대규모 DI 기반 애플리케이션은 디버깅이 쉽고 이해하기 쉽습니다.XML 설정은 '컴파일 시간 체크'되지 않지만, 이 작성자가 알고 있는 모든 응용 프로그램서비스는 호환되지 않는 인터페이스를 가진 개체를 다른 개체에 삽입하려고 하면 개발자에게 오류 메시지를 제공합니다.또한 대부분의 경우 알려진 모든 개체 구성을 포함하는 '확인' 기능을 제공합니다.이것은 오브젝트 A가 설정된 모든 오브젝트 주입에 대해 오브젝트 B에서 필요한 인터페이스를 구현하고 있는지 확인하는 것으로 쉽고 빠르게 실행할 수 있습니다.

이것은 다소 부담스러운 질문이지만, 대량의 xml 설정은 그다지 도움이 되지 않는다는 데 동의하는 경향이 있습니다.어플리케이션의 부하가 높은 프레임워크 등 의존성을 가능한 한 가볍게 하고 싶다.

코드를 심플하게 하는 경우가 많지만, 복잡성의 오버헤드가 있어 문제를 추적하는 것이 상당히 어렵습니다(직접 본 적이 있기 때문에, 스트레이트 Java를 사용하는 것이 훨씬 편리합니다).

스타일에 따라 다르겠지만, 당신이 어떤 것에 익숙한지...독자적인 솔루션을 도입해, 알기 쉽게 하는 메리트를 얻고 싶은가, 아니면 구성이 적절하지 않은 경우는 곤란할 가능성이 있는 기존의 솔루션에 의지하고 싶은가?이건 모두 트레이드오프야.

다만 XML 설정은 조금 귀찮은 부분이 있습니다.나는 무슨 일이 있어도 그것을 피하려고 한다.

코드를 데이터로 변경할 수 있는 경우 올바른 방향으로 나아가고 있습니다.

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

또, XML 파일을 GUI나 다른 툴에 읽어 들여 실용적으로 간단하게 조작할 수 있습니다.코드 예제를 사용하면 어떻게 할 수 있을까요?

대부분의 사람들이 구현한 코드들을 데이터에 지속적으로 반영하고 있습니다. 그러면 어떤 코드가 훨씬 더 깔끔하게 남아있게 됩니다.사람들이 데이터가 아닌 코드로 메뉴를 만든다는 것은 상상할 수 없는 일입니다.코드로 메뉴를 만드는 것은 보일러 플레이트 때문에 명백히 잘못된 것입니다.

DI 컨테이너를 사용하는 이유는 단순히 getter와 setter인 코드에 10억 개의 속성을 미리 구성할 필요가 없기 때문입니다.새로운 X()로 모든 것을 하드코드하시겠습니까?디폴트 설정도 가능합니다만, DI 컨테이너를 사용하면 싱글톤을 작성할 수 있기 때문에, 코드의 초기화에 관한 여러가지 태스크가 아니고, 코드의 상세 내용에 초점을 맞출 수 있습니다.

예를 들어 Spring을 사용하면 InitializingBean 인터페이스를 구현하고 afterProperties를 추가할 수 있습니다.method를 설정합니다(코드를 스프링에 결합하지 않도록 "init-method"를 지정할 수도 있습니다).이러한 메서드를 사용하면 클래스인스턴스에서 필드로 지정된 인터페이스가 부팅 시 올바르게 설정되어 있는지 확인할 수 있습니다.게터 및 세터를 늘 체크할 필요가 없어집니다(싱글톤을 스레드 세이프 상태로 유지하는 것을 전제로 합니다).

또한 DI 컨테이너를 사용하여 복잡한 초기화를 직접 수행하는 것이 훨씬 쉽습니다.예를 들어, 저는 XFire 사용을 지원합니다(CeltiXFire가 아니라 Java 1.4만 사용).앱은 Spring을 사용했지만 안타깝게도 XFire의 services.xml 구성 메커니즘을 사용했습니다.요소 컬렉션이 하나 이상의 인스턴스가 아닌 ZERO 이상의 인스턴스가 있음을 선언하기 위해 필요한 경우 이 특정 서비스에 대해 제공된 XFire 코드 중 일부를 재정의해야 했습니다.

스프링 콩 스키마에는 특정 XFire 기본값이 정의되어 있습니다.따라서 Spring을 사용하여 서비스를 구성했다면 콩을 사용할 수 있었을 것입니다.대신 bean을 사용하는 대신 services.xml 파일에 특정 클래스의 인스턴스를 입력해야 했습니다.이를 위해 저는 컨스트럭터를 제공하고 XFire 구성에서 선언된 참조를 설정해야 했습니다.내가 해야 할 진짜 변화는 하나의 수업에 과부하가 걸리게 했다.

그러나 services.xml 파일 덕분에 4개의 클래스를 새로 만들어야 했습니다.이러한 클래스는 컨스트럭터의 Spring Configuration파일의 디폴트에 따라 설정됩니다.스프링 구성을 사용할 수 있었다면 다음과 같이 말할 수 있었을 것입니다.

<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 컨테이너에 포함되어 있고 특별한 상황에 맞게 변경하기만 하면 코드의 변덕을 처리하는 것이 훨씬 깨끗해집니다.

당신의 답을 알고 있습니다.

각 접근 방식에는 분명히 단점이 있지만 외부 XML 구성 파일은 IDE가 아닌 빌드 시스템을 사용하여 코드를 컴파일하는 엔터프라이즈 개발에 유용합니다.빌드 시스템을 사용하면 빌드 버전 등 특정 값을 코드에 삽입할 수 있습니다(컴파일할 때마다 수동으로 업데이트해야 하는 번거로움).빌드 시스템이 일부 버전 관리 시스템에서 코드를 제거할 경우 더 큰 문제가 발생합니다.컴파일 시 간단한 값을 수정하려면 파일을 변경하고 커밋하며 컴파일한 후 매번 변경해야 합니다.이러한 변경은 버전 제어에 적용할 수 없습니다.

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

• 여러 빌드에 대한 단일 코드 베이스에 대한 스타일/스타일시트 주입
• 단일 코드 기반에 대해 다양한 동적 콘텐츠 세트(또는 이에 대한 참조)를 주입합니다.
• 다른 빌드/프로세서용 현지화 컨텍스트 삽입
• 웹 서비스 URI를 백업서버로 변경(메인 서버가 다운되었을 때)

업데이트: 위의 예제는 모두 클래스에 의존할 필요가 없는 항목에 대한 것입니다.그러나 다음과 같이 복잡한 개체와 자동화가 모두 필요한 사례를 쉽게 구축할 수 있습니다.

• 웹 사이트의 트래픽을 모니터링하는 시스템이 있다고 가정해 보십시오.동시 사용자 수에 따라 로깅 메커니즘이 켜지거나 꺼집니다.아마도 메커니즘이 꺼진 동안 stub 객체가 그 자리에 배치될 것입니다.
• 사용자 수에 따라 참가자의 수에 따라 P2P 기능을 전환하는 웹 회의 시스템이 있다고 가정합니다.

구성에서 무언가를 변경할 때마다 코드를 다시 컴파일할 필요가 없습니다.프로그램의 도입과 유지보수가 심플해집니다.예를 들어 구성 파일을 하나만 변경하면 구성 요소를 다른 구성 요소와 스왑할 수 있습니다.

여자친구를 위한 새로운 구현을 시작할 수 있습니다.그래서 코드를 다시 작성하지 않고도 새로운 여성을 주입할 수 있습니다.

<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>

(상기에서는 암컷과 핫 암컷이 같은 GirlfFriend 인터페이스를 실장하고 있는 것을 전제로 하고 있습니다).

에서.NET World, 대부분의 IOC 프레임워크는 XML과 코드 구성을 모두 제공합니다.

예를 들어 StructureMap 및 Ninject는 fluent 인터페이스를 사용하여 컨테이너를 설정합니다.XML 컨피규레이션파일을 사용하는 제약이 없어졌습니다.스프링(에도 있습니다)NET은 XML 파일이 이력 메인 구성 인터페이스이기 때문에 XML 파일에 크게 의존하지만 컨테이너를 프로그래밍 방식으로 구성할 수도 있습니다.

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

예를 들어 웹 응용 프로그램에서는 모델, 뷰 및 컨트롤러가 일반적으로 별도의 구성 파일로 지정됩니다.접근방식을 할 수 .

  UI-context.xml
  Model-context.xml
  Controller-context.xml

다른 와 몇 의 추가 합니다. or 、 른 、 UI 、 or 、 or 、 or 、 llersllersllersllersllers or or or 。

  AlternateUI-context.xml
  Model-context.xml
  Controller-context.xml
  ControllerAdditions-context.xml

코드에서 동일한 작업을 수행하려면 부분 구성을 결합하기 위한 인프라가 필요합니다.코드로 할 수 없는 것은 아니지만 IoC 프레임워크를 사용하여 할 수 있는 것은 확실히 용이합니다.

대부분의 경우 중요한 것은 프로그램 작성 후 누가 구성을 변경하느냐입니다.코드의 설정에서는, 그것을 변경하는 사람이 원래의 작성자와 같은 스킬과 소스 코드 등에 액세스 할 수 있다고 암묵적으로 가정합니다.

프로덕션 시스템에서는 일부 설정 서브셋(예: 사용 기간)을 XML 파일로 추출하여 시스템 관리자나 지원 담당자 등에게 소스 코드나 기타 설정에 대한 완전한 권한을 부여하지 않고 값을 변경할 수 있도록 하거나 단순히 복잡함에서 분리하는 것이 매우 실용적입니다.

봄의 관점에서 두 가지 답을 드릴 수 있습니다.

우선 XML 설정만이 설정을 정의하는 방법은 아닙니다.대부분의 작업은 주석을 사용하여 구성할 수 있으며 XML을 사용하여 수행해야 하는 작업은 라이브러리에서 사용하는 연결 풀과 같이 기록되지 않은 코드에 대한 구성입니다.스프링 3 에는, 예시의 핸드 롤 DI 설정과 같은 Java 를 사용해 DI 설정을 정의하는 방법이 포함되어 있습니다.따라서 Spring을 사용한다고 해서 XML 기반 구성 파일을 사용할 필요가 있는 것은 아닙니다.

둘째, 봄은 단순한 DI 프레임워크 그 이상입니다.트랜잭션 관리 및 AOP를 비롯한 많은 기능을 갖추고 있습니다.Spring XML 설정에서는 이러한 모든 개념이 혼재됩니다.대부분의 경우 동일한 구성 파일에서 빈 종속성, 트랜잭션 설정을 지정하고 백그라운드에서 실제로 AOP를 사용하여 처리한 세션 범위 빈을 추가합니다.XML 설정은 이러한 모든 기능을 관리하기에 더 좋은 장소라고 생각합니다.또한 주석 기반 구성 및 XML 구성이 Java 기반 구성보다 더 잘 확장된다고 느낍니다.

하지만 당신의 요점을 알겠고 Java에서 종속성 주입 구성을 정의하는 데 아무런 문제가 없습니다.보통 유닛 테스트나 DI 프레임워크를 추가하지 않은 작은 프로젝트를 수행할 때 직접 수행합니다.보통 자바에서는 설정을 지정하지 않습니다.스프링 사용을 선택했을 때 이 코드를 쓰는 것을 피하고 싶기 때문입니다.이는 기본 설정입니다.XML 구성이 Java 기반 구성보다 우수하다는 의미는 아닙니다.

스프링에는 속성 로더도 있습니다.이 방법을 사용하여 환경에 따라 달라지는 변수(개발, 테스트, 수용, 생산 등)를 설정합니다.예를 들어 리슨할 큐가 될 수 있습니다.

속성이 변경될 이유가 없는 경우 이 방법으로 속성을 구성할 필요도 없습니다.

매우 간단한 케이스이므로 Spring과 같은 IOC(Inversion of Control) 컨테이너가 필요하지 않습니다.한편, 「실장이 아닌 인터페이스에 프로그램 한다」(OOP 의 좋은 프랙티스)에서는, 다음과 같은 코드를 설정할 수 있습니다.

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

(myService의 유형은 IService(구체적인 구현이 아닌 인터페이스)입니다).IoC 컨테이너가 초기화 중에 적절한 IService 인스턴스를 자동으로 제공할 수 있게 되었습니다.인터페이스가 많고 구현이 많은 경우 수작업이 번거로울 수 있습니다.IoC 컨테이너(의존성 주입 프레임워크)의 주요 이점은 다음과 같습니다.

• 인터페이스와 그 구체적인 실장 간의 매핑의 외부 설정
• IoC 컨테이너는 복잡한 의존관계 그래프 해결, 컴포넌트 수명 관리 등 까다로운 문제를 처리합니다.
• 절차 코드가 아닌 선언적으로 매핑을 제공하므로 코딩 시간이 절약됩니다.
• Inversion of Control 원칙은 실제 구현을 가짜 구현으로 대체할 수 있기 때문에 유닛 테스트가 용이합니다(예를 들어 SQL 데이터베이스를 메모리 내 데이터베이스로 교체).

XML 컨피규레이션파일로 초기화하면 어플리케이션을 컴퓨터에 전개하고 있는 클라이언트와의 디버깅/적응 작업이 심플해집니다.(재컴파일+바이너리 파일 교환이 필요 없기 때문에)

가장 매력적인 이유 중 하나는 "할리우드 원칙"입니다. 전화하지 마세요. 전화 드리겠습니다.컴포넌트는 다른 컴포넌트 및 서비스 자체에 대한 조회를 수행할 필요가 없습니다.대신 컴포넌트에는 자동으로 제공됩니다.Java에서는 컴포넌트 내에서 JNDI 조회를 수행할 필요가 없어졌습니다.

또한 컴포넌트를 분리하여 유닛 테스트를 수행하는 것이 훨씬 쉽습니다.컴포넌트에 필요한 컴포넌트를 실제로 실장하는 것이 아니라 단순히 (자동으로 생성되는) 모크를 사용합니다.

언급URL : https://stackoverflow.com/questions/131975/what-are-the-benefits-of-dependency-injection-containers