MVC
Model + View + Controller
iOS 앱의 MVC 패턴
Model
데이터와 데이터를 관리하는 비즈니스 로직을 갖고 있다.
Model은 UI와 직접적으로 연결되지 않는다. 불가능한 것은 아니나 MVC 패턴을 제대로 활용하기 위해 Model은 받아온 데이터를 그에 맞추어 저장할 형태를 만드는 것이 더 중요하다.
Model에는 대부분 이런 코드들이 포함된다.
- 데이터로 사용하는 구조체
- 네트워크 로직: 네트워크 요청을 하고, 그 결과를 받아오는 기본적인 기능
- Persistance 로직: 메모리에 저장되는 데이터를 로드 및 세이브하는 로직
- 데이터 파싱: JSON 등의 데이터가 왔을 때 파싱하는 로직
- Manager 객체 (shared 객체): 구조체를 만들어두고 필요한 경우 어디서든 접근해 사용할 수 있도록 Manager를 따로 만드는 경우
- Util, Extenstion, Constant 등
View
사용자에게 데이터를 보여주고, 어떻게 보여줄지 UI를 구성하는 코드들은 포함한다. View는 직접 유저와 상호작용을 하기 때문에 이를 Controller로 전달하는 역할도 한다. 기본적으로 View는 Controller로부터 정리된 데이터를 받아 화면에 보여주는 역할을 하지만, 간단한 정보들은 View 단에서 정의해서 사용할 수 있다.
View를 작성할 때는 재사용성이 강조된다.
View에는 주로 아래 코드들이 포함된다.
- UIView를 상속해 만들어진 subclass
- Core Animation
- Core Graphics
Controller
Controller는 앱의 핵심 로직을 담고있다. MVVM의 ViewModel의 역할과 비슷하다. Model과 View의 중간다리 역할로 View로부터 사용자의 action을 받아 Model에게 어떤 작업을 해야하는지 알려주거나, 모델의 데이터 변화를 뷰에게 전달하여 View를 어떻게 업데이트할지 알려준다.
Controller는 View마다 하나씩 붙어서 그 View에 맞는 로직을 포함하기 때문에, 재사용성은 View보다 훨씬 떨어진다. 재사용성이 적다보니 코드가 길어지는 경우가 많다.
Controller vs UIKit UIViewController
Controller는 Model과 View에 모두 연결되어, 그 역할에 따라 두가지로 나눌 수 있다.
첫 번째는 Controller가 Model을 가지고 있는 Model Controller이다. 이 Model Controller는 Model의 데이터를 관리하고, View에 데이터를 전달하는 역할을 한다.
두 번째는 Controller가 View를 가진 View Controller이다. View를 관리하고 유저와의 상호작용도 관리하며, Model의 데이터를 업데이트하는 역할을 한다.
UIViewController가 Controller와 비슷한 역할을 하기는 한다. 하지만 UIViewController는 그가 하나의 Root View를 관리하며, 그 아래의 많은 subView들까지 관리한다.
- Model로부터 받아온 데이터의 변화에 따라 View를 업데이트
- 유저와의 상호작용에 반응
- View의 Layout을 관리하고 Resize
- 다른 객체와의 상호작용
계층 간의 커뮤니케이션
MVC의 동작 구조
Controller는 Model과 View에 어렵지않게 접근할 수 있다. Controller에 속한 subView에 직접 접근해 설정을 변경할 수도 있고, 생성된 Model 객체를 받아왔다면 그 객체에 직접 접근해 데이터를 활용할 수도 있다. 하지만 문제는 Model에서 Controller로 가거나, View에서 Controller로 갈 때인데, 이를 KVO(Key-Value Observing)와 Delegation으로 해결한다.
Model에서 Controller로 뭔가 전달해야 하는 경우
애초에 Model은 데이터를 제공할 뿐, Controller가 어떻게 이루어져있는지 아예 모르는 구조이기 때문에 직접 접근하는 것은 불가능하다. 이때 Controller는 Model에 있는 property에 Key-Value Observing을 이용해 그 프로퍼티의 변화를 감지할 수 있고, 그에 따라 새로운 데이터를 받아올 수 있다. 혹은 Notification을 이용해 뭔가 변화했다는 신호를 보내두면, 나중에 Controller가 그 알림을 보고 다시 Model에 접근해 새 데이터를 받아올 수도 있다.
View에서 Controller로 전달해야 하는 경우
대부분 유저와의 상호작용에 대해 전달하는 경우일텐데, 주로 Delegation 방식을 이용해 Controller에 관련 코드를 작성한다. Delegate는 위임한다는 뜻으로, View에 어떤 이벤트가 발생하면 그 이벤트의 처리를 delegate로 연결해둔 Controller에게 위임한다. Data Source도 비슷한 역할을 한다.
Model이나 View 모두 결국 Controller에 직접 접근할 수 없으므로 결국 역할을 ViewController가 도맡아 하는 격
MVC 패턴의 장점과 단점
😈 장점
- 다른 패턴에 비해 코드량이 적다
- 애플에서 기본적으로 지원하는 패턴이며, 때문에 쉽게 접근할 수 있다.
- 이미 많은 개발자들에게 친숙한 패턴이기 때문에 쉽게 유지보수할 수 있다.
- 개발 속도가 빠르기 때문에 아키텍처가 중요하지 않거나 작은 규모의 프로젝트에서 사용하기 좋다.
👿 단점
- 위 사진과 같이 View와 Controller가 너무 밀접하게 연관되어 있다.
ViewController에서 볼 수 있듯, View와 Controller가 붙어 있으며, Controller가 View의 Lifecycle까지 관리하기 때문에 분리가 어렵다.
→ 재사용성이 떨어지고, 유닛 테스트가 어려움. 대부분의 코드가 controller에 밀집.
→ Massive View Controller → 프로젝트 규모가 커질수록 유지보수하기 힘듬.
출처
iOS 개발 - MVC 패턴과 UIKit의 ViewController
Notion
