[iOS] MVC (Model-View-Controller)

MVC란?

MVC는 다음 3가지 주요 객체로 구성된 소프트웨어 개발 패턴이다.

Model

애플리케이션과 관련된 데이터를 캡슐화하고, 해당 데이터를 조작하고 처리하는 로직과 계산을 정의한다.

View

앱의 뷰로, 애플리케이션 내에서 사용자가 볼 수 있는 객체를 말한다.

Controller

delegate 패턴을 통해 하나 이상의 애플리케이션 View 객체와 하나 이상의 Model 객체 사이의 중개자 역할을 한다.

 

Model, View, Controller은 서로 의존하지 않고 Loosely Coupled 되어있다. 이는 즉 Model, View, Controller가 서로 독립적으로 작동한다는 의미로, 코드 구성이 간단하고 이해하기 쉬우며 유지보수가 쉬워진다. 모델 코드를 변경하지 않고도 뷰의 버그를 수정할 수 있다.

 

 

Model-View-Controller 동작 순서

1️⃣ View가 사용자로부터 입력 받음

2️⃣ View의 이벤트를 Controller에게 알림

3️⃣ Controller는 Model에게 데이터 요청

4️⃣ Model은 Controller에게 요청받은 데이터 전달

5️⃣ Controller는 View에게 표시할 내용 전달

6️⃣ View는 Controller로부터 받은 정보를 토대로 View에 표시

 

1. Model

• 애플리케이션과 관련된 데이터를 캡슐화하고, 해당 데이터를 조작하고 처리하는 로직과 계산을 정의한다.
• 하나의 Model 객체는 다른 Model 객체와 1:1 또는 1:다 대응 관계를 맺을 수 있다.
• Model 객체는 데이터를 사용자에게 제공하거나 사용자가 이를 편집할 수 있는 View 객체에 명시적으로 연결되어서는 안된다. 즉, 사용자 인터페이스나 표시 문제와 관련이 없어야 한다.
• persistence, model objects, parsers, managers, networking code 등이 존재한다.
  • Network Code
    • 전체 앱의 네트워크 통신에는 하나의 클래스만 사용하는 것이 좋다.
    • 이를 통해 HTTP 헤더, 응답과 에러 처리 등의 모든 네트워크 요청에 공통되는 개념을 쉽게 추상화할 수 있다.
  • Persistence Code
    • 데이터를 데이터베이스나 Core Data 또는 장치에 데이터를 저장할 때 사용한다.
  • Parsing Code
    • 네트워크 응답을 파싱하는 객체를 모델에 포함시켜야한다.
    • Swift 모델 객체에서는 JSON 인코딩/디코딩을 사용하여 파싱할 수 있는데, 이렇게 하면 네트워크 계층이 모델 객체의 세부 사항을 알 필요가 없다.
  • Managers and abstraction layers/classes
    • 일반적으로 다른 클래스 간의 접착제 역할을 하는 전형적인 “관리자” 객체가 있다.
    • 하위 레벨의 API에 대한 wrapper 역할을 할 수도 있다. iOS의 키체인 wrapper, notification에 도움이 되는 클래스, Health Kit을 사용하는 데 도움 된다.
  • Data sources and delegates
    • 모델 객체가 테이블뷰나 컬렉션뷰와 같은 다른 컴포넌트의 data source 또는 delegate가 되는 경우는 드물다.
  • Constants
    • 상수를 사용하는 것이 좋다.
  • Helpers and extensions
    • 프로젝트에서 string, collection 등의 기능을 확장하는 메소드를 추가하는 경우가 많은데, 이 또한 모델로 간주한다.

💡 데이터를 생성하거나 수정하는 뷰 계층에서의 사용자 작업은 Controller 객체를 통해 전달되고 Model 객체를 생성하거나 업데이트한다. Model 객체가 변경되면 (예: 네트워크 연결을 통해 새 데이터가 수신됨) Controller 객체에 통보하여 적절한 View 객체를 업데이트한다.

2. View

• 앱의 뷰로, 애플리케이션 내에서 사용자가 볼 수 있는 객체를 말한다.
• 자신이 보여지는 방법을 알고 있고 사용자 액션에 응답할 수 있다. 즉, 사용자가 앱과 상호작용할 때 뷰 계층과 상호 작용한다.
• 도메인별 로직을 포함하지 않기 때문에 재사용할 수 있다.
  • UILabel의 경우, 화면에 텍스트를 표시하는 뷰이며 재사용 및 확장이 가능하다.
• View 객체의 주요 목적은 애플리케이션의 Model 객체의 데이터를 보여주고 해당 데이터를 편집할 수 있도록 하는 것이다. 그럼에도 불구하고, View 객체는 MVC 애플리케이션의 Model 객체와는 일반적으로 분리된다. 주소록을 예를 들면 전화번호 및 정보가 보이는 화면들을 말한다.

View 체크리스트

✔️ 모델 계층과 상호작용하는가?

✔️ 비즈니스 로직이 포함되어 있는가?

✔️ UI와 관계 없는 조작을 시도하는가?

 

위 질문들 중 하나라도 해당하는 것이 있다면, 코드를 리팩토링하는 것이 좋다.

💡 View 객체는 애플리케이션의 Controller 객체를 통해 Model 데이터의 변화를 학습하고, 사용자의 변경 사항(예: 텍스트 필드에 입력된 텍스트)을 Controller 객체를 통해 애플리케이션의 Model 객체에 전달한다.

3. Controller

• 컨트롤러는 delegate 패턴을 통해 하나 이상의 애플리케이션 View 객체와 하나 이상의 Model 객체 사이의 중개자 역할을 한다.
• Controller 객체는 View 객체가 Model 객체의 변경사항을 인지할 수 있도록 하고, 그 반대의 경우도 가능하도록 하는 매개체가 된다.
• 도메인별 규칙과 관련된 경우가 많기 때문에 앱에서 가장 재사용성이 적은 부분이다.
• 모델 객체의 모든 요소를 사용하여 앱의 정보 흐름을 정의한다.
• 이상적인 시나리오에서는 컨트롤러 엔티티가 다루고 있는 구체적인 뷰를 알 수 없다. 대신, 포로토콜을 통해 추상 타입과 통신한다.
  • 예를 들면 UITableView가 UITableViewDataSource 프로토콜을 통해 데이터와 통신하는 방법이 있다.
• Controller 객체는 애플리케이션의 설정 및 조정 작업을 수행하고, 다른 객체들의 생명 주기(Life cycle)를 관리하기도 한다.
• 시작, 데이터 로드 트리거, UI 상호 작용 처리, UI와 모델 간의 조정 등을 목적으로 하기 때문에 많은 테스트를 수행하지 않는다.
• Cocoa Touch 프레임워크는 Coordinating Controller, View Controller (iOS), Mediating Controller (OS X)의 세 가지 주요 컨트롤러 유형을 제공한다.

Controller 체크 리스트

✔️ persistence와 network 중 어떤 것에 먼저 접근해야 하는가?

✔️ 얼마나 자주 앱을 갱신해야하는가?

✔️ 다음 화면은 무엇이며, 어떤 상황에서 표시되어야 하는가?

✔️ 앱이 백그라운드로 넘어가면 무엇을 정리해야 하는가?

✔️ 사용자가 셀을 탭한 다음의 작업은 무엇인가?

💡 Controller 객체는 View 객체에서 발생된 사용자 동작 및 의도 (사용자의 버튼 클릭 또는 텍스트 입력)를 해석하고 새로운 데이터 또는 변경된 데이터를 Model 객체로 전달한다. Model 객체가 변경되면 Controller 객체가 새 모델 데이터를 표시할 수 있도록 새 모델 데이터를 View 객체에 전달한다.

3-1. Coordinating Controllers

Coordinating Controller는 애플리케이션 전체 또는 일부 기능을 감독하고 관리한다. 애플리케이션별로 다른 로직이 각 애플리케이션에 주입(injected)되는 장소라고 할 수 있으며, 그 기능은 다음과 같다.

• 델리게이션(delegation) 메시지에 응답하고 알림(notifications)을 관리
• 사용자가 버튼과 같은 컨트롤을 탭하거나 클릭함에 따라 전송되는 동작 메시지(action message)에 응답
• 객체 간의 연결을 확립 또는 애플리케이션 실행 시와 같은 기타 설정 작업 수행
• 소유한 "owned" 객체의 생명 주기 관리

iOS 애플리케이션에서는 View Controller가 Coordinating Controller의 역할을 겸하는 경우가 많다.

3-2. View Controllers

• UIKit에서 View Controller는 콘텐츠를 화면에 표시하는 뷰를 관리하며, 해당 뷰에 대한 참조(reference)를 유지하고, View Controller는 이 뷰의 표시(presentation)와 후속 뷰로의 전환(transition)을 관리한다. 내비게이션 바, 탭 바 그리고 이와 관련된 모든 프레젠테이션 동작은 View Controller 객체에 의해 관리되고 구현된다. 또한, Modal View를 표시하고 메모리 부족 경고에 응답하며 기기의 방향(orientation)이 변경될 때 뷰를 회전시킬 수 있다.
• iOS의 View Controller는 UIViewController의 하위 클래스의 인스턴스이다. UIKit은 UITableViewController와 같은 여러 특수 목적의 UIViewController 하위 클래스를 제공한다. Controller가 Model과 View 간에 데이터를 중개하도록 하려면 반드시 프레임워크의 View-Controller 클래스(예 : UIViewController, UITableViewController 등)를 확장해야한다. View Controller는 여러 가지 프레임워크 객체에 대한 위임자 또는 데이터 원본 객체인 경우가 많다.

 

MVC 장점

• Loosely Coupled - 느슨한 결합
• Removes unnecessary dependencies - 불필요한 종속성 제거
• Reusable without modification - 수정 없이 재사용 가능
• Code reuse - 코드 재사용
• Extendable code - 확장 가능한 코드
• High Cohesion - 높은 응집력
• Easier to maintain or modify - 유지보수 및 수정이 용이
• Supports multiple views - 여러 뷰 지원
• Each part can be tested independently (Model, View, Controller) - 개별적으로 테스트 가능

MVC 한계

• 애플리케이션의 규모가 커지면 다수의 뷰와 모델이 하나의 컨트롤러에 연결되는 상황이 발생할 수 있다. 이런 경우, 컨트롤러가 불필요하게 커지게 되는데 코드 분석/수정과 테스트가 힘들어지고, Model과 View가 복잡하게 엮여있어 유지보수가 어렵게 된다. 이런 컨트롤러를 Massive-View-Controller라고 한다.
• 이를 개선하기 위해서 다양한 패턴 (MVP, MVVM 등)이 파생되었다.

 

참고 링크

Model-View-Controller

Model-View-Controller (MVC) in iOS - A Modern Approach

MVC-Architecture-in-5-minutes