2021.07.28 (수) 인증

역할과 구현을 분리해서 순수자바로 설계/개발 하는것을 따라해봄 다음과제는 실제로 정률 할인정책이라던가 를 적용했을때 잘 적용되는지를 보자 2021-07-28_21-22-40

강의명 : 스프링 MVC 1편 수강회차 : 스프링 MVC 섹션 4 마무리

"프레임워크나 공통 기능이 수고로워야 사용하는 개발자 또는 사용자가 편리해진다."

MVC 패턴

MVC패턴으로 컨트롤러의 역할과 뷰의 역할이 명확하게 구분될 수 있다.
그러나 아직도 중복되고 필요하지 않는 코드들이 보인다. ( 포워드 중복, View path 중복, 사용하지 않는 파라미터, 공통처리 등등)
이를 보완하기 위해서 프론트 컨트롤러가 필요하다.

프론트 컨트롤러

지금까지 모든 요청에 대해서 1:1 대응하는 공통처리를 만들었다. 즉 컨트롤러가 많아지면 거기에 맞는 공통부분도 많아진다
프론트 컨트롤러로 인해 모든 컨트롤러로 요청이 되던 것이 프론트 컨트롤러를 통과하면서 하나의 공통처리를 하나의 컨트롤러가 하게 된다.
여기에 viewResolver, adapter까지 더해준다면 스프링의 MVC패턴을 그대로 구현하게 된다.

viewResolver란? : 컨트롤러가 반환한 논리 뷰 이름을 실제 물리 뷰 경로로 변경해준다. 또 그 물리 경로에 있는 view의 객체를 반환한다.

adapter란?: 지금까지는 한 가지 컨트롤러 인터페이스만을 사용했는데, 실제로는 수없이 많은 컨트롤러 인터페이스를 사용할 것이다. 우리는 프론트 컨트롤러를 만들었고 많은 종류의 컨트롤러를 대응시켜야하는데 이때 필요한 것이 컨트롤러에 맞는 adapter이다. 마치 우리가 110v와 220v전기를 쓰기 위해 두 가지 플러그를 사용하는 것처럼

handler adapter란? 지금까지는 컨트롤러를 직접 호출했다. 이제부터 컨트롤러를 handler라고 보고 우린 가지고 있는 handler와 가지고 있는 adapter가 서로 맞는지 조회해야 한다. 즉 컨트롤러들을 찾고, 거기에 맞는 adapter가 있는지 조회한 다음 handlerAdapter는 이 정보를 가지고 실제 컨트롤러를 호출하여 modelView를 반환한다.

MVC 프레임워크 동작 순서

프론트 컨트롤러에 http요청이 들어온다.
프론트 컨트롤러는 순회하며 핸들러(컨트롤러)를 찾는다.
해당 핸들러가 있으면, 거기에 맞는 handlerAdapter를 찾는다.
해당 handlerAdapter가 있다면, 해당하는 handlerAdapter 가지고 실제 핸들러(컨트롤러)를 호출해서 view를 받는다.
이 때 반환된 modelview는 논리 뷰로 이를 물리 뷰로 바꾸어 줄 viewResolver를 호출하여 실제 물리적인 view를 호출한다.
반환된 실제 view를 render시켜서 html 응답으로 보여준다.

최근에 할 일이 많아서 많이 못했네요..

7. 의존관계 자동 주입

[x] 다양한 의존관계 주입 방법
[x] 옵션 처리
[ ] 생성자 주입을 선택해라!
[ ] 롬복과 최신 트랜드
[ ] 조회 빈이 2개 이상 - 문제
[ ] @Autowired 필드 명, @Qualifier, @Primary
[ ] 애노테이션 직접 만들기
[ ] 조회한 빈이 모두 필요할 때, List, Map
[ ] 자동, 수동의 올바른 실무 운영 기준

다양한 의존관계 주입 방법

의존관계 주입은 크게 4가지 방법이 있다.

생성자 주입
수정자 주입(setter 주입)
필드 주입
일반 메서드 주입

생성자 주입

특징

생성자 호출시점에 딱 1번만 호출되는 것이 보장된다.
불변, 필수 의존관계에 사용
중요! 생성자가 딱 1개만 있으면 @Autowired를 생략해도 자동 주입 된다. 물론 스프링 빈에만 해당한다.

수정자 주입(setter 주입)

특징

선택, 변경 가능성이 있는 의존관계에 사용
자바빈 프로퍼티 규약의 수정자 메서드 방식을 사용하는 방법이다
생성자 주입은 생성, 의존관계 주입 단계가 한번에 일어나지만 수정자 주입 방법은 생성 단계와 의존관계 주입 단계가 순서대로 일어난다.
참고: @Autowired 의 기본 동작은 주입할 대상이 없으면 오류가 발생한다. 주입할 대상이 없어도 동작하게 하려면 @Autowired(required = false) 로 지정하면 된다

필드 주입

이름 그대로 필드에 바로 주입하는 방법이다. 특징

코드가 간결해서 많은 개발자들을 유혹하지만 외부에서 변경이 불가능해서 테스트 하기 힘들다는 치명적인 단점이 있다.
DI 프레임워크가 없으면 아무것도 할 수 없다.
사용하지 말자!
- 애플리케이션의 실제 코드와 관계 없는 테스트 코드
- 스프링 설정을 목적으로 하는 @Configuration 같은 곳에서만 특별한 용도로 사용

일반 메서드 주입

일반 메서드를 통해서 주입 받을 수 있다. 특징

한번에 여러 필드를 주입 받을 수 있다.
일반적으로 잘 사용하지 않는다.

옵션 처리

자동 주입 대상을 옵션으로 처리하는 방법은 다음과 같다.

@Autowired(required=false) : 자동 주입할 대상이 없으면 수정자 메서드 자체가 호출 안됨
org.springframework.lang.@Nullable : 자동 주입할 대상이 없으면 null이 입력된다.
Optional<> : 자동 주입할 대상이 없으면 Optional.empty 가 입력된다.

스프링 빈과 의존관계

컴포넌트 스캔과 자동 의존관계 설정

생성자에 @Autowired 가 있으면 스프링이 연관된 객체를 스프링 컨테이너에서 찾아서 넣어준다. 이렇게 객체 의존관계를 외부에서 넣어주는 것을 DI (Dependency Injection), 의존성 주입이라 한다.
이전 테스트에서는 개발자가 직접 주입했고, 여기서는 @Autowired에 의해 스프링이 주입해준다.

오류 발생

Consider defining a bean of type 'hello.hellospring.service.MemberService' in your configuration.

memberService가 스프링 빈으로 등록되어 있지 않다.

참고: helloController는 스프링이 제공하는 컨트롤러여서 스프링 빈으로 자동 등록된다. @Controller 가 있으면 자동으로 등록된다.

스프링 빈을 등록하는 2가지 방법

컴포넌트 스캔과 자동 의존관계 설정
자바 코드로 직접 스프링 빈 등록하기

컴포넌트 스캔 원리

@Component : 애노테이션이 있으면 스프링 빈으로 자동 등록된다.
@Controller : 컨트롤러가 스프링 빈으로 자동 등록된 이유도 컴포넌트 스캔 때문이다.
@Component를 포함하는 다음 애노테이션도 스프링 빈으로 자동 등록된다. @Controller , @Service, @Repository

참고: 생성자에 @Autowired 를 사용하면 객체 생성 시점에 스프링 컨테이너에서 해당 스프링 빈을 찾아서 주입한다. 생성자가 1개만 있으면 @Autowired 는 생략할 수 있다.

memberService와 memberRepository가 스프링 컨테이너에 스프링 빈으로 등록되었다.

참고: 스프링은 스프링 컨테이너에 스프링 빈을 등록할 때, 기본으로 싱글톤으로 등록한다(유일하게 하나만 등록해서 공유한다) 따라서 같은 스프링 빈이면 모두 같은 인스턴스다. 설정으로 싱글톤이 아니게 설정할 수 있지만, 특별한 경우를 제외하면 대부분 싱글톤을 사용한다.

spring-god-study / spring-basic