ApplicationContext의 동작 방식

1. @Configuration/@Bean을 사용하여 Application Context에 빈을 등록
2. 클라이언트가 해당 빈을 요청
3. 해당 빈을 Application Context에서 조회한 후 빈의 생성을 빈팩토리에 요청
4. 빈팩토리에서 해당 요청을 받아 빈을 생성
5. 클라이언트가 생성된 객체를 사용
   ApplicationContext에 요청을 보내면 등록된 빈을 목록을 참고하여 해당되는 빈팩토리를 이용해 빈을 생성합니다.

ApplicationContext의 장점

• 클라이언트는 구체적인 팩토리 클래스를 몰라도 됩니다.
• 어플리케이션 컨텍스트가 빈을 자동으로 관리해줍니다.
• 빈을 쉽게 찾을 수 있게 여러 방식을 제공합니다.

스프링 IoC 용어 정리

• 빈: 스프링이 직접 그 생성과 제어를 담당하는 오브젝트 입니다.
• 빈 팩토리: IoC를 담당하는 핵심 컨테이너로 보통은 직접 사용하기보다는 이를 확장한 애플리케이션 컨텍스트를 사용합니다.
• 애플리케이션 컨텍스트: 빈팩토리를 확장한 IoC 컨테이너 입니다. 빈팩토리 뿐만아니라 여러 스프링의 부가기능도 함께 불러온 컨테이너라고 보면 됩니다.
• 설정정보/설정 메타정보: 컨테이너에 기능을 설정하거나, 어플리케이션 오브젝트를 생성하고 구성할 때 사용합니다.
• 컨테이너 vs IoC 컨테이너: 컨테이너는 애플리케이션 컨텍스트를, IoC 컨테이너는 빈을 관리하는 빈팩토리와 관련된 내용에서 사용됩니다.
• 스프링 컨테이너/프레임워크: IoC 컨테이너 + 어플리케이션 컨텍스트 x N

싱글톤 레지스트리 & 오브젝트 스코프

싱글톤 패턴의 한계

• private 생성자로 인해 상속 불가합니다.
• 테스트가 어려움이 있습니다.
• 싱글톤이 깨질 가능성이 있습니다.
• 전역상태로 만들어져 접근을 제한하지 못합니다.

싱글톤 레지스트리

스프링은 평범한 싱글톤 자바 코드를 직접 관리하여 위의 문제를 대체로 보완하거나 해결해준다.

싱글톤 주의점

싱글톤 레지스트리에서 관리하여 준다고 할지라도 싱글톤이 깨지는 문제는 매우 위험할 수 있습니다. 이때를 방지하기 위해 지역변수의 개념을 활용하여 메서드 별로 독립적으로 처리될 수 있도록 하여야 한다. 단, 해당 변수가 읽기전용으로만 사용된다면 전역으로 불러올지라도 싱글톤이 깨지는 문제는 발생하지 않아 괜찮습니다. 수정이 문제입니다. 그리고 읽기전용이라면 static final / final을 선언하여 더 안정된 구조를 갖출 수도 있습니다.

Scope

빈이 생성, 존재, 적용되는 범위(생명주기)를 말합니다. 싱글톤이 아닌 빈은 Scope를 갖고 있습니다. 대부분의 빈은 싱글톤 빈이지만 그 외에도 prototype, request, session 스코프도 있습니다. 예를들어, Session Scope는 세션과 생명주기를 같이하여 로그인 된 회원들 마다의 정보를 관리할 수 있습니다.

DI (Dependency Injection)

스프링 IoC라는 용어가 갖는 너무 많은 의미에서 핵심만을 짚어내기 위해 의존관계 주입(DI)라는 새로운 용어가 생겼습니다. DI는 필요로 하는 오브젝트를 수동적으로 외부에서 주입하도록 제어권한을 외부로 위임하는 방식입니다. 이를 통해 의존관계를 역전시키는 제어의 역전을 실현할 수 있게 됩니다.

DI 방식: Constructor, Setter, method

기본적으로 DI는 생성자, 수정자, 메서드 등 다양한 방법으로 적용할 수 있습니다. 각각의 장단점은 파라미터의 갯수 등과 같은 요인에 따라 명확해지기 때문에 적절히 사용해야 합니다. 예를들어, 생성자는 한번에 여러 파라미터를 입력할 때 좋습니다. 대신 실수를 유발하기 쉽습니다. 반면에 Setter는 한번에 하나의 파라미터만 전달할 수 있어 명확하지만 불편할 수 있습니다. 메서드를 이용해 주입한다면 좀 더 set*이라는 이름과 파라미터의 갯수로부터 자유로운 구조를 적용할 수 있습니다.

DL (Dependency Lookup)

DI와 반대되는 개념의 방식인 DL도 있습니다. DL은 외부로부터 주입 받지 않고 내부에서 검색하여 빈을 불러오게 됩니다. 일반적으로는 DI를 사용하는 것이 훨씬 더 간편하고, 적절합니다. 대신 DL을 사용할 경우 검색을 하는 주체인 클래스가 빈으로 등록 되어있지 않아도 된다는 장점이 있어 필요할 경우 사용하게 됩니다.

XML Configuration

• xml을 사용한 DI는 컴파일이 필요하지 않다는 점에서 장점이 있습니다.
• xml 태그들이 주는 투박함이 있지만 각각의 요소들을 생각보다 간단한 구조입니다

Java Configuration vs XML Configuration

• @Configuration : \
• @Bean methodName : \<bean id=“methodName”
• Return new BeanClasses(); : class=“a.b.c..BeanClass”>
• setter(“value”) : \

출처: "토비의 스프링 3.1" - 이일민