[디자인패턴] aspect ratio image
디자인 패턴
MVC
- MVC 패턴은 Model + View + Controller를 합친 용어입니다.
- 구조
- Model: 애플리케이션에서 사용되는 데이터와 그 데이터를 처리하는 부분
- View: 사용자에서 보여지는 UI 부분입니다
- Controller: 사용자의 입력을 받고 처리하는 부분
- 동작
- 사용자의 action들은 controller에 들어오게 됩니다.
- controller는 사용자의 action을 확인하고, model을 업데이트 합니다.
- controller는 model을 나타낼 view를 선택합니다.
- view는 model을 이용하여 화면을 나타냅니다
- 특징
- controller는 여러개의 view를 선택할 수 있는 1:n 구조입니다. controller는 view를 선택할 뿐 직접 업데이트 하지 않습니다.(view는 controller를 알지 못한다)
- 장점
- MVC 패턴의 장점은 널리 사용되고 있는 패턴이라는 점에 걸맞게 가장 단순합니다. 단순하다 보니 보편적으로 많이 사용되는 디자인 패턴입니다.
- 단점
- MVC 패턴의 단점은 view와 model 사이의 의존성이 높다는 것입니다. view와 model의 높은 의존성은 어플리케이션이 커질수록 복잡해지고 유지보수가 어렵게 만들 수 있습니다.
MVP
- MVP 패턴은 Model + View + Presenter를 합친 용어입니다. model과 view는 MVC 패턴과 동일하고, controller 대신 presenter가 존재합니다.
-
구조
- Model: 어플리케이션에서 사용되는 데이터와 그 데이터를 처리하는 부분입니다.
- View: 사용자에게 보여지는 UI 부분입니다.
- Presenter: view에서 요청한 정보로 model을 가공하여 view에 전달해 주는 부분입니다. view와 model 붙여주는 접착제 역할
- 동작
- 사용자의 action들은 view를 통해 들어오게 됩니다.
- View는 데이터를 Presenter에 요청합니다.
- Presenter는 model에게 데이터를 요청합니다.
- model은 presenter에서 요청받은 데이터를 응답합니다.
- presenter는 view에게 데이터를 응답합니다.
- view는 presenter가 응답한 데이터를 이용하여 화면을 나타냅니다.
- 특징
- presenter는 View와 model의 인스턴스를 가지고 있어 둘을 연결하는 접착제 역할을 합니다. presenter와 view는 1:1관계입니다.
- 장점
- MVP 패턴의 장점은 view와 model의 의존성이 없다는 것입니다. MVP 패턴은 MVC 패턴의 단점이었던 view와 model의 의존성을 해결했습니다.
- 단점
- MVC 패턴의 단점인 view와 model 사이의 의존성은 해결되었지만, view와 presenter 사이의 의존성이 높게 가지게 되는 단점이 있습니다. 어플리케이션이 복잡해 질 수록 view와 presenter 사이의 의존성이 강해지는 단점이 있습니다.
MVVM
- MVVM 패턴은 Model + View + View Model을 합친 용어입니다. Model과 View는 다른 패턴과 동일합니다.
-
구조
- Model: 어플리케이션에서 사용되는 데이터와 그 데이터를 처리하는 부분입니다.
- View: 사용자에서 보여지는 UI 부분입니다.
- View Model: View를 표현하기 위해 만든 Model입니다. View를 나타내 주기 위한 Model이자 View를 나타내기 위한 데이터 처리를 하는 부분입니다.
- 동작
- 사용자의 action들은 view를 통해 들어오게 됩니다.
- view에 action이 들어오면, command 패턴으로 view model에 action을 전달합니다.
- View model은 model에게 데이터를 요청합니다.
- model은 view model에게 요청받은 데이터를 응답합니다.
- View model은 응답 받은 데이터를 가공하여 저장합니다.
- view는 view model과 Data Binding하여 화면을 나타냅니다.
- 특징
- MVVM 패턴은 Command 패턴과 Data Binding 두 가지 패턴을 사용하여 구현되었습니다.
- Command 패턴과 Data Binding을 이용하여 view와 view model 사이의 의존성을 없앴습니다.
- View model과 view는 1:n 관계입니다.
- 장점
- MVVM 패턴은 view와 model 사이의 의존성이 없습니다. 또한 Command 패턴과 Data Binding을 사용하여 view와 view model 사이의 의존성 또한 없앤 디자인 패턴입니다. 각각의 부분은 독립적이기 때문에 모듈화 화여 개발할 수 있습니다.
- 단점
- MVVM 패턴의 단점은 view model의 설계가 쉽지 않다는 점입니다.
Viper
- View + Interactor + Presenter + Entities + Router를 합친 용어입니다.
-
구조
- View: Presenter의 요청대로 디스플레이하고, 사용자의 입력을 Presenter로 보내는 작업을 합니다.
- Interactor: Use case에 따라서 Entity 모델 객체를 조작하는 로직을 담고 있습니다.
- Presenter: Interactor로부터 데이터를 가져오고, View로 보내기 위해 데이터를 준비하여 언제 View에 보여줄지를 결정합니다.
- Entity: 모델 객체
- Router(Wire frame): 화면 전환을 담당하며, Presenter가 언제 화면을 전환해야 하는지를 안다면, Wire frame은 화면 전환을 어떻게 해야하는지를 알고 있습니다.
- 특징
- MV(X)와는 다른 카테고리로 MVC 패턴을 대체하기 위해 만들어진 패턴입니다.
- 데이터 상호작용 로직을 담당했던 Model의 기능은 Viper에서는 Interactor와 data structure인 Entities로 나뉘어졌다.
- Controller / Presenter / View Model의 오직 UI 표시 의무만 Viper의 Presenter로 이동했고, 데이터 변환 기능은 이동하지 않았다.
- Viper에서는 iOS application에 적용할 적절한 라우팅 방식을 고르는 문제가 있다. MV(X) 패턴 에서는 이런 이슈를 다루지 않는다.
- 장점
- 각 도메인의 역할이 명확하게 구분된다.
- 모듈을 작게 역할을 분명히 하기에 대규모 프로젝트에 적합하다.
- 단점
- 유지보수 비용이 많이 들어간다.
- 모델 설계가 쉽지않다.
- 많은 파일을 생성한다.
참고
- Command 패턴: https://ko.wikipedia.org/wiki/%EC%BB%A4%EB%A7%A8%EB%93%9C_%ED%8C%A8%ED%84%B4
- Data Binding: https://en.wikipedia.org/wiki/Data_binding