[Spring Boot] MVC 패턴

MVC 패턴 (Model-View-Controller Pattern)

  - 사용자 인터페이스로부터 비즈니스 로직을 분리함

      → 서로 간의 영향을 받지 않고 쉽게 수정할 수 있도록 하는 소프트웨어 디자인 패턴

  - Spring 프레임워크는 MVC 패턴을 준수함

 

 

---

모델 (Model)

  - 애플리케이션이 무엇을 할 것인지를 정의하는 역할

  - 내부 비즈니스 로직을 처리하기 위함

  - DB 데이터를 가진 객체

  - 모델의 상태에 변화가 있을 때, 컨트롤러와 뷰에 이를 전달함

      → 뷰는 최신의 결과를 보여주며, 컨트롤러는 모델의 변화에 따라 적용 가능한 명령을 수행할 수 있음

     

▶  관련 어노테이션

 

// 클래스 선언부 상단에 명시하는 어노테이션
 
    // getter, setter, toString 메서드 자동 생성 (Lombok)
    @Data 
 
    // 기본 생성자 자동 생성
    @NoArgsConstructor 
 
    // 모든 멤버변수가 포함된 생성자 자동 생성 (일부만 포함하려면 직접 생성하기)
    @AllArgsConstructor 
 
    // 빌더 패턴 자동 생성
    @Builder
 
    // JSON으로 데이터를 받을 때에는 다른 변수 표기법으로 받을 때 (예시 : 스네이크 표기법)
    @JsonNaming(value = PropertyNamingStrategies.SnakeCaseStrategy.class) // (범위 : 클래스 전체)
 
 
// 멤버변수 각각에 명시하는 어노테이션
 
    // JSON으로 데이터를 받을 때에는 다른 이름으로 받을 때
    @JsonProperty("이름") // 기존 이름으로는 인식되지 않음 (범위 : 해당 멤버변수)

 

 

---

뷰 (View)

  - 화면에 무엇인가를 보여주는 역할

  - 모델/컨트롤러가 보여주려 하는 것들을 화면에 처리함

 

▶  ViewResolver

  : 컨트롤러가 반환한 뷰 이름과 매핑하여 해당 뷰 파일을 찾고, 렌더링하는 인터페이스

  · /WEB-INF/view/xxx/xxx.jsp를 찾는 역할

 

 

반응형

728x90

---

컨트롤러 (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)