MVC, MVVM, MVP, VIPER, VIP를 알아봅시다.

안녕하세요. 리양입니다 :)

요즘 코로나로 전국적으로 이슈네여 ㅠ ㅠ 다들 몸 조심하시길 바랍니다.

 

요즘은 패턴에 대해 공부를 하기 시작했어여.

어떻게 layer를 좀 더 잘 나누어서 각 역할을 수행할 수 있게 할까를 고민하기 시작했습니다.

그래서 iOS에서 많이 알려진 mvc, mvvm, mvp, viper, vip를 소개할까 합니다.

시작할게요!

---

MVC

위의 그림은 일반적인 MVC패턴의 모습입니다.

Controller가 다리 역할이 되어 View의 입력을 Model에 반영하고 Model의 변화에 맞게 View를 갱신합니다.

역할 및 동작원리

• Model
  • 프로그램에서 사용되는 실제 데이터 및 데이터 조작 로직을 처리하는 부분
• View
  • 사용자에게 제공되어 보여지는 UI
• Controller
  • 사용자의 입력을 받고 처리하는 부분

1. Controller로 사용자의 입력이 들어옵니다.
2. Controller는 Model을 데이터 업데이트 및 불러오고
3. Model은 해당 데이터를 보여줄 View를 선택해서 화면에 보여주게 됩니다.

하지만, 실제 Apple에서의 MVC 작동 원리는 다르게 동작합니다.

View와 Controller가 강하게 연결되어 있기 때문에 ViewController가 거의 모든 일을 하게 되어있습니다.

그래서 Model만 따로 만들어집니다.

장점

1. 설계가 단순하기 때문에 가장 쉽고 빠르게 개발이 가능함
2. 애플에서 MVC를 지향하고 있기 때문에 기본 LifeCycle에 맞는 개발이 가능

단점

1. View와 Model이 서로 의존적이라는 점
2. Controller의 역할이 방대해져서 모듈화하는 부분이 무의미해질 수 있습니다.
3. 대규모 프로젝트에는 방대해지기 때문에 비적합합니다.

---

MVP

MVC에서 Controller를 제거하고 Presenter를 구성했습니다.

→ 그 이유는 View와 Model의 의존성을 없애기 위해서 Presenter를 존재하게 했습니다.

역할 및 동작원리

• Model
  • 프로그램에서 사용되는 실제 데이터 및 데이터 조작 로직을 처리하는 부분
  • dmoain Data또는 데이터를 다루는 data acces layer를 담당하는 카테고리
• View
  • 사용자에게 제공되어 보여지는 UI
• Presenter
  • View에서 요청한 정보를 Model로 부터 가공해서 View로 전달하는 부분
  • Presenter에서 어떠한 layout code도 담겨져 있지 않다.
  • View의 데이터와 상태를 Updating 해주는 역할을 맡았다.

View와 Model은 서로를 알 필요가 전혀 없다.!

1. View로 사용자의 입력이 들어옵니다.
2. View는 Presenter에 작업 요청
3. Presenter에서 필요한 데이터는 Model에 요청
4. Model은 Presenter에 필요한 데이터를 응답
5. Presenter는 View에 데이터를 응답
6. View는 Presenter로부터 받은 데이터로 화면에 보여줌

장점

1. 대부분의 책임을 Presenter와 Model이 가지고 있어 View는 출력만 하는 역할을 한다.
2. Test할 때 View에 대한 책임이 분리되어 있기에 각 요소들을 독립적으로 테스팅할 수 있다.

단점

1. View와 Presenter가 1:1 관계
2. MVC에 비해서는 코드가 더 많이 늘어나 진다.

---

MVVM

Controller를 빼고 ViewModel을 추가한 패턴입니다.

역할 및 동작원리

• View
  • iOS는 ViewController까지 View가 됩니다.
  • 사용자가 보여지는 View를 생각하시면 됩니다., 유저인터렉션을 받는 역할, 인터랙션을 받을 시 ViewModel에게 명령을 내립니다.
• ViewModel
  • View를 표현하기 위해 만들어진 View를 위한 Model
  • View와는 Binding을 하여 연결후 View의 액션을 받고 View를 업데이트도 됩니다.
  • ex) textView에 보여줄 내용을 담당하는 함수 등, View에서 변화가 일어나는 ViewController의 역할을 담당
• Model
  • 데이터, 비즈니스 논리, 서비스 클라이언트 등으로 구성
  • 실제적 데이터

1. View에 입력이 들어오면 ViewModel에 명령을 합니다.
2. ViewModel은 필요한 데이터를 Model에 요청 합니다.
3. Model은 ViewModel에 필요한 데이터를 응답 합니다.
4. ViewModel은 응답 받은 데이터를 가공해서 저장 합니다.
5. View는 ViewModel과의 Data Binding으로 인해 자동으로 갱신 됩니다.

위와 같이 UIImage 혹은 View에 값을 수정하는것을 ViewModel 에서 하면 안됩니다.혹은 View의 lifecycle 에 의존적이거나, (viewDidLoad, viewDidAppear, …)View를 레퍼런스로 받아 뷰의 값을 직접 변경하는 일도 UI와 관련된것으로 간주합니다.

장점

1. View와 Model이 서로 전혀 알지 못하기에 독립성을 유지할 수 있다.
2. 독십성을 유지하기 때문에 효율적인 유닛테스가 가능하다.
3. view와 viewModel을 바인딩하기 때문에 코드의 양이 작다.
4. View와 ViewModel의 관계는 N: 1 이다.
5. Unittest 하기 좋다. 이유는 ViewModel에는 UIKit관련 코드가 없기 때문이다. , Controller와의 의존성도 없기 때문입니다.

단점

1. 간단한 UI에서 오히려 ViewModel을 설계하는 어려움이 있을 수 있다.
2. 데이터 바인딩이 필수적으로 요구된다. 다양한 바인딩이 가능하다.
3. 복잡해질수록 Controller처럼 ViewModel이 빠르게 비대해짐
4. 표준화된 틀이 존재하지 않아 사람마다 이해가 다름

DataBinding

데이터 바인딩의 개념은 쉽게 말해 Model과 UI 요소 간의 싱크를 맞춰주는 것이라 할 수 있다(정확히 말하면 UI 데이터 바인딩이지만 iOS를 다루기 때문에 이것을 다룬다).

이 패턴을 통해 View와 로직이 분리되어 있어도 한 쪽이 바뀌면 다른 쪽도 업데이트가 이루어져 데이터의 일관성을 유지할 수 있다.

iOS에서 데이터 바인딩을 하는 방법은 다음과 같다.

• KVO
• Delegation
• Functional Reactive Programming
• Property Observer

추가) 신규, SwiftUI + Combine이 이번 iOS13부터 지원이 되면서 apple이 mvvm도 지원한다고 볼수 있습니다.

View부분을 SwiftUI로 하여 관련된 바인드를 Combine의 도움을 받아 할 수 있습니다.

---

VIPER

MV(X)의 패턴을 대체하기 위해 만들어진 패턴입니다.

역할 및 동작원리

• View
  • 사용자가 보여지는 View를 생각하시면 됩니다., 유저인터렉션을 받는 역할
  • 이벤트가 발생시 Presenter에 해당 일을 전달
  • Presenter의 요청대로 디스플레이하고 사용자 입력을 Presenter로 보내는 작업
• Presenter
  • Entity로 부터 받은 업데이트 이벤트를 실행하지만 데이터를 직접적으로 보내지는 않는다.
  • View 모델의 변경사항을 Interactor에 알린다.
  • '언제'의 타이밍을 아는 존재
  • Interactor로 부터 데이터를 가져오고 View로 보내기 위해 데이터를 준비하여 '언제' View를 보여줄지 결정
• Interactor
  • Presenter로 부터 받은 모델 변경사항에 따라 Entity에 접속하여 Entity로 부터 수신한 데이터를 Presenter로 전달
  • Use Case에 따라서 Entity 모델 객체를 조작하는 로직을 담았습니다.
• Entity
  • 객체에 구성된 부분을 Interactor에 의해 제어
  • 순수 모델 객체
• Routing
  • Wireframe이라고 불리기도함, UIWindow와 UINavigationController에서 화면간의 탐색을 위한 라우팅을 담당
  • 화면 전환을 담당, Presenter는 '언제' 화면이 전환이라면 Router는 '어떻게' 하는 지 담당

장점

1. 각 도메인의 역할이 명학하게 구분됨
2. 모듈을 작게 역할을 분명히 하기에 대규모 프로젝트에 적합함

단점

1. 설계가 여러 곳으로 난립함
2. 명확한 가이드나, 유지보수 되는 곳이 없음
3. 많은 파일들을 생성

Clean Swift(VIP)

VIP패턴은 VIPER 패턴과 디렉토리와 생성되는 클래스는 동일하지만 플로우를 다른 관점에서 보는 아키텍처

위의 그림 처럼 VIPER는 양방향으로 로직이 순환해서 순환참조에 의한 메모리 누수가 날 수 있고, 또한 하나의 액션의 기대 결과값을 위해 각 클래스의 프로토콜에 메소드를 만들어야하는 수고스러움이 있다.

그래서 이런 수고스러움을 덜고자 VIP는 닫는방향으로 로직이 순환해서 액션에 대한 결과값을 보여주는 형태이다.

역할 및 동작원리

• View
  • 스토리보드, XiB와 같은 사용자와 상호작용이 발생하는 인터페이스
• Controller
  • View를 코드에 바인딩하는 레이어, => UIViewController
• Interactor
  • Controller의 요청을 보내야하는 비지니스 로직 계층
• Presenter
  • Interactor로 부터 받은 형태를 View에 맞게 전달할 수 있게 Controller에게 전달
• Router
  • Controller에서 발생한 이벤트를 다른 user case에 전달하는 역할

1. View 가 사용자의 인터페이스를 만듭니다.
2. Controller에서 이벤트가 발생하여 모델을 요청후 Interactor를 호출
3. Interactor에서는 기본 코어 라이브러리를 호출하여 데이터를 액세스합니다.
4. Interactor에서 비지니스로직을 처리하고 결과를 다시 Presenter로 보냄
5. Presenter에서 Interactor에서 받은 결과에 대한 UI처리를 Controller에 전달 View에서 보여줌

VIPER와 다르게 액션에 대한 비즈니스 로직을 Presenter를 통하지 않고 Interactor를 요청하여 변화를 주어 단방향으로 플로우가 진행된다.

장점

1. 컴포넌트가 단단히 연결되어 있지 않아 유연하고, 확장가능하며, 유지관리가 가능하다.
2. 프로토콜로 서로 참조합니다.
3. 모든 layer가 인터페이스로 되어있기에 테스트에 용이합니다.

단점

1. layer끼리 전달할 때 request/ response 모델을 랩핑해야하는 불편함이 존재
2. 모델을 랩핑하지 않으면 컴포넌트가 결합될 수 있다.
3. 비동기 액션에 대한 처리가 별도로 필요합니다.

---

위의  다섯가지를 간략하게 알아봤습니다! 

틀린부분이나 수정이 필요하면 댓글이나 메일 부탁드립니다!

참조 url는 제가 공부를 위해 봤던 부분은 좀 더 추후 업데이트할 예정입니다 :)

---

참조

MVVM 디자인 패턴

MVVM패턴에 대하여

MVC,MVVM,MVP,VIPER 예제코드

Clean(VIP) 예제코드