5. 스프링 컨테이너
: DispatcherServlet에 의해 생성되어지는 객체들은 어디서 관리될까?
5.1 ApplicationContext
: 생성된 객체들은 ApplicationContext 에 등록되고 이를 IoC(제어의 역전)라고 한다. 앞선 글에서 알 수 있듯이 개발자가 직접 new를 통해 객체를 생성하게 되면 해당 객체를 가르키는 레퍼런스 변수를 관리하기 어렵게 된다. 그래서 스프링은 IoC를 통해 객체들을 직접 메모리에 올리고 관리한다.이로 인해 개발자는 객체에 대한 레퍼런스 변수를 직접 관리할 필요가 없어지고, 생성된 객체들을 필요할 때 DI(의존성 주입)해 사용하면 된다. 즉, 이는 필요한 곳에서 ApplicationContext에 접근해 객체를 가져올 수 있다는 의미이다. ApplicationContext는 싱글톤으로 관리되므로 어디서 접근하든 동일한 객체라는 것을 보증해준다.
5.2 ApplicationContext의 종류
- servelet-applicationContext : ViewResolver, Interceptor, MultipartResolver 객체를 생성하고 웹과 관련된 어노테이션 Controller,RestController 를 스캔한다.(해당 파일들은 DispatchServlet에 의해 실행된다.)
- root-applicationContext: 해당 어노테이션을 제외 어노테이션 Service,Repository등을 스캔(메모리에 로딩)하고, DB관련 객체를 생성한다.(해당 파일들은 ContexLoadertListener에 의해 실행되고, ContexLoadertListener 를 실행해주는 녀석은 web.xml 이므로, root-applicationContext는 servelet-applicationContext 보다 먼저 로드된다. servelet-applicationContext 에서는 root-applicationContext가 로드한 객체를 참조할 수 있지만, 그 반대는 불가능하다.생성 시점이 다르기 때문이다.)
5.3 Bean Factory(메소드 위에 @configuration을 붙여서 이용한다.)
필요한 객체를 Bean Factory에 등록할 수도 있다. Bean Factory에 등록 시 메모리에 로드되지 않고,필요할 때 getBean()이라는 메소드를 이용해 호출한 뒤 메모리에 로드할 수 있고, 이 또한 IoC에 의해 관리된다.그리고 필요할 때, DI하여 사용할 수 있다. ApplicationContext와 다른 점은 Bean Factory에 로드되는 객체들은 미리 로드되지 않고, 필요할 때 호출해 로드하기 때문에 lazy-loading 된다는 점이다.
'Spring' 카테고리의 다른 글
[Security]Spring Security와 JWT (2) | 2024.12.09 |
---|---|
[메타코딩] 13강. 스프링 부트의 동작원리? (0) | 2023.10.02 |
[메타코딩] 11강. 스프링 부트의 동작원리? (0) | 2023.09.25 |
[메타코딩] 10강. 스프링 부트의 동작원리? (1) | 2023.09.24 |
[메타코딩] 9강. 스프링 부트의 동작원리? (1) | 2023.09.21 |