1. bean scope scope: 범위, bean이 존재할 수 있는 범위 1.1. scope 종류 싱글톤 기본 스코프, 스프링 컨테이너의 시작과 종료까지 유지되는 가장 넓은 범위의 스코프 프로토타입 스프링 컨테이너가 프로토타입 빈의 생성 → 의존관계 주입 → 초기화 메서드 까지 관여 (spring bean 생명 주기) 이후는 관리하지 않는 매우 짧은 범위의 스코프 종료 callback 없음 웹 관련 스코프 request: 웹 요청이 들어오고 나갈때 까지 유지되는 스코프 session: 웹 세션이 생성되고 종료될 때 까지 유지되는 스코프 application: 웹의 서블릿 컨텍스트와 같은 범위로 유지되는 스코프 싱글톤, 프로토타입, request 정도 알면 충분 웬만하면 싱글톤으로 처리를 하는 것을 권..
1. 빈 생명주기 콜백 시작 Spring bean 생성, 종료 직전 @Bean 객체 내부 method를 호출해주는 기능 생성후 초기화시 호출 죽기 직전 안전 종료 메서드 호출 필요한 이유 db connection pool, network socket처럼 app시작 시점에 필요한 연결을 미리 해둘 경우 app 종료 시점에 연결을 모두 종료하는 작업을 진행하기 위해서 객체 내부 종료 작업 필요 1.1. 예제 문제 코드 - 미리 connect()를 하고 싶어서 생성자 내부에 connect() 넣어봤다 - 시도를 한 것. 잘못된 시도 package hello.core.lifecycle; public class NetworkClient { private String url; // 생성자 내부에 connect() ..
1. 의존관계 주입 방법 - 4가지 크게 4가지 존재 생성자 주입 - 권장 수정자 주입(setter 주입) - 정말 필요시 -- 3, 4 번은 사용하지 말 것 -- 필드 주입 일반 메서드 주입 복습 spring container 설정 과정 모든 @Component 찾아서 등록 (의존관계 주입을 바로 수행하지 않는다.) 의존 관계 주입을 수행 (@Component가 다 등록 된 이후에 수행) 하지만 예외적으로 생성자 주입이나 수동 bean 설정 같은 경우에는 java code 특성상 1,2, 단계가 동시에 진행 1.1. 생성자 주입 생성자 호출시점에 딱 1번만 호출되는 것이 보장 불변, 필수 의존관계에 사용 불변 : (외부에서 생성자 값 변경 못하게) 필수(private final를 이용해서 생성자의 pa..
1. 컴포넌트 스캔과 의존관계 자동 주입 컴포넌트 스캔 필요성 등록해야 할 spring bean이 수백개가 되면 일일이 등록하기 힘들고, 설정 정보도 커지고, 누락하는 문제도 발생 bean 등록을 해주는 컴포넌트 스캔과 더불어 의존관계를 주입 해주는 @Autowired도 제공 @Bean 등록 Overiding, 예외 처리 조건 SpringBootApplication 실행 시 : 동일 @Bean 명일 경우 NoUniqueBeanDefinitionException 발생 SpringApplication 실행 시 : 동일 @Bean 명이여도 overriding 해버림 - 위험 단위 Test 실행 시 : 동일 @Bean 명이여도 overriding 해버림 - 위험 Spring Test 실행 시 : 동일 @Bean..
발생 원인 순수 자바 컨테이너로 만들었던 AppConfig를 웹 애플리케이션으로 직접 사용하면 요청할 때마다 설정파일 내의 객체를 새로 생성하고 삭제하는 과정을 거친다. 메모리 낭비가 심하다. @Test @DisplayName("스프링 없는 순수한 DI 컨테이너") void pureContainer(){ AppConfig appConfig = new AppConfig(); MemberService memberService1 = appconfig.memberService(); MemberService memberService2 = appconfig.memberService(); assertThat(memberService1).isNotSameAs(memberService2); } 해결방안 해당 객체를 1개..
0. 흐름 AppConfig 변화 AppConfig의 return type이 구체 클래스여도 작동에는 문제가 없지만 설정파일에서는 역할과 구현이 분리가 되어야 한눈에 파악이 쉽기 때문에 스프링 추상클래스로 나타낸다. @Configuration public class AppConfig{ // service @Bean public MemberService memberService(){ return new MemberServiceImpl(memberRepository()); } @Bean public Orderservice orderService(){ return new OrderServiceImpl(memberRepository(), discoutnPolicy()) } // 객체 @Bean public M..
1. EJB 단점 : 웹 관련 기술과 ORM의 기술을 제공하지만 너무 복잡하고 EJB에 의존적 대안책 : 스프링(웹 관련 기술), 하이버네이트(ORM 기술 == JPA) 스프링 : EJB 없이도 자바로만 가지고 충분히 고품질의 확장 가능한 애플리케이션 개발할 수 있음을 보여줌. EJB 컨테이너 대체 단순함 현재 표준 기술 하이버네이트(JPA) : 하이버네이트 JPA의 새로운 표준 정의 EJB EntityBean 기술 대체 JPA 표준 정의 EJB EntityBean -> 하이버네이트 -> JPA(인터페이스) JPA의 90%는 하이버네이트로 구현 2. Spring 하나가 아닌 여러기능들의 모음 2.1. Spring Framework Spring의 여러 기능들 중 핵심 핵심 기술 : 스프링 DI 컨테이너(b..
흐름 java로만 이용해서 스프링의 container가 작동하는 원리를 보여준다. 이후 실제 SpringContainer의 작동방식을 보여준다. 1. 문제점 DIP, OCP 위반 DIP : 인터페이스에만 의존해야하는데 구현체에도 의존을 했었다. OCP : 기능을 확장하게 되면 clientCode에 영향을 준다. 2. 관심사의 분리 역할과 실제배역은 분리되어야 한다. 역할 = 인터페이스, 실제배역 = 구현체 이를 확실히 구분해주기 위해선 역할에 맞는 구현체를 선정해주는 설정(=기획자)이 필요 예시 연극에서 로미오 역할을 하는 디카프리오가 줄리엣 역할을 하는 여주인공을 직접 선정하는 것과 같다. - 여주인공 선정하는 기획자 필요 memberService의 역할을 하는 memberServiceImpl 가 me..
