🌈 [Section3] 1. [ Spring MVC ] API 계층 1

📕 오늘 배운 내용!

• Spring MVC
• Spring MVC 요청 처리 흐름
• Spring MVC를 이용한 실습

---

✏️ Spring MVC

• 서블릿(Servlet) API를 기반으로 클라이언트의 요청을 편리하게 처리해주는 프레임워크
• Spring Web MVC 를 줄여서 Spring MVC
  ( Spring MVC 프레임워크 라고도 부름 )

✔️ 서블릿(Servlet)
➜ 클라이언트의 요청을 처리하도록 특정 규약에 맞추어서 Java 코드로 작성하는 클래스 파일
⠀
( 아파치 톰캣(Apache Tomcat) - 서블릿들이 웹 애플리케이션으로 실행이 되도록 해주는 서블릿 컨테이너(Servlet Container) 중 하나 )

 

✔ M = Model

➜ 클라이언트에게 응답으로 돌려줄 작업의 처리 결과 데이터

• 서비스 계층 (Service Layer)
  ➜ 클라이언트의 요청 사항을 구체적으로 처리하는 영역
  
  
• 비즈니스 로직 (Business Logic)
  ➜ 실제로 요청 사항을 처리하기 위해 Java 코드로 구현한 것

 

✔ V = View

➜ Model 데이터를 이용해서 웹브라우저 같은 클라이언트 애플리케이션의 화면에 보여지는 리소스(Resource)를 제공하는 역할

✔️ View의 형태

1. HTML 페이지의 출력
➜ HTML 페이지를 직접 렌더링해서 클라이언트 측에 전송하는 방식
( SSR이라고 생각하면 될 것 같음 )
➜ HTML 태그로 구성된 페이지에 Model 데이터를 채워 넣은 후, 최종적인 HTML 페이지를 만들어서 클라이언트 측에 전송해줌
( But, 이는 프론트엔드, 백엔드가 통합된 구조 )
⠀
2.PDF, Excel 등의 문서 형태로 출력
➜ Model 데이터를 가공해서 PDF 문서나 Excel 문서를 만들어서 클라이언트 측에 전송하는 방식
➜ 문서 내에서 데이터가 동적으로 변경되어야 하는 경우 사용할 수 있는 방식
⠀
3. XML, JSON 등 특정 형식의 포맷으로의 변환
➜ Model 데이터를 특정 프로토콜 형태로 변환해서 변환된 데이터를 클라이언트 측에 전송하는 방식
➜ 특정 형식의 데이터만 전송하고, 프런트엔드 측에서 이 데이터를 기반으로 HTML 페이지를 만드는 방식
( CSR이라고 생각하면 될 것 같음)

• 장점
  • 프런트엔드 영역 / 백엔드 영역이 명확하게 구분 ➜ 개발 및 유지보수가 상대적으로 용이
  • 프런트엔드 측에서 비동기 클라이언트 애플리케이션을 만드는 것이 가능해짐

 

✔️ JSON ( JavaScript Object Notation )
➜ Spring MVC에서 클라이언트 애플리케이션과 서버 애플리케이션이 주고 받는 데이터 형식
➜ 기본 포맷 = {”속성”:”값”} 형태

 

✔ C = Contoller

• 클라이언트 측의 요청을 직접적으로 전달 받는 엔드포인트(Endpoint)
• Model과 View의 중간에서 상호 작용을 해주는 역할
  ( 요청 전달받고, Model 데이터를 View로 전달 )

✔️ 엔드포인트 (Endpoint)
- 컴퓨터와 네트워크에 연결하고 컴퓨터 네트워크와 정보를 교환하는 물리적 디바이스

 

✔ Spring MVC 최종 흐름

( 간단하게 추린 동작 방식 )

1. Client가 요청 데이터 전송
2. Controller가 받아서 요청 데이터 수신
3. 비즈니스 로직 처리
4. Model 데이터 생성
5. Controller에게 Model 데이터 전달
6. Controller가 View에게 Model 데이터 전달
7. View가 응답 데이터 생성

---

✏️ JASON 표기법 사용 연습

[참고] https://jsonformatter.org/json-to-java 이용

위와 같이 직원들의 정보를 JSON 형식으로 넣고 돌려보니,
아래와 같이 Java로 변경되어 잘 나왔다!

[참고] https://codebeautify.org/blog/json-full-form/

---

✏️ Spring MVC 요청 처리 흐름 ⭐

(1) 먼저 클라이언트가 요청을 전송하면 DispatcherServlet 클래스에 요청이 전달됨

🔊 클라이언트가 DispatcherServlet한테 요청 전송하고 전달 받음

(2) DispatcherServlet 클라이언트의 요청을 처리할 Controller에 대한 검색을 HandlerMapping 인터페이스에게 요청

🔊 DispatcherServlet ➜ HandlerMapping "야 Contoller 좀 검색해봐"

(3) HandlerMapping이 클라이언트 요청 + 매핑되는 핸들러 객체를 다시 DispatcherServlet에게 리턴

🔊 HandlerMapping ➜ DispatcherServlet "야 그 요청에 알맞은 Controller 찾았어"
( 여기서 핸들러 객체 - Controller 내부 메서드)

• 핸들러 객체는 해당 핸들러의 Handler 메서드 정보를 포함하고 있음
  ( Handler 메서드 = Controller 클래스 안에 구현된 요청 처리 메서드 )

(4) 요청을 처리할 Controller 클래스를 찾았으니, 이제 실제로 클라이언트 요청을 처리할 Handler 메서드를 찾아 호출해야 함
DispatcherServlet이 Handler 메서드 직접 호출하지 않고, HandlerAdpater에게 Handler 메서드 호출 위임함

🔊 DispatcherServlet ➜ HandlerAdpater "야 이거 Handler 한테 처리하라고 해"

(5) HandlerAdapter가 DispatcherServlet으로부터 전달 받은 Controller 정보를 기반으로, 해당 Controller의 Handler 메서드 호출

🔊 HandlerAdapter ➜ Controller "야 Handler 메서드 너 나와서 이거 처리해봐"
( 이 Controller 클래스가 Spring MVC에서 클라이언트 요청의 최종 목적지 )

여기까지 흐름의 반을 돎 ! 이제 반대로 ~

(6) Controller의 Handler 메서드가 비즈니스 로직 처리 후 리턴 받은 결과물인 Model 데이터를 HandlerAdapter에게 전달

🔊 Controller ➜ HandlerAdapter "야 이거 다 해서 결과물(Model) 너한테 줄게"

(7) HandlerAdapter가 전달받은 Model 데이터와 View 정보를 다시 DispatcherServlet에게 전달

🔊 HandlerAdapter ➜ DispatcherServlet "야 결과물(Model)이랑 View 정보 줄게"

(8) DispatcherServlet이 전달 받은 View 정보를 다시 ViewResolver에게 전달해서 View 검색 요청

🔊 DispatcherServlet ➜ ViewResolver "야 이 View 정보 검색해봐"

(9) ViewResolver가 View 정보에 해당하는 View를 찾아서 View를 다시 리턴

🔊 ViewResolver ➜ DispatcherServlet "그 정보에 해당하는 View 여기 있어"

(10) DispatcherServlet이 ViewResolver로부터 전달 받은 View 객체를 통해 Model 데이터를 넘겨주면서, 클라이언트에게 전달할 응답 데이터 생성을 요청

🔊 DispatcherServlet ➜ View 객체 "야 여기 결과물(Model) 있으니까 클라이언트한테 줄 응답 데이터 좀 만들어봐"

(11) View가 응답 데이터 생성해서 다시 DispatcherServlet에게 전달

🔊 View ➜ DispatcherServlet "야 여기 다 만듦"

(12) DispatcherServlet이 View로부터 전달 받은 응답 데이터를 최종적으로 클라이언트에게 전달

🔊 DispatcherServlet ➜ 클라이언트 "자 다 했어. 응답 데이터 줄게"

❗ 위 흐름을 보면 DispatcherServlet이 굉장히 중간에서 하는 일이 많아 바빠 보임 !
But, 실제로 요청에 대한 처리는 다른 구성 요소들에게 다 위임(Delegate)하고 있음
(Front Controller Pattern)

➜ DispatcherServlet = 바지사장

---

✔ Front Controller Pattern

➜ DispatcherServlet이 애플리케이션의 가장 앞단에 배치되어 다른 구성요소들과 상호작용하면서 클라이언트의 요청을 처리하는 패턴

✔️ Handler 메서드
➜ Controller 클래스에 있는 애너테이션이 붙어 있는 메서드들
Ex. @GetMapping, @PostMapping, PatchMapping 등

✔️ HandlerMapping
- 사용자의 요청과 이 요청을 처리하는 Handler를 매핑해주는 역할
➜ HTTP 요청 메서드(GET,POST 등)와 Mapping URL을 기준으로 해당 Handler와 매핑
( 여러 모든 핸들러 메서드들의 @~Mapping 애너테이션 정보들을 가지고 있음 )
⠀
( Spring 에서는 여러가지 유형의 HandlerMapping 클래스를 제공하는데 실무에서는 주로 Spring에서 디폴트로 정한 RequestMappingHandlerMapping 사용 )

✔️ HandelrAdpter
- 다른 프레임워크의 핸들러를 Spring MVC에 통합하기 위해 사용
⠀
✔️ Adapter (어댑터)
- 무언가를 다른 형식이나 형태로 바꿔주는 역할

✔️ Resolve
- 무언가를 해석하고 해결해주다

---

✔️ API 계층

( 저번에 배웠지만 잊었을까봐 한번 더 첨부한다 )

---

✏️ 애플리케이션 제작을 위해 제일 먼저 해야되는 일

1. 애플리케이션의 경계를 설정하는 것

✔️ 애플리케이션의 경계를 설정한다
➜ 요구사항에 맞춰서 어떤 애플리케이션의 기능을 특정 범위로 제한하는 것

2. 애플리케이션 기능 구현을 위한 요구 사항을 수집하는 일

3. 패키지 구조 생성

 

✏️ Spring Boot 기반 애플리케이션에서 주로 사용되는 Java 패키지 구조

1. 기능 기반 패키지 구조 (package-by-feature)

• 기능 별로 패키지 나누기
  ( 이 패키지 안에는 하나의 기능 완성을 위한 계층별 클래스들이 모여있음 )

Ex. Coffee, Member 등
( Coffee 패키지 안에는 CoffeeController, CoffeeDto, CoffeeRepository 등의 기능이 있음 )

 

2. 계층 기반 패키지 구조 (package-by-layer)

• 계층 별로 패키지 만들기
  ( 각 패키지 안에는 각 기능들이 모여있음 )

Ex. controller, dto, model, repository, service 등
( controller 패키지 안에는 CoffeeController, MemberController 등의 기능이 있음 )

 

❗ 위 두개를 상황에 따라 알맞게 사용하면 되지만,
테스트와 리팩토링이 용이하고, 향후에 마이크로 서비스 시스템으로의 분리가 상대적으로 용이한 기능 기반 패키지 구조 사용 권장함

 

✏️ Spring Boot 기반 애플리케이션의 정상적인 실행을 위해 가장 먼저 해야될 일

➜ main() 메서드가 포함된 애플리케이션의 엔트리포인트(Entrypoint) 작성

But, Spring Initialize를 통해 프로젝트를 만들면 엔트리포인트 클래스가 자동으로 생성되어 있음

✔️ 엔트리포인트 (Eentrypoint)
➜ 애플리케이션의 시작점

---

✏️ Controller 핸들러 메서드 애너테이션

• @RequestParam
  ➜ 쿼리 파라미터, form-data 등의 Servlet request Parameter를 바인딩 해야 할 경우 사용
  
  
• @RequestHeader
  ➜ request header를 바인딩해서 header의 key/value에 접근할 수 있음
  
  
• @RequestBody
  ➜ request body를 읽어서 지정한 Java 객체로 deserialization 해줌
  
  
• @RequestPart
  ➜ 'multipart/form-data' 형식의 request 데이터를 part 별로 바인딩할 수 있도록 해줌
  
  
• @PathVariable
  ➜ @RequestMapping 에 패턴 형식으로 정의된 URL의 변수에 바인딩할 수 있도록 해줌
  
  
• @MatrixVariable
  ➜ URL 경로 세그먼트 부분에 key/value 쌍으로 된 데이터에 바인딩할 수 있도록 해줌
  
  
• HttpEntity
  ➜ request header와 body에 접근할 수 있는 컨테이너 객체를 사용할 수 있음
  
  

[참고] https://itvillage.tistory.com/41

---

😜 Spring MVC를 이용한 실습

• Project 폴더의 Section3-Week1 파일에 있음
• 자세한 설명은 워드 참고 !

JSON 문자열을 수작업하는 것을 개선하기 위하여
➜ Map 객체로 대신하고 타입을 ResponseEntity 객체로 변경함 !
( 실습 코드 같이 보면서 이해하기 )

---

🌈 느낀점

오늘 개념도 이해하기 쉬웠고 다 괜찮았다 !
페어와의 실습도 빠르게 끝났고 시작이 좋았다.
하지만 git에서 push를 할 때 생긴 오류 때문에 몇시간을 잡아먹은 건지.. ㅠㅠㅠ
할 게 많다 ..

 

( 본 게시물은 2022/10/21에 작성한 글을 옮긴 글입니다. 원문은 요기에 있음! )

728x90