Spring(심화)-1주차

스프링 MVC 이해 - Response

스프링 MVC?

• MVC (Model - View - Controller) 디자인 패턴
• Server 에서 HTML 을 내려 주는 경우
  1. 정적 (static) 웹 페이지
  • Controller
    1. Client 의 요청을 Model 로 받아 처리
    2. Client 에게 View (정적 웹 페이지, HTML) 를 내려줌
       
  2. 동적 (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 의 역할 이해

1. HTTP request, response 처리를 위해 매번 작성해 줘야하는 중복코드들 생략 가능
2. 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) {
    		// ... 
    	}
    }    

3. AllInOneController 문제점

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

Controller, Service, Repository 역할 분리

1. Controller

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

2. Service

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

3. 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 를 사용하면 생략 가능

키워드로 상품 검색

• API
  

• 상품 검색 API 작동순서
  

관심상품 등록

• API