Model -View -Controller 의 약자로, 소프트웨어 디자인 패턴이다.
- 비즈니스 로직과 UI를 분리시키는데 중점을 둔다.
- MVC에 기반을 둔 다른 디자인 패턴으로는 MVVM(모델-뷰-뷰모델), MVW(모델-뷰-왓에버), MVP(모델-뷰-프리젠터) 가 있다.
- 단점으로는 View와 Model 사이의 의존성이 높다는 것이다. 이는 App의 크기가 커질수록 복잡해지며 유지보수가 어려워진다.
| 컴포넌트 | 관계 |
|---|---|
| Model | 다른 컴포넌트에 대해 모름. 오직 자신이 무엇 을 수행하는지만 암. |
| View | 다른 컴포넌트에 대해 모름. 수동적으로 VC에서 주는 것만 띄움. |
| Controller | 유일하게 다른 컴포넌트들을 알고있음. 그들이 뭘 수행하는지도 알고있음. |
MVC를 사용하는 이유?
1️⃣ 처음엔 MVC 구분 없이 하나의 덩어리로 섞어서 구현.
2️⃣ 그러다보니 View의 수정이 필요한데, 비즈니스 로직과 컨트롤 코드가 섞여있어 읽기도 어렵고 수정을 진행하다 비즈니스 로직 / 컨트롤 코드에 영향을 끼쳐 버그가 발생.
3️⃣ 거기에 기능이 추가될 때마다 작았던 하나의 코드 덩어리가 큰 덩어리로 불어나게 되면서, 유지보수가 더욱 힘들어짐.
4️⃣ 사람들은 고민을 하기 시작함. 그러던 중 APP 의 핵심은 View - Model - Controller 인데, 이 셋의 연관관계를 찾게 됨.
그렇게 탄생한게 MVC 이고, 각각의 목적에 따라 분리시켜 위의 문제점이었던 유지보수와 확장성을 개선하게 됨
Model
- App이
무엇을 할건지 정의- 내부 비즈니스 로직을 처리
- DB와 연동해 입/출력 데이터를 다룸
- 데이터의 상태가 변경되면, Controller에게 알림 (데이터의 변화. 즉, 필요한 화면으로 전환)
- 업데이트 된 View를 제거하기위해 Controller에게 알리기도 함
- 구조체에 정보를 저장하는것 말고, 그 구조체의 UI를 어떻게 꾸밀지는 전혀 고민하지 않아도 된다.
View
- 사용자의 요청을
화면에 띄움(UI)- Contoller가 Model에게 데이터 받아 View에게 화면 구성을 지시함
- 재사용성이 강조됨 (Ex. 앱 전체에 들어가는 버튼을
myButton으로 정의하는 등)
- View는 Delegate / Datasource 등을 이용해 Controller에게 변화를 알린다.
- Model이 먼저 변하면 (Ex. 서버에서 데이터를 받음) 변한 내용을 Controller에게 알려서 View를 변화시킨다.
Controller
- Model과 View 사이에 존재하는 일종의 조정자
- 유일하게 다른 컴포넌트들이 무엇을 수행하는지 알고있음
- 항목을 번호순으로 정리하는 등 단순히 뷰를 업데이트하고 싶을때는 Model을 건너띄고 View에게 명령을 내리기도 함
정리해보자면,
입력을 받는 View 에서 사용자 요청 을 받음
➡️ View 가 Delegate 등을 이용해 Controller 에게 Event 발생을 알림
➡️ 전달을 받은 Controller 가 Model 에게 데이터를 요청
➡️ Model 도 Delegate 등을 이용해 Controller 에게 요청받은 데이터를 전달
➡️ Controller 가 View 에게 출력할 데이터와 맞는 화면을 요청
이미지로 확인해보면 이해가 더 쉬울 수 있다.
.png)
참고 문서
1. iOS MVC
2. https://choi-log-life.tistory.com/entry/iOS-MVC-Pattern
3. 공식문서
4. https://medium.com/hcleedev/ios-%EA%B0%9C%EB%B0%9C-mvc-%ED%8C%A8%ED%84%B4%EA%B3%BC-uikit%EC%9D%98-viewcontroller-3fdb52f6b4b8
