💡 Bean Scope 지금까지 한 실습에서 스프링 빈이 스프링 컨테이너의 시작과 함께 생성되어 스프링 컨테이너가 종료될 때까지, 유지한다고 학습했다. 이것은 스프링 빈이 기본적으로 싱글톤 스코프로 생성이 되기 때문. 스코프는 번역 그대로 빈이 존재할 수 있는 범위를 뜻함 스프링의 싱글톤 스코프 지원 범위 '싱글톤' 기본 스코프, 스프링 컨테이너의 시작과 종료까지 유지되는 가장 넓은 범위의 스코프 '프로토타입' 스프링 컨테이너는 프로토타입 빈의 생성과 의존관계 주입까지만 관여하는 매우 짧은 범위의 스코프 '웹 관련 스코프' 'request' = 웹 하나 요청이 들어오고 나갈때 까지(각각의 요청 따로) 유지되는 스코프 'session' = 웹 세션이 생성되고 종료될때 까지 유지되는 스코프 'applicat..

💡 종료 메소드 추론, Bean 초기화 외부 라이브러리를 수동 Bean으로 등록할때, 대부분의 라이브러리의 종료메소드 이름은 close,shutdown 이름의 메소드를 자동으로 호출. @Bean의 destroyMethod 의 기본값은 (inferred) (추론)으로 등록되어있다 따라서 직접 스프링빈으로 등록하면 종료 메소드는 따로 적어주지 않아도 됨 추론 기능을 비활성화 하고 싶으면 destroyMethod를 ""로 지정해주면 됨 권장하지 않는 방법 @PostConstruct, @PreDestroy 어노테이션을 이용한 초기화 스프링에서 권장하는 방법 javax.annotation 패키지이며, 스프링 종속기술이 아닌 JSR-250이라는 자바 표준으로 다른 컨테이너에서도 동작함 컴포넌트 스캔과 잘 어울린다 ..

💡 의존관계 자동 주입 의존관계 주입의 4가지 방법 생성자 주입 수정자 주입(Setter) 필드 주입 일반 메소드 주입 생성자 주입 생성자 호출 시점에 딱 1번만 호출되는 것이 보장됨 보통 '불변,필수' 의존관계에 사용 중요! 생성자가 딱 1개만 있으면 @Autowired를 생략해도 자동 주입됨 (스프링 빈에만 해당) 수정자 주입(Setter) 선언한 필드를 Setter를 사용해서 각각의 set 마다 @Autowired를 해줌 '선택,변경' 가능성이 있는 의존관계에 사용 @Autowired(required = false) 를 해주면 주입 대상이 없어도 정상동작하게 할 수 있음 수정자 주입의 단점으로는 public으로 열려있기 때문에 보안관점에서 좋지 않다 필드 주입 말 그대로 필드 옆에 @Autowire..

💡 Component Scan 지금까지 스프링 빈을 등록할때 @Bean이나 XML의 을 통해서 등록을 했다 예제는 몇개 안되지만 실무에선 수백개가 넘기 떄문에 귀찮고 누락 문제도 발생 그래서 설정정보 없이도 자동으로 스프링 빈을 등록하는 컴포넌트 스캔을 사용한다 또, 의존관계도 자동으로 주입하는 @Autowired 기능도 제공한다 바로 코드로 알아보자, 기존의 AppConfig는 학습용으로 냅두고 새로운 AutoAppConfig 클래스를 생성한다 탐색 위치와 기본 스캔 대상 일반적으로 프로젝트 최상단에 @ComponentScan을 잡으면 된다 @ComponentScan(basePackages = "hello.core) = 탐색위치 지정 @ComponentScan(basePackages = {"hello...

💡 @Configuration과 Singleton @Configuration은 Singleton을 위해서 존재함 AppConfig 파일에서 보면 memberRepository 객체가 2번 생성되는것 처럼 보인다 그럼 Singleton이 깨지는 건가? 하고 생각할 수 있으므로 테스트를 통해 알아보자 💡 바이트코드 조작 스프링 컨테이너는 싱글톤 레지스트리다 따라서 스프링 컨테이너는 스프링 빈이 싱글톤이 되도록 보장해줘야햠 그때 사용하는것이 클래스의 바이트코드를 조작하는 라이브러리 사용 모든 비밀은 @Configuration을 조작한 AppConfig에 있다 아래의 코드 예시를 보자 AnnotationConfigApplicationContext에 파라미터로 넘긴 값은 스프링 빈으로 등록된다, 즉 AppConf..

💡 Singleton Container 스프링 컨테이너는 싱글톤 패턴의 문제점을 해결하면서, 객체 인스턴스를 싱글톤(1개만 생성)으로 관리한다. 지금까지 우리가 학습한 스프링 빈이 바로 싱글톤으로 관리되는 빈이다. 스프링 컨테이너는 싱글턴 패턴을 적용하지 않아도, 객체 인스턴스를 싱글톤으로 관리한다. 이전에 설명한 컨테이너 생성 과정을 자세히 보자. 컨테이너는 객체를 하나만 생성해서 관리한다. 스프링 컨테이너는 싱글톤 컨테이너 역할을 한다. 이렇게 싱글톤 객체를 생성하고 관리하는 기능을 싱글톤 레지스트리라 한다. 스프링 컨테이너의 이런 기능 덕분에 싱글턴 패턴의 모든 단점을 해결하면서 객체를 싱글톤으로 유지할 수 있다. 싱글톤 패턴을 위한 지저분한 코드가 들어가지 않아도 된다. DIP & OCP 위반, ..

💡 Singleton Pattern 이란? 기업용 온라인 서비스 기술을 지원하기 위해 탄생 객체 인스턴스를 1개만 사용하고 공유하도록 하는 디자인 패턴 private 생성자를 사용해서 외부에서 임의로 new 키워드를 사용 못하게 막아야함 아래 사진은 웹 어플리케이션 특성상 여러 요청이 올때의 DI 컨테이너 동작을 사진으로 표현한 것 저 그림의 문제점은 동일한 요청이 들어오면 객체를 계속 생성하기 때문에 리소스 문제 등, 다양한 방면에서 비효율적이다 Singleton 적용이 안된 순수 DI 컨테이너를 이용한 테스트 아래 사진에 나온것처럼 AppConfig 에게 MemberService를 2번 요청한 결과의 주소값이 서로 다른것을 확인 가능하다 이렇게 객체가 계속 생성되면 메모리에 모든 객체가 다 남기때문에..