티스토리 뷰

## 토비의 스프링 3.1 스터디 후 정리한 내용으로 토비의 스프링 책이 바탕으로 되어있다.



제어의 역전(IoC)과 싱글톤 레지스트리



제어의 역전 IoC Inversion of Control (p.92~)


제어의 역전이란?


프로그램의 제어 프름구조가 뒤바뀌는 것

 제어의 흐름의 개념을 거꾸로 뒤집는 것

오브젝트가 자신이 사용할 오브젝트를 스스로 선택하지 않는다. 당연히 생성하지도 않는다.

또 자신도 어떻게 만들어지고 어디서 사용되는지를 알 수 없다. 모든 제어 권한을 자신이 아닌 다른 대상에게 위임하기 때문이다.



라이브러리 VS 프레임워크


* 라이브러리 : 라이브러리를 사용하는 애플리케이션 코드는 애플리케이션 흐름을 직접 제어한다.

* 프레임워크 : 거꾸로 어플리케이션 코드가 프레임워크에 의해 사용된다. 보통 프레임워크 위에 개발한 클래스를 등록해 두고, 프레임워크가 흐름을 주도하는 중에 개발자가 만든 애플리케이션 코드를 사용하도록 만드는 방식이다.

프레임워크에는 분명한 제어의 역전 개념이 적용되어 있어야 한다.



스프링의 IoC


빈 : 스프링이 제어권을 가지고 직접 만들고 관계를 부여하는 오브젝트

스프링 빈 : 스프링 컨테이너가 생성, 관계설정, 사용등을 제어해주는 제어의 역전이 적용된 오브젝트

빈팩토리 / 애플리케이션 컨텍스트 : 빈의 생성과 관계 설정 같은 제어를 담당하는 IoC 오브젝트



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



+) DaoFactory(p.88)를 오브젝트로 직접 사용했을 때 vs 애플리케이션 컨텍스트를 사용했을 때

 

- 클라이언트는 구체적인 팩토리 클래스를 알 필요가 없다.

- 애플리케이션 컨텍스트는 종합 IoC 서비스를 제공한다.








싱글톤 레지스트리와 오브젝트 스코프 (p.102)



오브젝트 Factory vs 애플리케이션 컨텍스트 (가장 큰 차이점)


오브젝트 Factory : new DaoFactory / 2개의 객체 생성시 2개는 다른 객체

애플리케이션 컨텍스트 : getBean("userDao", UserDao.class); / 2개의 객체 생성시 2개는 같은 객체

                                => 스프링은 여러번에 걸쳐 빈을 요청하더라도 매번 동일한 오브젝트를 돌려준다.




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


애플리케이션 컨텍스트IoC 컨테이너이면서 싱글톤을 저장하고 관리하는 싱글톤 레지스트리이다.

(별 다른 설정을 하지 않으면 내부에서 생성하는 빈 오브젝트를 모두 싱글톤으로 만든다. but 디자인 패턴의 싱글톤과 다르다!)



?? why? 스프링은 왜 싱글톤으로 빈을 만들까?

=> 스프링이 주로 적용되는 대상이 자바 엔터프라이즈 기술을 사용하는 서버환경이기 때문이다.


+) 자바 엔터프라이즈 환경 : 대량 네트워크 환경, 분산 환경, 웹 환경

=> 대량의 request를 받아 처리할 수 있는 높은 성능이 요구되는 환경.

각각의 객체를 생성하게 되면 부하가 높아진다.

(서블릿 또한 대부분 멀티스레드 환경에서 싱글톤으로 동작한다.)



* 디자인 패턴에서의 싱글톤 패턴 단점

pricate 생성자 -> 상속, 다형성 사용할 수 없음

테스트의 어려움

전역변수이기 때문에 접근, 수정 시 의도치 않은 구현 발생 가능





싱글톤 레지스트리


스프링은 서버환경에서 싱글톤이 만들어져서 서비스오브젝트 방식으로 사용되는 것을 적극 지지한다.

하지만 자바의 기본적인 싱글톤 패턴의 구현 방식은 여러가지 단점이 있기 때문에, 스프링은 직접 싱글톤 형태의 오브젝트를 만들고 관리하는 기능을 제공한다.

그것이 바로 싱글톤 레지스트리다.


스태틱 메소드와 private 생성자를 사용해야 하는 비정상적인 클래스가 아니라 평범한 자바 클래스라도 IoC 방식의 컨테이터를 사용해서 생성, 관계설정, 사용등에 대한 제어권을 컨테이너에게 넘기면 손쉽게 싱글톤 방식으로 만들어져 관리되게 할 수 있다.


스프링의 싱글톤 레지스트리 덕분에 싱글톤 방식으로 사용될 애플리케이션 클래스라도 public 생성자를 가질 수 있다.

=> 스프링은 IoC 컨테이너일 뿐만 아니라, 고전적인 싱글톤 패턴을 대신해서 싱글톤을 만들고 관리해주는 싱글톤 레지스트리이다.





싱글톤과 오브젝트의 상태


싱글톤은 멀티스레드라면 여러스레드가 동시에 접근이 가능하다.

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

다중 사용자의 요청을 한꺼번에 처리하는 스레드들이 동시에 싱글톤 오브젝트의 인스턴스 변수를 수정하는 것은 매우 위험하다. (저장공간이 하나뿐이니 덮어 쓸 수 있음)

따라서 싱글톤은 기본적으로 인스턴스 필드의 값을 변경하고 유지하는 상태유지 방식으로 만들지 않는다.

정보(변수)들은 파라미터 변수, 로컬 변수, 리턴 값 등을 이용하면 된다.



p.110 코드 참조


Connection c; 

User user;

=> 로컬 변수로 저장. new 할 때 마다 매번 새로운 값으로 바뀔 수 있음. 개별적으로 사용하거나 파라미터로 받아서 사용 (p.76)


그렇다면 connectionMarker는? 인스턴스 변수로 저장되어 있다!  사용이 가능한가?

=> 그렇다. connectionMarker는 읽기 전용 정보이기 때문이다.

@Bean을 만들어 생성. 스프링이 관리하는 Bean! 싱글톤으로 하나의 객체만 생성


이렇게 자신이 사용하는 다른 싱글톤 빈을 저장하려는 용도라면 인스턴스 변수를 사용해도 좋다.




댓글
댓글쓰기 폼
공지사항
Total
79,514
Today
3
Yesterday
74
링크
TAG
more
«   2021/06   »
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30      
글 보관함