일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- C언어
- 컴포넌트스캔
- nestJS
- @Autowired
- 프로그래머스
- Spring
- 파이썬
- 카카오
- 코테
- python
- TypeORM
- 가상면접사례로배우는대규모시스템설계기초
- 알고리즘
- spring boot
- 카카오 코테
- 스프링
- AWS
- 시스템호출
- OpenCV
- thymeleaf
- git
- nestjs typeorm
- 해시
- @Component
- 카카오 알고리즘
- nestjs auth
- Nodejs
- C++
- 코딩테스트
- 구조체배열
- Today
- Total
공부 기록장 💻
MVC 패턴이란? 본문
우아한테크코스 프리코스의 3주차 미션은 다음과 같다.
1) 클래스를 분리하고,
2) 도메인 로직에 대한 단위 테스트를 작성하는 연습을 하는 것
그리고 프로그래밍 요구 사항들을 세부적으로 살펴 보면, 핵심 로직을 구현하는 코드와 UI를 담당하는 로직을 분리하여 구현해야 하며, 도메인 로직에 단위 테스트를 구현해야 한다고 명시되어 있다.
그래서 도메인 로직이 무엇일까?
도메인 로직(비즈니스 로직)에 대해 조사를 해보니, 이는 소프트웨어 설계 과정에서 프로그래밍을 할 때 차용하게 되는 패턴 중 하나로, 도메인이란, MVC 패턴에서 Model에 해당하는 것을 말한다.
우선적으로 MVC 패턴을 이해하며, 핵심 로직 부분과 UI를 담당하는 로직을 분리해 구현하여 프로그램을 설게하고, 도메인 로직에 대한 단위 테스트 작성 연습을 해보도록 하자.
MVC 패턴이란?
wikipedia에서 MVC에 대해 정의하고 있는 것을 살펴보면 다음과 같다.
Model-View-Controller는 소프트웨어 공학에서 사용되는 소프트웨어 디자인 패턴이다.
이 패턴을 성공적으로 사용하려면, 사용자 인터페이스로부터 비즈니스 로직을 분리하여 애플리케이션의 시각적 요소나 그 이면에서 실행되는 비즈니스 로직을 서로 영향 없이 쉽게 고칠 수 있는 애플리케이션을 만들수 있다.
MVC 패턴은 프로그래밍을 할 때, 전체적인 구조에 관련된 여러 디자인 패턴 중 하나이다.
도메인(비즈니스) 로직과 UI 로직을 분리하여 유지보수를 독립적으로 수행할 수 있게 하는 장점을 지니고 있다고 한다.
MVC 패턴의 구조
Model (Domain) : 데이터와 관련된 책임을 담당하는 레이어
- Model이란, 프로그램이 작업하는 세계관의 요소들을 개념적으로 정의한 것으로 볼 수 있다.
- 음식점 무인 포스기 프로그램을 개발한다고 했을 때, 무인 포스기가 정상적으로 작동하게 하기 위해서는 메뉴, 메뉴를 담는 장바구니, 해당 메뉴의 수량과 결제 수단, 할인 정책 등이 필요하다. 이러한 물리적 개체, 규칙, 작업 등의 요소들을 구분되는 역할로 정의해 놓은 것이 Model이라 할 수 있다.
- 어떠한 작업을 수행하는데 특정 책임과 역할로서 구분될 수 있다면, 최대한 구체적이고 작은 entity를 유지하면서 Model을 설계하는 것이 중요하다.
- 비즈니스 로직을 수행한다. (데이터와 관련된 저장, 가공 등의 일을 수행한다.)
- 상태 변화를 처리한다. (Entity, VO, Aggregate로 나뉘어 관리 -> 도메인 주도 설계)
- @Entity (영속성에서 테이블에 매핑되는 클래스)가 주로 대상이다.
- 데이터와 행동을 갖는 객체이다.
View : 사용자에게 보일 사용자 인터페이스를 담당하는 레이어
- 데이터를 시각적으로 표현하고, 사용자에게 알맞은 화면을 보여주는 역할을 수행한다.
- 결과값 출력, 사용자 요구(버튼 클릭 또는 사용자의 데이터 입력)
- 데이터, 로직은 없어야 한다. 도메인 로직의 어떤 것도 알고 있어서는 안된다.
- 절대적으로 객체를 전달받아 상태를 바로 출력하는 역할만을 담당해야 한다.
- view에서는 도매인 객체의 상태를 따로 저장하고 관리하는 클래스 변수 또는 인스턴스 변수가 있을 필요가 없다.
- 웹에서는 웹 브라우저로 렌더링 되는 페이지가 해당된다. 모델이 처리한 데이터를 받아 합산하고, 사용자의 브라우저로 렌더링 되는 페이지이다.
- 동적으로 처리되어야 할 데이터를 시각화 해준다. (상황과 도메인에 맞게 다른 값을 가져야 하는 데이터들에 대해서만 모델에서 받아온다.)
Controller : Model과 View를 연결해주는 레이어
- 사용자의 요청(View를 통한 입력)에 맞는 서비스(Model에서의 데이터 변경)를 실행한다.
- 프로그램의 작동 순서나 방식을 제어하고, 입출력의 순서나 데이터 양식을 결정한다.
- 따라서 view와 model이 각각 어떤 역할과 책임이 있는지 알아야 한다.
- 처리한 모델의 값을 뷰에 전달하여 반환한다.
- 사용자의 요청을 가장 먼저 마주하는 레이어이다.
- 사용자의 인증, 보안 설정 등 전체적인 애플리케이션에 영향을 미치는 요소를 구현한다.
예제들로 컨트롤러의 역할을 살펴보자.
1) View를 통해 전달된 사용자의 요청을 분석
- if (ob==bt_new)
2) 사용자가 입력한 데이터를 얻어오는 기능
- tf.getText();
3) 모델 클래스의 객체를 생성
- Caculator calc = new Caculator();
- 메소드 호출 -> calc.add(2,3);
- 데이터 저장 -> int result = calc.add(2,3);
4) 페이지 이동 또는 이동할 페이지 선택
5) 유효성 검색 - Valid Check
** 컨트롤러를 제외한 모델, 뷰 레이어는 다른 레이어를 알아서는 안 된다.
MVC 패턴의 장점은 무엇인가?
장점
- 동시 다발적으로 개발할 수 있다.
- 백엔드와 프론트엔드가 독립적으로 개발할 수 있으며, 각 파트에서도 독립적인 개발이 가능하다.
- 책임 영역이 구분되어 응집도가 높고 결합도가 낮은 설계를 할 수 있게 된다.
- 뷰와 모델이 다른 레이어에서 독립적으로 각각의 역할을 하므로, 이들을 연결하는 컨트롤러는 뷰와 모델에 대한 의존성만 지닌다.
- 관리 가능한 의존도로 관리할 수 있게 된다.
MVC 패턴의 원칙들
1. Model은 Controller와 View에 의존해서는 안 된다.
- 각 레이어에서는 각각 담당하는 책임이 존재하는데, Model이 Controller, View의 책임을 가지면 안 된다는 뜻이다.
- 오로지 데이터에 대한 순수 로직만 존재하는 것이 바람직하다.
2. View는 Model에만 의존한다.
- 여기서 의존이란 순수 도메인 데이터에 대한 의존을 말하는데, View에서 사용되는 값은 Model에서 전달된 값이어야 하며, 이 때 Controller가 Model에 대한 값을 View로 넘겨주는 역할을 한다.
3. View는 Model로부터 사용자마다 다르게 변경되는 데이터만 받아야 한다.
- 사용자마다 다른 생애 주기를 가진 data만을 Model이 받아야 하는데, 공통된 정보에 대해서는 자체적으로 View가 소유해야 한다. 즉, 공통으로 처리되는 부분에 대해서는 View 자체에서 처리되어야 한다.
4. Controller는 Model과 View에 의존해야 한다.
- 컨트롤러는 들어온 요청에 맞게, Model에 로직을 호출하고 그 결과를 View로만 전달하면 된다.
5. View가 Model로부터 데이터를 받을 때는 Controller에서 받아야 한다.
- Controller는 요청에 맞는 서비스를 호출하고, 로직에 처리된 Model의 결과를 View로 전달해야 한다.
[참고자료]
'# Develop > Project' 카테고리의 다른 글
[Python] 웹 스크래핑 하기 (내 블로그의 최신 글과 링크 가져오기) (0) | 2023.02.05 |
---|---|
[Python/Data Analysis] Fitbit 기초 운동량 데이터를 분석해보자 (0) | 2022.12.09 |
[Database Modeling] 원티드 채용 플랫폼의 채용 시스템 DB 모델링을 위한 사전 자료 조사 및 분석 (3) | 2022.10.21 |
카카오 소셜 로그인 과정 이해하기 (0) | 2022.09.27 |
[NestJS/오세유] 오세유 프로젝트 진행 상황과 팀 회의 회고 1 (0) | 2022.09.09 |