전문가를 위한 스프링5 - 3장 정리(2)

필드 주입의 단점

1. 의존성을 추가하기가 쉽지만 단일 책임 원칙을 위반하지 않도록 주의해야 함. 많은 의존성이 생기면 클래스에 대한 책임이 커지므로 리팩터링 시에 관심사를 분리하기 어려움.

 

2. 의존성 주입의 책임은 스프링의 컨테이너에게 있지만, 필드 주입을 사용하면 어떤 타입의 의존성이 실제로 필요한지 의존성이 필수인지 여부가 명확하지 않을 수 있음.

 

3. 필드 주입은 final 필드에 사용할 수 없음.

 

4. 필드 주입은 의존성을 수동으로 주입해야 하므로 테스트 코드를 작성하기 어려움.

 

@Component를 사용하면 기본적으로 @Service와 동일한 효과 가능

둘 중 어떤 어노테이션이라도 적용한 클래스는 애너테이션 기반 구성의 자동 검출과 클래스 경로 스캐닝의 대상이 됨

 

@Service는 @Component의 특수한 형태이며, @Service 애노테이션이 사용된 클래스는 애플리케이션 내의 다른 레이어에게 비지니스 서비스를 제공하고 있음을 나타냄.

 

@Autowired 대신 @Resource 애너테이션을 사용한 이유?

-> @Autowired 애너테이션이 배열, 컬렉션, 맵을 해당 컬렉션의 값 타입에서 파생된 대상 빈 타입을 가져와 처리하기 때문이다. 클래스에 List 타입의 애트리뷰트가 있고, @Autowired 애너테이션이 적용되어 있었다면 스프링은 구성 파일에 선언된 <util:list> 대신 현재 ApplicationContext 내의 ContentHolder 타입의 모든 빈을 해당 애트리뷰트에 주입하려 시도하기 때문에 의도하지 않은 의존성이 주입될 수 있음.

@Autowired와 @Qualifier를 사용하여 해결 가능

 

싱글턴 패턴

전역 변수를 사용하지 않고 객체를 하나만 생성 하도록 하며, 생성된 객체를 어디에서든지 참조할 수 있도록 하는 패턴
작업 : 하나의 인스턴스만을 생성하는 책임이 있으며 getInstance 메서드를 통해 모든 클라이언트에게 동일한 인스턴스를 반환하는 작업을 수행한다.

 

메서드 대체를 사용해야 될 때

동일 타입의 모든 빈이 아닌 단일 빈에 대한 특정 메서드만 대체하려는 경우에 유용하다.

 

빈 명명 규칙 이해하기

<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
    <bean id="string1" class="java.lang.String"/>
    <bean name="string2" class="java.lang.String"/>
    <bean class="java.lang.String"/>
</beans>

 

빈 생성 방식 이해하기

스프링의 모든 빈 -> 싱글턴

스프링은 빈의 단일 인스턴스를 유지하고 관리하며, 모든 의존 객체는 동일한 인스턴스를 사용한다.

싱글턴: 애플리케이션 내에 단일 인스턴스를 갖는 객체

싱글턴 패턴:  싱글턴 디자인 패턴을 나타내려는 목적으로 상호 교환적 사용

 

싱글턴 패턴: 클래스가 단일 인스턴스로 동작하도록 관리

인터페이스를 완전히 사용할수 없는 객체 룩업을 위한 패턴

 

싱글턴이 아닌 타입(프로토타입)

프로토타입 스코프: 스프링은 애플리케이션이 빈 인스턴스를 요청할때 마다 새 인스턴스 생성

빈 객체가 서로 다른 것

 

인스턴스 생성 방식

 

싱글턴

상태가 없는 공유 객체

읽기 전용 상태를 갖는 공유 객체

공유 상태를 갖는 공유 객체

 

비싱글턴

쓰기 가능한 상태를 갖는 객체

private 상태를 갖는 오브젝트 

 

요청(Request): 웹 애플리케이션에서 스프링 MVC를 사용할때 요청 스코프를 가진 빈의 인스턴스는 HTTP 요청마다 생성되고 완료되면 소멸

세션(Session): 웹 애플리케이션에서 사용되고, http 세션이 시작되면 생성되고 세션이 끝나면 소멸

 

의존성 해석하기

스프링은 구성을 통해서 명시하지 않으면 사용자 빈 사이에 어떤 의존성도 인식하지 못함.

ApplicationContext를 가져오는 수정자를 구현한 빈은 스프링 IOC 컨테이너에 의해 자동으로 감지되고, 해당 빈 내부에 생성된 ApplicationContext가 주입됨.

 

빈에 좌동와이어링하기

 

byName : 이름에 의한 자동와이어링

 

byType: 타입에 의한 자동와이어링

 

생성자: 타입에 의한 와이어링과 같음

 

default: 스프링은 Constructor 방식과 byType 방식을 자동으로 선택

 

main() 메서드는 단순히 ApplicationContext에 선언된 각각의 Target 타입 빈을 검색해 자동와이어링이 이루어지게 합니다.

1. 타입에 의한 자동와이어링

2. 이름에 의한 자동와이어링

3. 생성자에 의한 자동와이어링

 

타입에 의한 자동와이어링을 하는 경우

같은 인터페이스를 구현한 클래스가 여러 개이고, 자동와이어링을 원하는 프로퍼티가 타입으로 인터페이스를 지정할 때 예외 발생

 

-> 빈 정의에서 primary 애트리뷰트의 값을 true로 설정하여 빈을 먼저 사용하도록 하는 것 (2개 빈 타입 존재하는 경우)

-> 빈 이름을 지정하고 xml로 주입할 위치를 구성하는 방법(복잡)

-> @Autowired 애터네이션, 주입돼야 하는 빈의 이름을 인자로 전달하는 @Qualifier 애노테이션 적용함(@Lazy)

: 기본 자동와이어링 방식이 byType임

 

@Primary 애너테이션 -> 타입 기반으로 자동와이어링을 할때 스프링에게 자신의 빈을 우선순위를 높게 지정

더 많은 관련 빈 타입 처리 -> @Qualifier 애너테이션

 

자동와이어링을 사용하는 경우

-> 중요한 애플리케이션이라면 자동 와이어링 사용 x

 

빈 상속 결정하기

 

같은 타입의 빈이나 공유 인터페이스를 구현하는 빈을 여러개 정의할 필요가 있음

스프링이 parent 빈을 child 빈의 부모로 간주해 구성을 상속해야 함을 나타냄.

 

AppliactionContext에서 부모 빈 정의를 룩업할 수 없게 하려면 parent 빈을 선언할 때 <bean> 태그에 abstract="true" 애트리뷰트를 추가할 수 있음. 

 

자식 빈은 부모 빈에서 생성자 인수와 프로퍼티 값을 상속받음