1장. 오브젝트 의존관계2

토비 스프링을 공부하면서 실습했던 내용과 모르는 내용만 기록을 위해서 포스팅한다.

 

1.5 스프링의 IOC

1.5.1 오브젝트 팩토리를 이용한 스프링 IoC

실습 코드 링크: https://github.com/vvshinevv/toby-spring/tree/feature/1.5.1

스프링에서 빈 팩토리라고 말할 때는 빈을 생성하고 관계를 설정하는 IoC의 기본 기능에 초점을 맞춘 것이고, 애플리케이션 컨텍스르라고 말할 때는 애플리케이션 전반에 걸쳐 모든 구성요소의 제어 작업을 담당하는 IoC 엔진이라는 의미가 좀 더 부각된다.

 

1.5.2 애플리케이션 컨텍스트의 동작 방식

애플리케이션 컨텍스트는 1) DaoFactory 클래스를 설정정보로 등록해두고 @Bean이 붙은 메소드 이름을 가져와 빈 목록을 만들어둔다. 2) 클라이언트가 애플리케이션 컨텍스트의 getBean() 메소드를 호출하면 자신의 빈 목록에서 요청한 이름이 있는지 찾고 3) 있다면 빈을 생성하는 메소드를 호출해서 오브젝트를 생성시킨 후 클라이언트에게 돌려준다.

 

1.5.3 스프링 IoC의 용어 정리

1. 빈(bean)

 - 스프링이 IoC 방식으로 관리하는 오브젝트라는 뜻이다. 스프링이 직접 그 생성과 제어를 담당하는 오브젝트만을 빈이라고 부른다.

2. 빈 팩토리(bean factory)

 - 핵심 IoC 컨테이너이다. 빈을 생성하고 조회하고 돌려주고 그 외 부가적인 빈 관리를 하는 기능을 담당한다.

3. 애플리케이션 컨텍스트(application context)

 - 빈 팩토리를 확장한 IoC 컨테이너이다. 빈 팩토리와 동일하지만, 스프링이 제공하는 각종 부가 서비스를 추가로 제공한다.

4. 설정 정보 / 설정 메타 정보

 - 애플리케이션 컨텍스트 또는 빈 팩토리가 IoC를 적용하기 위해 사용하는 메타 정보이다. 

5. 컨테이너 또는 IoC 컨테이너

 - IoC 방식으로 빈을 관리한다는 측면에서 애플리케이션 컨텍스트나 빈 팩토리를 컨테이너 또는 IoC 컨테이너라고 한다. 애플리케이션 컨텍스트 오브젝트는 하나의 애플리케이션에서 보통 여러 개가 만들어져서 사용된다. 스터디에서 어러 개가 만들어 진다는 말에 의논을 했었다. 이말은 Spring boot의 경우 애플리케이션에서 1개의 애플리케이션 컨텍스트로 관리하지만, Spring MVC에서는 하나의 애플리케이션에서 여러 개의 어플리케이션 컨텍스로 관리할 수 있다. 

Dispatcher 서블릿에 2개의 애플리케이션 컨텍스트가 관리된다.

6. 스프링 프레임워크

 - 스프링이 제공하는 모든 기능을 통틀어 말할 때 주로 사용

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

오브젝트의 동일성과 동등성이란 말이 있는데 동일성은 레퍼런스가 같다는 말이고, 동등성은 참조하는 값이 같다는 말이다. 스프링의 빈(객체)은 싱글톤으로 생성이 되며, 여러 번에 걸쳐 빈을 요청하더라도 매번 동일한 오브젝트를 돌려준다. 

 

1.6.1 싱글톤 레지스트리로서의 애플리케이션 컨텍스트

스프링이 싱글톤으로 빈을 만드는 이유는 스프링이 주로 적용되는 대상이 자바 엔터프라이즈 기술을 사용하는 서버환경이기 때문이다. 서버 하나 당 최대로 초당 수십에서 수백 번씩 브라우저나 여타 시스템으로부터의 요청을 받아 처리할 수 있는 높은 성능이 요구된다. 매번 클라이언트에서 요청이 올 때마다 각 로직을 담당하는 오브젝트를 새로 만든다고 하면 그 리소스는 엄청날 것이다. 그래서 엔터프라이즈 분야에서는 서비스 오브젝트라는 개념을 일찍부터 사용해왔다. 스터디에서 서비스 오브젝트라는 말을 많이 쓰는지에 대해서 이야기가 나왔는데 서비스 오브젝트라는 말은 싱글톤으로 동작하는 서비스라고 이해했다. 대표적으로 서블릿이있다.

 

1.6.2 싱글톤과 오브젝트의 상태

싱글톤은 멀티스레드 환경이라면 여러 스레드가 동시에 접근해서 사용할 수 있다. 기본적으로 싱글톤이 멀티스레드 환경에서 서비스 형태의 오브젝트로 사용되는 경우에는 상태정보를 내부에 갖고 있지 않는 무상태 방식으로 만들어져야 한다.

 

1.6.2 스프링 빈의 스코프

스프링에서 스코프는 싱글톤 스코프와 프로토타입 스코프가 있다. 프로토타입 스코프는 싱글톤과 달리 컨터이너에 빈을 요청할 때마다 매번 새로운 오브젝트를 만들어준다.

 

1.7 의존관계 주입(DI)

1.7.1 제어의 역전과 의존관계 주입

DI는 오브젝트 레퍼런스를 외부로부터 제공(주입) 받고 이를 통해 여타 오브젝트와 다이내믹하게 의존관계가 만들어지는 것이다.

 

1.7.2 런타임 의존관계 설정

의존한다는 건 의존 대상, 즉 B 클래스가 A 클래스에 영향을 미친다고 할때 A는 B에 의존한다고 말한다. 의존관계에는 방향성이 있다. 모델이나 코드에서 클래스와 인터페이스를 통해 드러나는 의존관계 말고, 런타임 시에 오브젝트 사이에서 만들어지는 의존관계도 있다. 인터페이스를 통해서 설계 시점에 느슨한 의존관계를 갖는 경우에는 런타임 시에 사용할 오브젝트가 어떤 클래스인지 미리 알 수가 없다. 즉 코드 속에 드러나지 않는 다는 말이다. 이런 것을 의존 오브젝트라고 말한다.

런타임 시에 의존 오브젝트를 사용할 수 있도록 그 레퍼런스를 전달받는 과정이 마치 메소드를 통해 DI 컨테이너가 UserDao에게 주입해주는 것과 같아서 의존관계 주입이라고 부른다.

 

1.7.3 의존관계 검색과 주입

의존관계 검색은 의존 관계를 맺는 방식이 외부로부터의 주입이 아니라 스스로 검색을 한다는 뜻이다. 의존관계 주입의 경우 UserDao와 ConnectionMaker 사이에 DI가 적용되려면 두 클래스 모두 빈 오브젝트여야 한다. 반면에 검색은 하나만 빈 오브젝트이기만하면 된다.

 

1.7.4 의존관계 주입의 응용

실습 코드 링크: https://github.com/vvshinevv/toby-spring/tree/feature/1.7.4

 

1.7.5 메소드를 이용한 의존관계 주입

실습 코드 링크: https://github.com/vvshinevv/toby-spring/tree/feature/1.7.5

---

[참고자료]

토비 스프링 vol.1 - 이일민