- 관심사의 분리.
- 클라이언트는 내가 어떤 오브젝트를 사용하는지에 관심이없다.
- 생성및 관계설정의 책임을 DaoFactory에게 위임한다.
- 원래는 각각의 클래스가 가지고 있던 의존성 책임을 -> DaoFactory에게 위임하고. 각각의 클래스는 본연의 비지니스 역할(콘택스트) 에만 집중할 수 있게된다.
- 결국 이 DaoFactory가 일종의 applicationContext로서 Ioc를 담당
- 프레임워크와 라이브러리의 차이는 제어의 흐름이 누구에게 있는가이다.
- 스프링은 '시간'을 '관계'를 담당해준다.
- 각종 오브젝트들을 적절한 시간에 만들고, 그 오브젝트들의 관계를 넣어준다.
- 우리는 비지니스 로직을 공개하지 않고 코드를 짤수있게 된다.
- 위코드 확인 : 먼저 빈들을 싱글톤으로 등록해두고 -> 클라이언트가 해당 빈을 요청하면 -> getBean으로 찾아서 리턴한다.
<용어 정리>
- bean:
스프링이 관리하는 오브젝트. 모든 객체가 빈이 아니라, 스프링이 직접 생명주기를 관리해야만 빈이라고 부른다.
- bean factory
: 빈의 생명주기와 관계설정을 관리하는 클래스. 보통은 빈 팩토리 클래스를 막바로 사용하기보다 어플리케이션 콘텍스트 클래스를 불러서 사용한다.
- applicationContext :
빈 팩토리를 상속한다. 빈생명주기 + 스프링이 제공하는 부가적인 기능 .
- 직접 제작한 DaoFactory 에서 만들어낸 userDao클래스는 각각 다른 메모리값이 할당된 별개의 인스턴스이다.
반면 @Configuration어노테이션을 통해 ApplicationContext를 생성하고,
이를 통해 Bean Factory 에서 불러낸 UserDao클래스는 동일하다. 테스트 케이스 초록불을 확인할 수 있다.
즉 스프링은 기본적으로 빈을 생성할때 싱글톤 전략을 사용한다. 하지만 왜일까?
- 번외) 동일성과 동등성
동일성 : 물리적 동일성. 같은 메모리상에 위치한다. 기본적으로 Object의 equals메소드는 동일성비교를 한다. (==)
동등성 : 논리적으로 같은가. 특정기준에 의해서 같은 인스턴스임을 보장한다. 단 이때 물리적 메모리 할당값은 다를 수 있다. (equals)
- 스프링이 싱글톤으로 빈을 생성하는 이유
: 일단 기본적인 자바 싱글톤 전략을 직접 사용한다고 했을때 발생하는 문제점이 여럿있다.
private생성자이므로 상속불가하고 , 확장불가하고, 테스트 하기 어려워진다. 밖에서 생성할수가 없으니..
그리고 서버환경에서는 반드시 한개만 만들어진다고 보장할 수도 없다.
-> 그렇지만, 싱글톤으로 생성하는 것 적극지지 - 왜냐하면, 유저의 요청에 따라 계속해서 클래스를 생성하면 메모리가 절대로 못버텨난다.
- 스프링은 자바의 전통적인 싱글톤 전략 대신 Ioc를 이용하여 빈을 싱글톤으로 생성하고 관리한다.
- 싱글톤사용시 주의점
: 멀티스레드 환경에서는 객체가 공유되기 때문에 주의한다 .
따라서 -> 상태stateless해야한다. 변경되는 상태값을 가지고 있으면 안된다.
- 변경될수있는 값은 파라메터로 혹은 지역변수로 전달한다. 이건 스택에 쌓이는 정보이므로 공유되지 않으므로 괜찮다.
- 혹은 읽기전용 변수 / 혹은 다른 싱글톤객체를 인스턴스 변수로 가지고 있는 것은 괜찮다.
댓글 없음:
댓글 쓰기