728x90
Model View Controller
애플리케이션의 구성 요소를 세 가지 역할로 구분해 개발 프로세스에서 각각의 구성 요소에만 집중해서 개발할 수 있도록 한 패턴
생기게 된 배경
- 길어지는 코드의 가독성, 유지보수가 불편해짐
- 각 코드가 반복되며 코드의 기능별로 패턴을 나누게 됨
장점
- 단순, 직관적
- 재사용성과 확장성 용이
- 각 계층의 변화가 다른 계층에 변화를 일으키지 않아 변동에 유리함.
단점
- 애플리케이션의 규모가 커지고 복잡해질수록 모델과 뷰의 관계가 복잡
- Controller와 View의 강결합
- 대상 플랫폼에 따라 적용이 불가능할 수 있음 (안드로이드)
- 안드로이드의 경우 Activity에서 view를 관리하고, 도메인 로직을 사용해야 하므로 controller와 view가 함께 있을 수밖에 없다.
MVC 패턴을 지키기 위한 5가지 규칙
- Model은 Controller와 View에 의존하지 않아야 한다.
- View는 Model에만 의존해야 하고, Controller에는 의존하면 안된다.
- View가 Model로부터 데이터를 받을 때는, 사용자마다 다르게 보여주어야 하는 데이터에 대해서만 받아야 한다.
- Controller는 Model과 View에 의존해도 된다.
- View가 Model로 부터 데이터를 받을 때, 반드시 Controller에서 받아야 한다.
Model
애플리케이션의 데이터(상수, 변수 등)와 관련된 부분
도메인 모델: 속성과 상태를 가지며 자신의 상태를 관리하는 모델
- 규칙: Model은 Controller와 View에 의존하지 않아야 한다.
(controller가 없더라도 Model의 코드에는 문제가 없도록 작성되어야 한다.)
View
사용자에게 보이는 것과 관련된 부분
사용자로부터 입력을 받거나 사용자에게 보여지는 화면.
모델의 정보를 참조할 수 있으나, 모델의 정보를 가지고 있거나 ui 요소 외 추가적인 연산이 이뤄지지 않아야 한다.
- 규칙: View는 Model에만 의존해야 하고, Controller에는 의존하면 안 된다.
(controller가 없더라도 View의 코드에는 문제가 없도록 작성되어야 한다.) - View가 Model로부터 데이터를 받을 때는, 사용자마다 다르게 보여주어야 하는 데이터에 대해서만 받아야 한다.
(Model의 상태, 저장된 값만 참조하고, 메서드, 연산 등을 사용하지 않아야 한다.)
Controller
Modelrhk View의 기능을 이어주고, 중개해 주는 부분
- 규칙: Controller는 Model과 View에 의존해도 된다.
(Controller는 Model과 View를 이어주고, 연산을 직접 하는 것이 아니라 각각에게 메시지를 전달해야 한다.) - 규칙: View가 Model로부터 데이터를 받을 때, 반드시 Controller에서 받아야 한다.
(연산은 Controller가 Model에게 시키고, 화면에 그리는 것은 Controller가 값을 model에게 받아 View에게 시키다.)
그 외
- 값에 대한 유효성 검증은 어디에서 이루어져야 하는가? 는 트레이드오프의 영역인 것 같습니다.
- 제 생각을 말해보자면, 어느 정도는 View에서 이루어져야 한다.
왜냐하면, View에서 하지 않을 경우 Controller의 역할이 방대해지고,
사용자로부터 받은 값이기 때문에 View의 역할이라고 보았습니다. - 그렇다고 View에서만 검증하면 안 된다고 봅니다. 받아온 값을 연산하는 중에도 문제가 있을 수 있죠.
각 계층별로 특정한 기준에 따라 검증이 필요하다고 생각합니다. - 아래와 같은 기준으로 예시를 들 수 있을 것 같습니다!
ex. 제품의 개수를 입력받을 때
View의 검증 내용: 숫자로만 이루어져 있는가
Domain의 검증 내용: 음수가 아닌가
- 제 생각을 말해보자면, 어느 정도는 View에서 이루어져야 한다.
참고
- https://thebook.io/080326/0038/
- https://www.youtube.com/watch?v=ogaXW6KPc8I (10분 테코톡. 제리)
- https://www.youtube.com/watch?v=es1ckjHOzTI (10분 테코톡. 범블비)
728x90
'CS note > 디자인 패턴, 프로그래밍 패러다임' 카테고리의 다른 글
strategy pattern (전략 패턴) (1) | 2023.01.27 |
---|---|
factory pattern (팩토리 패턴) (0) | 2023.01.25 |
singleton pattern (싱글톤 패턴) (0) | 2023.01.20 |
디자인 패턴 및 프로그래밍 패러다임 (0) | 2023.01.20 |
댓글