2021.07.24 / 2021.07.25 (주말) 인증

[char-yb]

강의명: 스프링 핵심원리 기본 수강날짜: 7.24 수강회차: 빈 생명주기 콜백 시작 ~ 프로토타입 스코프

빈 생명주기 콜백 시작

• 데이터베이스 커넥션 풀이나, 네트워크 소켓처럼 애플리케이션 시작 시점에 필요한 연결을 미리 해두고, 애플리케이션 종료 시점에 연결을 모두 종료하는 작업을 진행하려면, 객체의 초기화와 종료 작업이 필요하다.
• NetworkClient 는 애플리케이션 시작 시점에 connect() 를 호출해서 연결을 맺어두어야 하고, 애플리케이션이 종료되면 disConnect() 를 호출해서 연결을 끊어야 한다
• 객체를 생성한 다음에 외부에서 수정자 주입을 통해서 setUrl() 이 호출되어야 url이 존재하게 된다.

스프링 빈은 간단하게 아래와 같은 라이프사이클이 돈다. 객체 생성 -> 의존관계 주입

• 스프링 빈은 객체를 생성하고, 의존관계 주입이 다 끝난 다음에야 필요한 데이터를 사용할 수 있는 준비가 완료된다.
• 따라서 초기화 작업은 의존관계 주입이 모두 완료되고 난 다음에 호출해야 한다.
• 스프링은 의존관계 주입이 완료되면 스프링 빈에게 콜백 메서드를 통해서 초기화 시점을 알려주는 다양한 기능을 제공한다.
• 또한 스프링은 스프링 컨테이너가 종료되기 직전에 (일반적인 싱글톤 같은 경우)소멸 콜백을 준다.
• 따라서 안전하게 종료 작업을 진행할 수 있다.

스프링 빈의 이벤트 라이프사이클 스프링 컨테이너 생성 -> 스프링 빈 생성 -> 의존관계 주입(수정자, 필드 주입) -> 초기화 콜백(의존관계 끝) -> 사용 -> 소멸전 콜백 -> 스프링 종료

• 초기화 콜백: 빈이 생성되고, 빈의 의존관계 주입이 완료된 후 호출
• 소멸전 콜백: 빈이 소멸되기 직전에 호출

참고: 객체의 생성과 초기화를 분리하자. 단일 책임원칙으로 객체를 생성할 때는 정말 생성에 집중을 해야 한다. 메모리 할당까지 세팅을 완료해야 한다.

• 생성자는 필수 정보(파라미터)를 받고, 메모리를 할당해서 객체를 생성하는 책임을 가진다. 반면에 초기화는 생성된 값들을 활용해서 외부 커넥션을 연결하는 등 무거운 동작을 수행한다.
• 따라서 생성자 안에서 무거운 초기화 작업을 함께 하는 것 보다는 객체를 생성하는 부분과 초기화 하는 부분을 명확하게 나누는 것이 유지보수 관점에서 좋다.
• 물론 초기화 작업이 내부 값들만 약간 변경하는 정도로 단순한 경우에는 생성자에서 한번에 다 처리하는게 더 나을 수 있다.

스프링은 크게 3가지 방법으로 빈 생명주기 콜백을 지원한다.

• 인터페이스(InitializingBean, DisposableBean)
• 설정 정보에 초기화 메서드, 종료 메서드 지정
• @PostConstruct, @PreDestory 애노테이션 지원

인터페이스 InitializingBean, DisposableBean

• InitializingBean 은 afterPropertiesSet() 메서드로 초기화를 지원한다.
• DisposableBean 은 destroy() 메서드로 소멸을 지원한다

초기화, 소멸 인터페이스 단점

• 이 인터페이스는 스프링 전용 인터페이스다. 해당 코드가 스프링 전용 인터페이스에 의존한다.
• 초기화, 소멸 메서드의 이름을 변경할 수 없다.
• 코드를 고칠 수 없는 외부 라이브러리에 적용할 수 없다.

빈 등록 초기화, 소멸 메서드 설정 정보 사용 특징

• 메서드 이름을 자유롭게 줄 수 있다.
• 스프링 빈이 스프링 코드에 의존하지 않는다.

• 코드가 아니라 설정 정보를 사용하기 때문에 코드를 고칠 수 없는 외부 라이브러리에도 초기화, 종료 메서드를 적용할 수 있다.

  종료 메서드 추론

• @Bean의 destroyMethod 속성에는 아주 특별한 기능이 있다.
• 라이브러리는 대부분 close , shutdown 이라는 이름의 종료 메서드를 사용한다.
• @Bean의 destroyMethod 는 기본값이 (inferred) (추론)으로 등록되어 있다.
• 이 추론 기능은 close , shutdown 라는 이름의 메서드를 자동으로 호출해준다. 이름 그대로 종료 메서드를 추론해서 호출해준다.
• 따라서 직접 스프링 빈으로 등록하면 종료 메서드는 따로 적어주지 않아도 잘 동작한다.
• 추론 기능을 사용하기 싫으면 destroyMethod="" 처럼 빈 공백을 지정하면 된다

애노테이션 @PostConstruct, @PreDestory

• 최신 스프링에서 가장 권장하는 방법
• 애노테이션 하나만 붙이면 되므로 사용이 편하다.
• 패키지를 잘 보면 javax.annotation.PostConstruct 이다. 스프링에 종속적인 기술이 아니라 JSR-250 라는 자바 표준이다. 따라서 스프링이 아닌 다른 컨테이너에서도 동작한다.
• 컴포넌트 스캔과 잘 어울린다.(왜냐면 빈을 등록하는 것이 아니기 때문에 @Component라고 해서 컴포넌트 스캔의 대상이 어차피 애노테이션을 넣어야 하니까 잘 된다.) 단점: 외부 라이브러리에는 적용하지 못한다는 것이다. 외부 라이브러리를 초기화, 종료 해야 하면 @Bean의 기능을 사용하자.

정리

• @PostConstruct, @PreDestory 애노테이션을 사용하자
• 코드를 고칠 수 없는 외부 라이브러리를 초기화, 종료해야 하면 @Bean의 initMethod , destroyMethod를 사용하자.

빈 스코프 빈 스코프란? 스프링 빈이 스프링 컨테이너의 시작과 함께 생성되어서 스프링 컨테이너가 종료될 때 까지 유지된다고 학습했다. 이것은 스프링 빈이 기본적으로 싱글톤 스코프로 생성되기 때문이다. 스코프는 번역 그대로 빈이 존재할 수 있는 범위를 뜻한다.

스프링은 다음과 같은 다양한 스코프를 지원

• 싱글톤: 기본 스코프, 스프링 컨테이너의 시작과 종료까지 유지되는 가장 넓은 범위의 스코프이다.
• 프로토타입: 스프링 컨테이너는 프로토타입 빈의 생성과 의존관계 주입까지만 관여하고 더는 관리하지 않는 매우 짧은 범위의 스코프이다. (요청을 하면 의존관계 주입하고, 초기화까지 해주고 끝!, 종료 메서드 호출x)
• 웹 관련 스코프
  • request: 웹 요청이 들어오고 나갈때 까지 유지되는 스코프이다.
  • session: 웹 세션이 생성되고 종료될 때 까지 유지되는 스코프이다.(로그인에서 주로 사용)
  • application: 웹의 서블릿 컨텍스와 같은 범위로 유지되는 스코프이다.

프로토타입 스코프

• 싱글톤 스코프의 빈을 조회하면 스프링 컨테이너는 항상 같은 인스턴스의 스프링 빈을 반환한다.
• 반면에 프로토타입 스코프를 스프링 컨테이너에 조회하면 스프링 컨테이너는 항상 새로운 인스턴스를 생성해서 반환한다.

1. 싱글톤 스코프의 빈을 스프링 컨테이너에 요청한다.
2. 스프링 컨테이너는 본인이 관리하는 스프링 빈을 반환한다.
3. 이후에 스프링 컨테이너에 같은 요청이 와도 같은 객체 인스턴스의 스프링 빈을 반환한다

프로토타입 빈 요청1

1. 프로토타입 스코프의 빈을 스프링 컨테이너에 요청한다.
2. 스프링 컨테이너는 이 시점에 프로토타입 빈을 생성하고, 필요한 의존관계를 주입한다. 프로토타입 빈 요청2
3. 스프링 컨테이너는 생성한 프로토타입 빈을 클라이언트에 반환한다.
4. 이후에 스프링 컨테이너에 같은 요청이 오면 항상 새로운 프로토타입 빈을 생성해서 반환한다.

정리

• 핵심은 스프링 컨테이너는 프로토타입 빈을 생성하고, 의존관계 주입, 초기화까지만 처리한다는 것이다.

• 클라이언트에 빈을 반환하고, 이후 스프링 컨테이너는 생성된 프로토타입 빈을 관리하지 않는다.

• 프로토타입 빈을 관리할 책임은 프로토타입 빈을 받은 클라이언트에 있다.

• 그래서 @PreDestory 같은 종료 메서드가 호출되지 않는다.

• 싱글톤 빈은 스프링 컨테이너 생성 시점에 초기화 메서드가 실행 되지만, 프로토타입 스코프의 빈은 스프링 컨테이너에서 빈을 조회할 때 생성되고, 초기화 메서드도 실행된다.

• 프로토타입 빈을 2번 조회했으므로 완전히 다른 스프링 빈이 생성되고, 초기화도 2번 실행된 것을 확인할 수 있다.

• 싱글톤 빈은 스프링 컨테이너가 관리하기 때문에 스프링 컨테이너가 종료될 때 빈의 종료 메서드가 실행되지만, 프로토타입 빈은 스프링 컨테이너가 생성과 의존관계 주입 그리고 초기화 까지만 관여하고, 더는 관리하지 않는다.

• 따라서 프로토타입 빈은 스프링 컨테이너가 종료될 때 @PreDestory 같은 종료 메서드가 전혀 실행되지 않는다.

만약에 호출해줄려면 적절하게 다 작성하고 destroy() 를 직접 호출을 해주고 close()해주어야 한다.

프로토타입 빈의 특징 정리

• 스프링 컨테이너에 요청할 때 마다 새로 생성된다.
• 스프링 컨테이너는 프로토타입 빈의 생성과 의존관계 주입 그리고 초기화까지만 관여한다.
• 종료 메서드가 호출되지 않는다.
• 그래서 프로토타입 빈은 프로토타입 빈을 조회한 클라이언트가 관리해야 한다. 종료 메서드에 대한 호출도 클라이언트가 직접 해야한다.

[kyupid]

스프링 핵심 원리 - 기본편 객체지향 설계와 스프링 예제만들기 초입부분 순수한 자바로만 서비스를 만든다는 건 무슨느낌일까 기대된다

[char-yb]

강의명: 스프링 핵심원리 기본편 수강회차: 프로토타입 스코프 - 싱글톤 빈과 함께 사용 시 문제점 ~ 프로토타입 스코프 - 싱글톤 빈과 함께 사용시 Provider로 문제 해결

프로토타입 스코프 - 싱글톤 빈과 함께 사용 시 문제점

스프링 컨테이너에 프로토타입 빈 직접 요청 스프링 컨테이너에 프토토타입 스코프의 빈을 요청하면 항상 새로운 객체 인스턴스를 생성해서 반환한다. 일단 듣자마자 이해는 잘 안됐다.

1. 클라이언트A는 스프링 컨테이너에 프로토타입 빈을 요청한다.
2. 스프링 컨테이너는 프로토타입 빈을 새로 생성해서 반환(x01)한다. 해당 빈의 count 필드 값은 0이다.
3. 클라이언트는 조회한 프로토타입 빈에 addCount() 함수를 호출하면서 count 필드를 +1 한다. 결과적으로 프로토타입 빈(x01)의 count는 1이 된다.

스프링 컨테이너에 프로토타입 빈 직접 요청2

1. 클라이언트B는 스프링 컨테이너에 프로토타입 빈을 요청한다.
2. 스프링 컨테이너는 프로토타입 빈을 새로 생성해서 반환(x02)한다. 해당 빈의 count 필드 값은 0이다.
3. 클라이언트는 조회한 프로토타입 빈에 addCount() 를 호출하면서 count 필드를 +1 한다. 결과적으로 프로토타입 빈(x02)의 count는 1이 된다.

싱클톤에서 프로토타입 빈 사용1 clientBean 은 싱글톤이므로, 보통 스프링 컨테이너 생성 시점에 함께 생성되고, 의존관계 주입도 발생한다.

1. clientBean 은 의존관계 자동 주입을 사용한다. 주입 시점에 스프링 컨테이너에 프로토타입 빈을 요청한다.
2. 스프링 컨테이너는 프로토타입 빈을 생성해서 clientBean 에 반환한다. 프로토타입 빈의 count 필드값은 0이다. 이제 clientBean 은 프로토타입 빈을 내부 필드에 보관한다. (정확히는 참조값을 보관한다.)

싱글톤에서 프로토타입 빈 사용2 클라이언트 A는 clientBean 을 스프링 컨테이너에 요청해서 받는다.싱글톤이므로 항상 같은 clientBean 이 반환된다.

3. 클라이언트 A는 clientBean.logic() 을 호출한다.
4. clientBean 은 prototypeBean의 addCount() 를 호출해서 프로토타입 빈의 count를 증가한다. count값이 1이 된다

싱글톤에서 프로토타입 빈 사용3 (가장 어렵다...) 클라이언트 B는 clientBean 을 스프링 컨테이너에 요청해서 받는다.싱글톤이므로 항상 같은 clientBean 이 반환된다. 여기서 중요한 점이 있는데, clientBean이 내부에 가지고 있는 프로토타입 빈은 이미 과거에 주입이 끝난 빈이다. 주입 시점에 스프링 컨테이너에 요청해서 프로토타입 빈이 새로 생성이 된 것이지, 사용 할 때마다 새로 생성되는 것이 아니다!

5. 클라이언트 B는 clientBean.logic() 을 호출한다.
6. clientBean 은 prototypeBean의 addCount() 를 호출해서 프로토타입 빈의 count를 증가한다. 원래 count 값이 1이었으므로 2가 된다.

무식하게 logic() 안에 applicationContext로 주입을 받아 사용하면 값은 2가 아닌 1이 된다.

여러 빈에서 같은 프로토타입 빈을 주입 받으면, 주입 받는 시점에 각각 새로운 프로토타입 빈이 생성된다. 예를 들어서 clientA, clientB가 각각 의존관계 주입을 받으면 각각 다른 인스턴스의 프로토타입 빈을 주입 받는다.

clientA prototypeBean@x01 clientB prototypeBean@x02 결국 프로토타입 빈을 사용하는 것은 사용할때 마다 새로 생성해서 사용할려고 하는 것이다. 이와 같은 문제를 아래 강의 회차에서 다룬다.

프로토타입 스코프 - 싱글톤 빈과 함께 사용시 Provider로 문제 해결

• 의존관계를 외부에서 주입(DI) 받는게 아니라 이렇게 직접 필요한 의존관계를 찾는 것을 Dependency Lookup (DL) 의존관계 조회(탐색) 이라한다.
• 그런데 이렇게 스프링의 애플리케이션 컨텍스트 전체를 주입받게 되면, 스프링 컨테이너에 종속적인 코드가 되고, 단위 테스트도 어려워진다.
• 지금 필요한 기능은 지정한 프로토타입 빈을 컨테이너에서 대신 찾아주는 딱! DL 정도의 기능만 제공하는 무언가가 있으면 된다. ApplicationContext는 별의별 기능을 다 제공한다. 그러나 이 고민을 해결해주기 위해 스프링에서 준비가 다 되어있다.

ObjectFactory, ObjectProvider 지정한 빈을 컨테이너에서 대신 찾아주는 DL 서비스를 제공하는 것이 바로 ObjectProvider 이다. ObjectFactory가 있지만 getObject 기능만 제공되어 따로 실습할 필요는 없다.

• 실행해보면 prototypeBeanProvider.getObject() 을 통해서 항상 새로운 프로토타입 빈이 생성되는 것을 확인할 수 있다.
• ObjectProvider 의 getObject() 를 호출하면 내부에서는 스프링 컨테이너를 통해 해당 빈을 찾아서 반환한다. (DL)
• 스프링이 제공하는 기능을 사용하지만, 기능이 단순하므로 단위테스트를 만들거나 mock 코드를 만들기는훨씬 쉬워진다.
• ObjectProvider 는 지금 딱 필요한 DL 정도의 기능만 제공한다. 특징
• ObjectFactory: 기능이 단순, 별도의 라이브러리 필요 없음, 스프링에 의존
• ObjectProvider: ObjectFactory 상속, 옵션, 스트림 처리등 편의 기능이 많고, 별도의 라이브러리 필요없음, 스프링에 의존

JSR-330 Provider: 자바 표준 (스프링에 의존하지 않는 기능)

• javax.inject.Provider 라는 JSR-330 자바 표준을 사용하는 방법으로 javax.inject:javax.inject:1 라이브러리를 gradle에 추가해야 한다.
• 실행해보면 provider.get() 을 통해서 항상 새로운 프로토타입 빈이 생성되는 것을 확인할 수 있다.
• provider 의 get() 을 호출하면 내부에서는 스프링 컨테이너를 통해 해당 빈을 찾아서 반환한다. (DL)
• 자바 표준이고, 기능이 단순하므로 단위테스트를 만들거나 mock 코드를 만들기는 훨씬 쉬워진다.
• Provider 는 지금 딱 필요한 DL 정도의 기능만 제공한다.

특징

• get() 메서드 하나로 기능이 매우 단순하다.
• 별도의 라이브러리가 필요하다.
• 자바 표준이므로 스프링이 아닌 다른 컨테이너에서도 사용할 수 있다.

정리

• 그러면 프로토타입 빈을 언제 사용할까? 매번 사용할 때 마다 의존관계 주입이 완료된 새로운 객체가 필요하면 사용하면 된다. 그런데 실무에서 웹 애플리케이션을 개발해보면, 싱글톤 빈으로 대부분의 문제를 해결할 수 있기 때문에 프로토타입 빈을 직접적으로 사용하는 일은 매우 드물다.
• ObjectProvider , JSR330 Provider 등은 프로토타입 뿐만 아니라 DL이 필요한 경우는 언제든지 사용할 수 있다.

[dnjsrud3407]

강의명 : 스프링 핵심 원리 수강회차 <의존관계 자동 주입>

• 조회 빈이 2개 이상 - 문제
• @Autowired 필드 명, @Qualifier, @Primary
• 애노테이션 직접 만들기
• 조회한 비이 모두 필요할 때, List, Map
• 자동, 수동의 올바른 실무 운영 기준

<빈 생명주기 콜백>

• 빈 생명주기 콜백 시작
• 인터페이스 InitializingBean, DisposableBean
• 빈 등록 초기화, 소명 메서드
• 애노테이션 @PostConstruct, @PreDestory

요약

• 동적으로 빈을 선택하여 서비스를 수행하고 싶을 때 빈을 모두 스프링 컨테이너에 저장하고 따로 Map 형태로도 저장하여 동적으로 선택해서 사용하면 된다

• 자동으로 빈을 등록하는 경우 : 대체로 자동으로 빈을 등록하는 것을 우선으로 한다

• 수동으로 빈을 등록하는 경우는 애플리케이션의 기술 지원 빈 즉 기술적인 문제나 공통 관심사를 처리할 때 주로 사용된다

• 또한 다형성을 활용하는 비즈니스 로직은 수동 빈을 사용하는 경우 한 눈에 알아볼 수 있어서 유지보수에 좋다

• 스프링 빈의 이벤트 라이프사이클은 아래와 같다 스프링 컨테이너 생성 -> 의존관계 주입 -> 초기화 콜백 -> 사용 -> 소멸전 콜백 -> 스프링 종료

• 스프링 컨테이너를 생성하고 의존관계를 주입한 후 초기화 메서드를 사용하고 싶을때, 객체 빈이 소멸 직전에 부를 메서드를 사용하고 싶을 때 스프링에서 지원하는 콜백이 있다

• 인터페이스 형식은 이제 사용하지 않고 주로 @PostConstruct, @PreDestory 를 메서드 위에 선언하여 사용하는 편이다

• 단 외부라이브러리를 사용할 경우에는 @Bean(initMethod='') 형식을 사용한다

[dowon-ahn]

HTTP 완벽가이드 란 책을 읽으며, 메모하는 글 입니다.

• 전 세계의 웹브라우저, 서버, 웹 애플리케이션은 모두 HTTP(Hypertext Transfer procol)를 통해 대화한다.

• HTTP는 신뢰성있는 데이터 전송 프로토콜을 사용하기 때문에, 데이터가 지구 반대편에서 오더라도 전송 중 손상되거나 꼬이지 않음을

  보장한다.

1.2 웹 클라이언트 서버

• 웹 콘텐츠는 웹서버에 존재하고, 웹 서버는 HTTP 프로토콜로 의사소통하기 때문에 보통 HTTP 서버라고 불린다.

• 클라이언트는 서버에게 HTTP 요청을 보내고 서버는 요청된 데이터를 HTTP 응답으로 돌려준다.

1.3 리소스

• 웹 서버는 웹 리소스르 관리하고 제공한다.

• 리소스는 웹 콘텐츠의 원천이며, HTML을 포함하여 모든 구분할 수 있는 데이터를 의미한다.

  (반드시 정적 파일일 필요는 없으며, 요청에 따라 콘텐츠를 생산하는 프로그램이 될 수도 있다.)

1.3.1 미디어 타입

• 인터넷은 수천가지의 데이터 타입을 다루기 때문에, HTTP는 웹에서 전송되는 객체 각각에 MIME 타입이라는 데이터 포맷 라벨을 붙인다. (Multipurpose Internet Mail Extensions)

• MIME 타입은 사선(/)으로 구분된 주 타입과 부 타입으로 이루어진 문자열 라벨이다.

e.g. HTML => text/html 라벨이 붙는다.

JPEG 이미지는 image/jpeg가 붙는다.

GIF 이미지는 image/gif가 된다.

1.3.2 URI

• URI는 인터넷의 우편물 주소같은 것으로, 정보 리소스를 고유하게 식별하고 위치를 지정할 수 있다. ( URL + URN)

1.3.3 URL

• URIL은 특정 서버의 한 리소스에 대해 구체적인 위치를 서술한다.

• 오늘날의 대부분의 URI는 URL이다.

1.3.4 URN

• 유니폼 리소스의 이름으로, URN은 콘텐츠를 이루는 한 리소스에 대해 그 리소스의 영향을 받지 않는 유일무이한 이름 역할을 한다.

• 아직널리 채택되지 않음.

1.4 트랜잭션

• HTTP 트랜잭션은 요청과 응답 메세지로 구성되어 있다.

1.4.1 메서드

• HTTP는 HTTP 메서드라고 불리는 여러가지 종류의 요청 명령을 지원한다. 모든 HTTP 요청 메세지는 한 개의 메서드를 갖는다.

• 널리 쓰이는 메서드로는 GET / PUT / DELETE / POST / HEAD 가 있다.

1.4.2 상태코드

• 1XX : 요청이 수신되어 처리중

• 2XX : 요청 정상 처리

• 3XX : 요청을 완료하려면 추가 행동이 필요

• 4XX : 클라이언트 오류

• 5XX : 서버오류, 서버가 정상 요청을 처리하지 못함

1.4.3 웹페이지는 여러 객체로 이루어질 수 있다.

• 웹 페이지를 구성하기 위해, 여러 서버에 데이터를 요청할 수 있다. (웹 페이지는 보통 하나의 리소스가 아닌 리소스의 모음이다.)

• 웹 페이지는 첨부된 리소스들에 대해 각자 별개의 HTTP 트랜잭션을 필요로한다. ( = 리소스 별로 HTTP 트랜잭션이 발생)

1.5 메세지

• 시작줄 / 헤더 / 본문으로 구성

1.6 TCP 커넥션

• 인터넷 자체가 대중적으로 TCP / IP에 기초하고 있다.

• TCP / IP는 패킷 교환 네트워크 프로토콜의 집합이다.

• TCP / IP는 각 네트워크와 하드웨어의 특성을 숨시고, 어떤 종류의 컴퓨터나 네트워크든 서로 신뢰성 있는 의사소통을 하게 해 준다.

• TCP의 특징 ( 오류없는 데이터 전송 / 순서에 맞는 전달(보낸순서대로 도착) / 조각나지 않는 데이터 스트림(언제 어떤 크기로든 전송O))

1.6.2 접속 / IP / 주소 그리고 포트번호

• HTTP 클라이언트가 서버에 메세지를 전송할 수 있게 되기 전에, 인터넷 프로토콜 주소와 포트번호를 사용해 클라이언트와 서버사이에 TCP / IP 커넥션을 맺어야 한다.

• HTTP URL에 포트번호가 없는 경우 기본값 80을 가정한다.

[sablemarten]

스프링 빈 조회

빈 조회라고 해서 잘 안 와닿았는데 복붙으로만 사용했던 부분에 대한 설명이었다. 자바와 스프링을 동시에 배웠을 때 왜 이것과 저것이 매칭되어서 작동하는 것인지 모르고 썼었는데, 실무에서 쓸 때 생각하면서 써보도록 할 수 있을 것 같다.

[arangeblue]

강의명 : 스프링 MVC 1편 수강회차 : 스프링 MVC 섹션 0~1 / 웹 어플리케이션의 이해

내용

• 웹서버 : 정적파일 서빙, 다른 client마다 다른 화면을 제공하기 어려움
• 웹 어플리케이션 서버 : 웹 서버에서 프로그래밍 코드를 통해 동적으로 작동하는 서버, client마다 다른 화면을 제공할 수 있고, 동적으로 움직이는 화면을 서빙

웹 시스템 구성

• 1. WAS, DB : 가장 간단한 형태의 웹 시스템

• WAS는 정적리소스, 어플리케이션 로직 모두 제공, WAS가 너무 많은 역할을 담당, 서버 과부하 우려

• 가장 비싼 어플리케이션 로직이 정적 리소스 때문에 수행이 어려울 수 있음

• WAS 장애시 오류 화면도 노출 불가능

• 2. WEB, WAS, DB

• 정적 리소스는 웹서버가 처리

• 웹서버는 어플리케이션 로직 같은 동적인 처리가 필요하면 WAS에 요청을 위임

• WAS는 중요한 어플리케이션 로직 처리 전담

• 또한 효율적인 리소스 관리, 정적리소스가 많아지면 웹 서버 증설, 어플리케이션 리소스가 많이 사용되면 WAS 증설

• WEB 서버는 잘 죽지 않아서 1번처럼 WAS 장애가 떴을 때 WEB으로도 처리 가능

---

서블릿 : 비즈니스 로직 실행이라는 가장 중요한 로직을 제외한 거의 모든 HTTP처리 업무를 지원

• 1. HTTP요청시 Servlet
• WAS는 Request, Response 객체를 새로 만들어서 서블릿 객체 호출
• 개발자는 Request객체에서 HTTP 요청 정보를 편리하게 꺼내서 사용
• 개발자는 Response객체에서 HTTP 응답 정보를 편리하게 입력
• WAS는 Response 객체에 담겨있는 내용으로 HTTP 응답 정보를 생성

---

서블릿 컨테이너 : WAS안에는 서블릿 컨테이너가 있는데 이는 객체 생성, 호출, 관리까지 해준다.

• 톰캣처럼 서블릿을 지원하는 WAS를 서블릿 컨테이너라고 함
• 서블릿 컨테이너는 서블릿 객체를 생성, 초기화, 호출, 종료하는 생명주기 관리
• 서블릿 객체는 싱글톤으로 관리
• 1. 고객의 요청이 올 때마다 계속 객체를 생성하는 것은 비효율
• 2. 최초 로딩 시점에 서블릿 객체를 미리 만들어두고 재활용
• 3. 모든 고객 요청은 동일한 서블릿 객체 인스턴스에 접근
• 4. 공유 변수 사용 주의
• 5. 서블릿 컨테이너 종료시 함께 종료
• JSP도 서블릿으로 변환 되어서 사용
• 동시 요청을 위한 멀티 쓰레드 처리 지원

[cxz5309]

스프링 핵심 원리 - 기본편

5. 싱글톤 컨테이너

• [x] 웹 애플리케이션과 싱글톤
• [x] 싱글톤 패턴
• [x] 싱글톤 컨테이너
• [x] 싱글톤 방식의 주의점
• [x] @Configuration과 싱글톤
• [x] @Configuration과 바이트코드 조작의 마법

싱글톤 패턴

• 클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴

1. static영역에 객체 instance를 미리 하나 생성해서 올려둔다.
2. 이 객체 인스턴스가 필요하면 오직 getInstance()메서드를 통해서만 조회할 수 있다.
3. 생성자를 private로 막아서 혹시라도 외부에서 new 키워드로 생성되는 것을 막는다.

• 문제점
  • 싱글톤 패턴을 구현하는 코드 자체가 많이 들어간다.
  • 의존관계상 클라이언트가 구체 클래스에 의존한다. DIP를 위반한다.
  • 클라이언트가 구체 클래스에 의존해서 OCP 원칙을 위반할 가능성이 높다.
  • 테스트하기 어렵다.
  • 내부 속성을 변경하거나 초기화 하기 어렵다.
  • private 생성자로 자식 클래스를 만들기 어렵다.
  • 결론적으로 유연성이 떨어진다.
  • 안티패턴으로 불리기도 한다

싱글톤 컨테이너

• 스프링 컨테이너는 싱글턴 패턴을 적용하지 않아도, 객체 인스턴스를 싱글톤으로 관리한다.
• 스프링 컨테이너는 싱글톤 컨테이너 역할을 한다. 이렇게 싱글톤 객체를 생성하고 관리하는 기능을 싱글톤 레지스트리라 한다.
• 스프링 컨테이너의 이런 기능 덕분에 싱글턴 패턴의 모든 단점을 해결하면서 객체를 싱글톤으로 유지할 수 있다.
• 싱글톤 패턴을 위한 지저분한 코드가 들어가지 않아도 된다.
• DIP, OCP, 테스트, private 생성자로 부터 자유롭게 싱글톤을 사용할 수 있다.

싱글톤 방식의 주의점

• 싱글톤 패턴이든, 스프링 같은 싱글톤 컨테이너를 사용하든, 객체 인스턴스를 하나만 생성해서 공유하는 싱글톤 방식은 여러 클라이언트가 하나의 같은 객체 인스턴스를 공유하기 때문에 싱글톤 객체는 상태를 유지(stateful)하게 설계하면 안된다.
• -> 무상태(stateless)로 설계해야 한다
  • 특정 클라이언트에 의존적인 필드가 있으면 안된다.
  • 특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안된다!
  • 가급적 읽기만 가능해야 한다.
  • 필드 대신에 자바에서 공유되지 않는, 지역변수, 파라미터, ThreadLocal 등을 사용해야 한다

@Configuration과 싱글톤

• 스프링 컨테이너는 싱글톤 레지스트리다. 따라서 스프링 빈이 싱글톤이 되도록 보장해주어야 한다.
• 스프링이 자바 코드까지 어떻게 하기는 어렵다.
• 그래서 스프링은 클래스의 바이트코드를 조작하는 라이브러리를 사용한다

bean = class hello.core.AppConfig$$EnhancerBySpringCGLIB$$bd479d70

• 스프링이 CGLIB라는 바이트코드 조작 라이브러리를 사용해서 AppConfig 클래스를 상속받은 임의의 다른 클래스를 만들고, 그 다른 클래스를 스프링 빈으로 등록한 것이다

@Configuration 을 적용하지 않고, @Bean 만 적용하면 어떻게 될까?

• @Configuration 을 붙이면 바이트코드를 조작하는 CGLIB 기술을 사용해서 싱글톤을 보장하지만, 만약 @Bean만 적용하면 어떻게 될까?

bean = class hello.core.AppConfig

• 이 출력 결과를 통해서 AppConfig가 CGLIB 기술 없이 순수한 AppConfig로 스프링 빈에 등록된 것을 확인할 수 있다
• 당연히 인스턴스가 같은지 테스트 하는 코드도 실패하고, 각각 다 다른 MemoryMemberRepository 인 스턴스를 가지고 있다

정리

• @Bean만 사용해도 스프링 빈으로 등록되지만, 싱글톤을 보장하지 않는다.
• memberRepository() 처럼 의존관계 주입이 필요해서 메서드를 직접 호출할 때 싱글톤을 보장하지 않는다.
• 크게 고민할 것이 없다. 스프링 설정 정보는 항상 @Configuration 을 사용하자

[juvelop17]

회원 리포지토리 테스트 케이스 작성

개발한 기능을 실행해서 테스트 할 때 자바의 main 메서드를 통해서 실행하거나, 웹 애플리케이션의 컨트롤러를 통해서 해당 기능을 실행한다. 이러한 방법은 준비하고 실행하는데 오래 걸리고, 반복 실행하기 어렵고 여러 테스트를 한번에 실행하기 어렵다는 단점이 있다. 자바는 JUnit이라는 프레임워크로 테스트를 실행해서 이러한 문제를 해결한다.

회원 리포지토리 메모리 구현체 테스트

• test에서 test class 파일 생성 후 클래스 내부에서 test할 클래스 생성
• @Test : 테스트할 메소드를 지정하는 어노테이션
• 클래스 내부의 변수 확인

  Assertions.assertEquals(expected, actual);

  Assertions.assertThat(actual).isEqualTo(expected);

CMD + P : 사용 가능한 파라미터 타입 확인

• @AfterEach : 각 메소드가 끝날 때마다 실행되는 메소드를 지정하는 어노테이션