GO CAN DO IT

ApplicationContext는 Bean Factory의 역할 + Spring의 여러가지 기능들을 담당하고 있다. 이 ApplicationContext는 다음과 같은 인터페이스들을 상속받고 있는데 ApplicationEventPublisher EnvironmentCapable HierarchicalBeanFactory ListableBeanFactory MessageSource ResourceLoader ResourcePatternResolver 이들 중 가장 먼저 살펴볼 것은, EnvionmentCapable 인터페이스이다. 이 Environment가 제공하는 기능은 크게 프로파일과 프로퍼티로 나눌 수 있는데, 먼저 프로파일에 대해 알아보자. 1. 프로파일 인터페이스 이 프로파일은 개발/ 운영서버가..

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, 제어권이 없는 오브젝트들..

1.1 초난감 DAO : 대충 메소드도 분리되어있지 않고 DB 커넥션도 없는 DAO를 스프링에 맞게 업그레이드 시켜보자는 Intro 1.2 DAO의 분리 1.2.3 DB커넥션 만들기의 독립 - 만약 UserDao라는 클래스의 getConnection이라는 메소드를 분리하고 싶을 때, '상속'과 추상메소드를 통해 분리할 수 있다. public abstract class UserDao{ public void add(User user) throws ClassNotFoundException, SQLException{ Connection c = getConnection(); } public abstract getConnection() throws ClassNotFoundException, SQLException;..