Spring(심화)-1주차

스프링 MVC 이해 - Response

스프링 MVC?

MVC (Model - View - Controller) 디자인 패턴
Server 에서 HTML 을 내려 주는 경우
1. 정적 (static) 웹 페이지
- Controller
  1. Client 의 요청을 Model 로 받아 처리
  2. Client 에게 View (정적 웹 페이지, HTML) 를 내려줌
1. 동적 (dynamic) 웹 페이지
- Controller
  1. Client 의 요청을 Model 로 받아 처리
  2. Template engine 에게 View, Model 전달
    1) View: 동적 HTML 파일
    2) Model: View 에 적용할 정보들
  3. Template engine
    1) View 에 Model 을 적용 → 동적 웹페이지 생성
    예) 로그인 성공 시, "로그인된 사용자의 id" 를 페이지에 추가
    2) Template engine 종류: 타임리프 (Thymeleaf), Groovy, FreeMarker, Jade 등 (스프링에서 JSP 이용은 추천하지 않고 있음)
  4. Client 에게 View (동적 웹 페이지, HTML) 를 내려줌
Controller 와 HTTP Response 메시지
Controller 와 HTTP Request 메시지

스프링 MVC 동작원리

1. Client → DispatcherServlet
- 가장 앞 단에서 요청을 받아 FrontController 라고도 불림
2. DispatcherServlet → Controller
- API 를 처리해 줄 Controller 를 찾아 요청을 전달
- Handler mapping 에는 API path 와 Controller 함수가 매칭되어 있음
- 함수 이름을 내 마음대로 설정 가능했던 이유!!
- Controller 에서 요청하는 Request 의 정보 ('Model') 전달
3. Controller → DispathcerServlet
- Controller 가 Client 으로 받은 API 요청을 처리
- 'Model' 정보와 'View' 정보를 DispatcherServlet 으로 전달
4. DispatcherServlet → Client
- ViewResolver 통해 View 에 Model 을 적용
- View 를 Client 에게 응답으로 전달

Annotation

@RequestMapping("/hello/response"): 클래스 위에 선언해서 공통 url로 씀
@GetMapping("/html/redirect")
=> /hello/response/html/redirect
@RestController = @Controller + @ResponseBody

Controller 의 역할 이해

HTTP request, response 처리를 위해 매번 작성해 줘야하는 중복코드들 생략 가능
API 이름마다 파일을 만들 필요 없음
- API 마다 파일을 만들 필요 없음
- 보통 하나의 Contoller 에 모든 API 를 넣지는 않음
- 유사한 성격의 API 를 하나의 Controller 로 관리
- 함수 이름도 내 마음대로 설정 가능(단, 클래스 내의 중복함수명 불가)

@Controller
    public class UserController {
    	@GetMapping("/user/login")
    	public String login() {
    	    // ...
    	}

      @GetMapping("/user/logout")
      public String logout() {
          // ...
      }

    	@GetMapping("/user/signup")
    	public String signup() { 
    		// ... 
    	}

    	@PostMapping("/user/signup")
      public String registerUser(SignupRequestDto requestDto) {
    		// ... 
    	}
    }

AllInOneController 문제점

한 개의 클래스에 너무 많은 양의 코드가 존재
1. 코드 이해가 어려움: 처음부터 끝까지 다 읽어야 코드 내용을 이해할 수 있음
현업에서는 코드 추가 혹은 변경 요청이 계속 생김
1. 신규 상품 등록 시 Client 에게 응답 (Response) 하는 값 변경
2. 최저가 (Myprice) 업데이트 조건 변경
3. DB 테이블 이름 변경

Controller, Service, Repository 역할 분리

Controller

클라이언트의 요청을 받음
요청에 대한 처리는 서비스에게 전담
클라이언트에게 응답

Service

사용자의 요구사항을 처리 ('비즈니스 로직') 하는 실세 중에 실세!!!
현업에서는 서비스 코드가 계속 비대해짐
DB 정보가 필요할 때는 Repository 에게 요청

Repository

DB 관리 (연결, 해제, 자원 관리)
DB CRUD 작업 처리

DI (의존성 주입) 의 이해

강한 결합 -> 느슨한 결합
- 각 객체에 대한 객체 생성은 딱 1번만!!
- 생성된 객체를 모든 곳에서 재사용!!!
IoC (제어의 역전)
- 용도에 맞게 필요한 객체를 그냥 가져다 사용
- 사용할 객체가 어떻게 만들어졌는지는 알 필요 없음
- "DI (Dependency Injection)" 혹은 한국말로 "의존성 주입"

스프링 IoC 컨테이너

스프링 프레임워크가 필요한 객체를 생성하여 관리하는 역할을 대신함
빈 (Bean): 스프링이 관리하는 객체
스프링 IoC 컨테이너: '빈'을 모아둔 통
@Component
- 클래스 선언 위에 설정
- 스프링 서버가 뜰 때 스프링 IoC 에 '빈' 저장
- 스프링 '빈' 이름: 클래스의 앞글자만 소문자로 변경
- @Component 적용 조건
  - @ComponentScan 에 설정해 준 packages 위치와 하위 package@SpringBootApplication 에 의해 default 설정들
  - @SpringBootApplication 에 의해 default 설정
스프링 '빈' 사용 방법: @Autowired
- 멤버변수 선언 위에 @Autowired → 스프링에 의해 DI (의존성 주입) 됨
- '빈' 을 사용할 함수 위에 @Autowired → 스프링에 의해 DI 됨
- @Autowired 적용 조건: 스프링 IoC 컨테이너에 의해 관리되는 클래스에서만 가능
- @Autowired 생략 조건: 생성자 선언이 1개 일 때만 생략 가능
  => Lombok 의 @RequiredArgsConstructor 를 사용하면 생략 가능