MVC 패턴 (Model-View-Controller Pattern)
- 사용자 인터페이스로부터 비즈니스 로직을 분리함
→ 서로 간의 영향을 받지 않고 쉽게 수정할 수 있도록 하는 소프트웨어 디자인 패턴
- Spring 프레임워크는 MVC 패턴을 준수함
모델 (Model)
- 애플리케이션이 무엇을 할 것인지를 정의하는 역할
- 내부 비즈니스 로직을 처리하기 위함
- DB 데이터를 가진 객체
- 모델의 상태에 변화가 있을 때, 컨트롤러와 뷰에 이를 전달함
→ 뷰는 최신의 결과를 보여주며, 컨트롤러는 모델의 변화에 따라 적용 가능한 명령을 수행할 수 있음
▶ 관련 어노테이션
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 | // 클래스 선언부 상단에 명시하는 어노테이션 // getter, setter, toString 메서드 자동 생성 (Lombok) @Data // 기본 생성자 자동 생성 @NoArgsConstructor // 모든 멤버변수가 포함된 생성자 자동 생성 (일부만 포함하려면 직접 생성하기) @AllArgsConstructor // 빌더 패턴 자동 생성 @Builder // JSON으로 데이터를 받을 때에는 다른 변수 표기법으로 받을 때 (예시 : 스네이크 표기법) @JsonNaming(value = PropertyNamingStrategies.SnakeCaseStrategy.class) // (범위 : 클래스 전체) // 멤버변수 각각에 명시하는 어노테이션 // JSON으로 데이터를 받을 때에는 다른 이름으로 받을 때 @JsonProperty("이름") // 기존 이름으로는 인식되지 않음 (범위 : 해당 멤버변수) | cs |
뷰 (View)
- 화면에 무엇인가를 보여주는 역할
- 모델/컨트롤러가 보여주려 하는 것들을 화면에 처리함
▶ ViewResolver
: 컨트롤러가 반환한 뷰 이름과 매핑하여 해당 뷰 파일을 찾고, 렌더링하는 인터페이스
· /WEB-INF/view/xxx/xxx.jsp를 찾는 역할
컨트롤러 (Controller)
- 모델이 어떻게 처리할지를 알려주는 역할
- 뷰에 명령을 보내어 화면 요청 결과를 전달함
- 모델과 뷰를 연결함
- 사용자의 입력 처리와 흐름 제어
- JSP에서 Servlet이 수행했던 역할
→ Spring Boot에서는 기본 클래스에 어노테이션을 명시해서 사용할 수 있음
- 데이터 기본 파싱 전략 : key-value 구조
- RESTful API에 대한 요청/응답 처리가 가능한 Controller 객체로 지정 : @RestController
→ JSON 방식으로 응답 처리
→ Response 타입이 객체(DTO)면 자동으로 JSON 형식으로 응답 처리됨
: 'Object Mapper'가 알아서 매핑해서 자동 파싱 처리해줌
- 화면(VIEW)에 대한 요청/응답 처리가 가능한 Controller 객체로 지정 : @Controller
- URL 단일 매핑 : @RequestMapping("/매핑")
- URL 다중 매핑 : @RequestMapping({"/매핑1", "/매핑2"})
- Service Layer로 지정 : @Service
- DAO Interface로 지정 : @Mapper
▶ REST API
① Body가 없는 경우
1) GET 방식 처리 : @GetMapping("/매핑")
2) DELETE 방식 처리 : @DeleteMapping("/매핑")
· 쿼리 파라미터 : 매개변수 앞에 @RequestParam 지정
· 경로 파라미터 : 매개변수 앞에 @PathVariable 지정
· 단, DTO 형식으로 파싱 처리할 때에는 어노테이션 X
② Body가 있는 경우
1) POST 방식 처리 : @PostMapping("/매핑")
2) PUT 방식 처리 : @PutMapping("/매핑")
[데이터 전달 방식]
i. JSON 형식으로 전달
- 매개변수 앞에 항상 @RequestBody 지정 (Body에서 데이터를 가져온다는 의미)
ii. form 태그를 활용한 key=value 구조로 전달 (Query String 방식으로 만들어짐)
- @RequestBody 지정 불필요
- URL Mapping을 동일하게 하더라도, 서버는 Method를 구분할 수 있음
- 예시 : https://young0105.tistory.com/188
method | 의미 | CRUD | 멱등성 | 안정성 | Path Variable |
Query Parameter |
Body 유무 |
GET | 리소스 취득 | R | O | O | O | O | X |
POST | 리소스 생성/추가 | C | X | X | O | △ | O |
PUT | 리소스 생성/갱신 | C / U | O | X | O | △ | O |
DELETE | 리소스 삭제 | D | O | X | O | O | X |
▶ 클라이언트(브라우저) ↔ Controller ↔ Service ↔ DAO
1) DAO
: SQL문
2) Service
: 비즈니스 로직
3) Controller
i. (필요하다면) 인증 처리
- 세션에 유저 정보가 저장되어 있는지 (로그인되어 있는지)
ii. 유효성 검사
- 유효성 검사는 프론트엔드, 백엔드 둘 다 해주는 것이 바람직함
iii. 서비스 호출
iv. 나머지 필요한 작업들
v. return "redirect:페이지경로";
- redirect를 하지 않으면 새로운 request/response가 생성되지 않아 원하지 않는 결과가 반환될 수 있음
레이어
- Web Layer : Rest API를 제공하며, Client 중심의 로직 적용
- Business Layer : 내부 정책에 따른 Logic을 개발함 (주로 핵심 업무 부분 개발)
- Data Layer : 데이터베이스 및 외부와의 연동 처리
- Service Layer는 주로 비즈니스 로직을 수행함
· 컨트롤러/뷰 등 다른 레이어와 분리하여 개발함
- 애플리케이션의 유지 보수성과 확장성 향상
- 코드 결합도 축소 & 재사용성 향상
· 트랜잭션 처리
▶ 비즈니스 로직 (Business Logic)
: 애플리케이션에서 수행되는 비즈니스 규칙, 프로세스 등
· 애플리케이션의 핵심적인 업무 처리를 담당하는 로직
ex) 출금 기능
- 계좌 존재 여부 확인 (select)
- 계좌 비밀번호 확인 (select)
- 계좌 잔액 확인 (select)
- 출금 처리 (update)
- 거래 내역 등록 (insert)
'Java > Spring Boot' 카테고리의 다른 글
[Spring Boot] ResponseEntity (0) | 2023.04.11 |
---|---|
[Spring Boot] IoC (제어의 역전) / DI (의존성 주입) ★ (0) | 2023.04.11 |
[Spring Boot] REST API - Controller 구현 예시 (0) | 2023.04.10 |
[Spring Boot] 파라미터 전달 방식 (0) | 2023.04.09 |
[Spring Boot] 개요 (0) | 2023.04.07 |