MVC, MVP, MVVM ...

W·2024년 1월 17일

용어정리

목록 보기
4/6

패턴

MVC

  • Model-View-Controller

  • Model은 데이터를 의미한다.

  • Controller가 거의 대부분의 일을 다한다는 단점이 있다. (너무 비대해진다)

MVP

  • Model-View-Presenter
  • MVC패턴에서의 단점이었던 방대해진 Controller의 역할을 분리하기 위해 고안된 패턴

Presenter

  • UIKit과 관련이 없는 로직들을 수행
  • View에서 요청한 정보를 Model로부터 가공해서 View로 전달
  • Presenter 또한 방대해질수가 있다. (단점)
  • 대부분의 책임을 Presenter와 Model이 가지고 있어 View는 출력만 하는 역할을 한다.
  • Test할 때 View에 대한 책임이 분리되어 있기 때문에 각 요소들을 독립적으로 테스팅할 수 있다.
    • 유닛 테스트 가능
  • View와 Presenter가 1:1관계를 형성 → 완전히 독립되어있다고 할수 없다.
  • Presenter와 이를 구현하기 위한 Protocol의 추가로 인해 MVC패턴에 비해 코드가 더 많이 늘어나게 된다.

MVVM

내 생각을 정리해 봄

  1. Model을 ViewModel에서 프로퍼티로 갖는다.
  2. View(= ViewController) 에서는 ViewModel을 인스턴스화하여 가져다 쓴다.
  3. 값의 변경이 있게되면 View에서 ViewModel의 데이터를 재할당한다.
Ex)
class ViewController {
	private var articleListVM: ArticleListViewModel!

	self.articleListVM = ArticleListViewModel(articles: articles)
}

강의 자료

  • Model-View-ViewModel

  • SwiftUI와 RxSwift 기반 앱 개발에서 활용되는 패턴

  • Controller의 역할을 ViewModel이 대신한다.

  • View와 Model 사이에 바인딩(binding)을 통해 데이터의 변화를 자동으로 반영한다.

  • Controller의 역할을 줄이고 테스트 용이성을 높일 수 있다.

  • 단방향으로 데이터가 흐름( ↓ 실선 )

  • View와 ViewModel을 바인딩하기 때문에 코드의 양이 작다. (장점)

  • View와 ViewModel(Store)의 관계가 N:1이다.

  • 간단한 UI에서는 오히려 ViewModel을 설계하는 어려움이 있다.

  • Data Binding이 필수적으로 요구된다.

  • 복잡해질수록 MVC패턴의 Controller처럼 ViewModel이 빠르게 방대해진다. (단점)

  • 표준화된 틀이 존재하지 않아 사람마다 이해가 다르다.

MVI

  • Model- View- Intent
  • 함수형 프로그래밍에 기반한 패턴
  • 사용자의 입력을 Intent 라고 부르고, View는 Intent를 받아서 Model에 전달한다.
  • Model은 Intent에 따라 상태를 변경하고 View에게 전달한다.
  • 이 과정에서 불변성(Immutability)과 순수함수(Pure Function)를 지키기 때문에 예측이 가능하고 안정적인 앱 개발이 가능하다.
  • TCA와 유사한 형태

VIPER

  • View, Interactor, Presenter, Entity, Router(WireFrame)
  • MV종류의 패턴(MVC, MVVM, MVI)을 대체하기 위해 만들어진 패턴
  • Viper 패턴은 모듈간의 의존성을 낮추고 책임을 분리함으로써 테스트 용이성과 유지보수성을 높일 수 있다.
  • 구현하기 복잡하고 파일 수가 많아진다. (단점)

RIBs

  • Router- Interactor-Builder
  • Uber에서 개발한 패턴
  • 앱을 여러 개의 RIB이라는 독립적인 모듈로 나누고, 각 모듈은 Router,Interactor,Builder로 구성한다
  • Router는 화면전환과 데이터 전달을 담당하고 Interactor는 비즈니스 로직을 처리하며, Builder는 RIB의 생성과 의존성 주입을 담당한다.
  • 모듈 간의 의존성을 낮추고 재사용성과 유지보수성을 높일 수 있다.
  • VIPER처럼 고려해야할 모듈과 코드 파일 수가 늘어나고 사전에 요구되는 학습량이 많다. (단점)
profile
타협하는 순간 발전이 없어

0개의 댓글