11/01 GDSC 백엔드 스터디 정리

목차

1. Spring MVC

 

2. 3 tier - Architeture

 

3. DTO

 

Spring MVC

Spring Web

- HTTP Request가 오면 이에 맞는 컨트롤러를 디스패처 서블릿이 배정해준다.

- 컨트롤러에서는 비즈니스 로직을 실행 후 데이터를 모델에 담아서 뷰 이름을 지정하여 디스패처 서블릿에 넘긴다.

- 디스패처 서블릿은 이름에 맞는 뷰를 뷰 리졸버에 요청하여 찾고 모델을 해당 뷰에 넘긴다.

- 이후 디스패처 서블릿은 뷰를 유저에게 반환한다.

 

Spring MVC

- 구성하는 요소는 디스패처 서블릿, 컨트롤러, 핸들러 어댑터, 뷰 리졸버, 뷰로 위에서 설명한 순서로 동작한다.

- 모델은 데이터를 저장하는 객체로 뷰에서 특정 데이터를 동적으로 보여주기 위해 사용한다.

 

순서

• 1. 핸들러 조회: 핸들러 매핑을 통해 URL에 매핑된 핸들러(컨트롤러) 조회
• 2. 핸들러 어댑터 조회: 핸들러를 실행할 수 있는 핸들러 어댑터 조회
• 3. 핸들러 어댑터 실행: 핸들러 어댑터 실행
• 4. 핸들러 실행: 핸들러 어댑터가 실제 핸들러를 실행
• 5. ModelAndView 반환: 핸들러 어댑터는 핸들러가 반환하는 정보를 ModelAndView로 변환해 반환
• 6. viewResolver 호출: 뷰 리솔버를 찾아 실행한다. ⇒ JSP: InternalResourceViewResolver가 자등 등록되어 사용된다.
• 7. View 반환: 뷰 리솔버는 렌더링 역할을 담당하는 뷰 객체 반환. ⇒ JSP: InternalResourceView(JstlView)를 반환하는데, 내부에는 forward() 가 있다.
• 8. 뷰 렌더링: 뷰를 통해서 뷰를 렌더링한다.

정리

-> 현재 대부분의 기능은 수년간 이미 다 구현되고 확장되었기에 스프링에 기능 자체가 없어서 직접 구현할 일은 없지만 내부 로직과 흐름에 대해 이해한다면 내 프로젝트의 문제가 생겼을 때 디버깅을 할 때 몹시 유리하다.

 

Spring MVC 어노테이션

@RequestMapping - 기본 매핑, HTTP Method 전체 허용

@GetMapping - Get Mapping 전용 어노테이션

@PostMapping - Post Mapping 전용 어노테이션

@PutMapping - Post Mapping 전용 어노테이션

@DeleteMapping Delete Mapping 전용 어노테이션

 

@PathVariable - PathVariable(경로 변수)를 사용한 매핑

@Consumes = application/json - Content-Type 헤더 기반 추가 매핑 미디어 타입

@RestController - @Controller와 @ResponseBody가 합쳐진 것  

@RequestParam - 파라미터 이름으로 바인딩

@RequestBody - HTTP 메세지 바디 정보를 편리하게 조회하게 해주는 어노테이션

 

3 tier - Architecture

Model - View - Controller

 

Model

프로그램이 작업하는 세계관의 요소들을 개념적으로 정의한 것

 

프로그램이 목표하는 작업을 원활하게 수행하기 위해 필요한 물리적 개체, 규칙, 작업 등의 요소들을 구분하는 역할

앱의 데이터와 비즈니스 로직을 가지고 있다.

 

결과적으로 모델을 잘 설계했다라는 것은

-> 해당 도메인 세계를 얼마만큼 이해하고 있는지와도 밀접한 연관이 있다.

-> 물리적인 요소뿐만 아니라 추상적인 요소 또한 해당 작업을 수행하는데 특정 책임과 역할로서 구분 될 수 있다면 최대한 구체적이고 작은 엔티티를 유지하면서 모델을 설계하는 것이 중요하다.

 

 

View

사용자가 보는 화면에 입출력 과정 및 결과를 보여주기 위한 역할(UI 담당)

 

입출력의 순서나 데이터 양식은 컨트롤러에 종속되어 결정된다.

이 때 뷰는 도메인 모델의 상태를 변환하거나, 받아서 렌더링하는 역할을 한다.

객체를 전달받아 상태를 바로 출력하는 역할만을 담당해야한다.

뷰에서는 도메인 객체의 상태를 따로 저장하고 관리하는 클래스 변수나 인스턴스 변수가 필요없다.

 

 

Controller

Model과 View를 연결시켜주는 다리 역할

 

도메인 객체들의 조합을 통해 프로그램의 작동 순서나 방식을 제어한다.

뷰와 모델이 각각 어떤 역할과 책임이 있는지 알고 있어야 한다.

 

뷰로부터 사용자의 액션을 받아 모델에게 어떤 작업을 해야하는지 알려주거나 모델의 데이터 변화를 뷰에게 전달하여 뷰를 어떻게 업데이트할지 알려준다. 

모델, 뷰에게 직접 지시가 가능하다.

 

 

 

전체적인 서버 구조와 클라이언트로 이어지는 통신 구조

클라이언트(브라우저) -> 컨트롤러 -> 서비스 -> 레포지토리 -> DB

-> 레포지토리 -> 서비스 -> 컨트롤러 -> 클라이언트(브라우저)

 

(->)마다 DTO를 반환한다. Data Trensfer Object

 

 

 

3가지 서버 계층(데이터적 관점)

Presentation Layer(Client Tier) <-> Business Logic(Application Tier) <-> Data Access Logic , DB (Data Tier)

 

스프링에서는

Web Layer <-(DTO)-> Service Layer <-(Domain Model)-> Repository Layer

 

 

Web Layer

흔히 사용하는 컨트롤러와 JSP/freemarker 등의 View 템플릿 영역이다.

이외에도 Servlet의 Filter, Spring의 Intercepter, ControllerAdvice 등 외부 요청과 응답에 대한 전반적인 영역을 말한다.

 

 

Service Layer

일반적으로 컨트롤러와 레포지토리의 중간 영역에서 사용한다.

트랜젝션이 발생하는 구간이기 때문에 @Transactional이 사용되어야 영역이다.

보통 여기서 비즈니스 로직을 처리하나 관점에 따라 Domain Model에서 비즈니스 로직을 처리하기도 한다.

 

 

Repository Layer(Persistence Layer)

DB에 접근하는 영역

DAO(Data Access Object)의 영역

 

 

Dto

계층 간에 데이터 교환을 위한 객체

 

 

Domain Model(Business Layer)

도메인이라 불리는 개발 대상을 모든 사람이 동일한 관점에서 이해할 수 있고 공유할 수 있도록 단순화시킨 것을 도메인 모델이라고 한다.

ex) 택시 앱 -> 배차, 탑승, 요금 등이 모두 도메인이 될 수 있다. 

@Entity가 사용된 영역이 도메인 모델이다.

 

 

 

DTO

DTO(Data Transfer Object)

계층 간 데이터 교환을 하기 위해 사용하는 객체로, DTO는 로직을 가지지 않는 순수한 객체(getter, 생성자)만 가진 클라스

 

! 굉장히 중요) 도메인 모델을 캡슐화 하여 보호할 수 있다.

 

-> 하나의 DTO로 서버스까지 쭉 전달하는 것은 컨트롤러와 서비스 간의 의존을 강화하니까 안된다.

특히 컨트롤러와 서비스의 의존은 매위 위험하다.