GO CAN DO IT

Bean의 Scope는 기본적으로 싱글톤이다. 프로그램 구동시 Bean의 인스턴스는 오직 하나라는 뜻이다. Bean이 가질수 있는 Scope 는 싱글톤 외에 매번 인스턴스를 새로 생성하는 ProtoType 도 있다. 만약, 프로토 타입 빈이 싱글톤 빈을 참조하면 어떻게 될까? 매번 프로토타입의 빈은 새로운 인스턴스로 생성되고, 그 인스턴스들이 바라보는 싱글톤 빈은 동일한 인스턴스일 것이다. 이럴 때는 아무런 문제가 되지 않는다. 그렇다면, 싱글톤 빈이 프로토 타입 빈을 참조하면 어떻게 될까? 싱글톤이 생성 된 이후에 프로토타입 빈이 변경이 되어도 해당 내용이 업데이트가 되지 않는다. 이를 업데이트하려면 Scoped-proxy값을 설정해주거나, 참조시 참조 객체를 Object-Provider 리스트로 감싸..

여기 BookRepository 객체와, BookRepository 객체를 사용하는 BookService 객체가 있다고 가정해보자. 그리고 이 BookService 객체에서 BookRepository 객체를 주입받아야 하는 상황에서 BookService는 Bean으로 등록을 해주고, BookRepository 는 Bean으로 등록을 하지 않았다고 해보자. // #1. BookService @Service public class BookService { BookRepository bookrepository; @Autowired public void BookService(BookRepository bookRepository){ this.bookRepository = bookRepository; } } // ..

#스프링 IoC 토비의 스프링에서 먼저 공부한 스프링 IoC에 대해 다시 한번 리마인드를 해보자. First, IoC stands for Inversion Of Control 즉 제어의 역전이라는 뜻이다. 스프링 프레임워크 안에서의 객체들은 자신들이 사용할 객체들을 스스로 생성하지도 않고, 자기 자신들도 어디서 사용되는지 알 수가 없다. 오브젝트들의 생성과 책임에 대한 제어가 오브젝트 스스로에게 있지 않고, 이 권한을 위임한 다른 특별한 오브젝트에게 있다! 오브젝트의 입장에서는 그 특별한 오브젝트로부터 생성과 책임에 대해 제어를 받으니 control의 방향이 inversed 된 것이다. 그리고 이러한 IoC방식에서 말하는 특별한 Object를 Application Context, 제어권이 없는 오브젝트들..