아키텍쳐가 중요한 이유?
: 수많은 일을 수행하는 거대한 class를 디버그할 때 버그를 찾고 고치기 힘들기 때문입니다.
- 데이터가 UIVIewController에 바로 저장됨
- UIVIew가 거의 아무것도 하지 않음
- Model이 빈 데이터 구조
- Unit Test로 아무것도 하지 못함
( Unit test : 프로그램의 기본 단위인 모듈을 테스트하는 것, 코드 퀄리티 개선)
등등인 경우에 포함된다면 아키텍쳐를 살펴봐야합니다..
좋은 아키텍쳐의 특징
1) 분배
: 복잡성을 제거하는 가장 쉬운 방법은 개체간에 책임을 나누는 것입니다.
(각각의 객체들은 구체적이고 명확한 역할을 가져야합니다.)
2) Testability(테스트 가능)
: 테스트를 통해 개발자는 앱이 사용자 기기에 들어가기 전에 이슈를 발견해야합니다.
3) 사용이 용이하고 유지보수가 저렴
: 코드가 적을 수록 버그가 적습니다.
iOS의 아키텍쳐 패턴들
MVC / MVP / MVVM / VIPER 등
(MVC, MVP, MVVM 은 앱의 entity를 세 카테고리로 나눕니다.)
- Model
: 어플에서 사용되는 데이터와 데이터를 처리하는 부분입니다.
- View
: presentation 계층(GUI = Graphical User Interface)를 담당합니다. ios에서는 UI로 시작하는 모든 것을 일컫습니다.
- Controller, Presenter, ViewModel
: 모델과 뷰 사이의 중재자로
뷰에서 수행된 사용자의 입력(action)에 반응하여 모델을 변화시키며 뷰를 업데이트 시킵니다.
Entity를 나누면 얻을 수 있는 효과
- 앱을 더 잘 이해할 수 있습니다.
- View 와 Model을 재사용할 수 있습니다.
- 독립적으로 테스트 할 수 있습니다.
1. 애플의 MVC
- 1) 유저가 controller에 액션을 보내면
2) controller가 model을 업데이트하고
3) model의 변화를 controller에 알리면
4) controller가 view를 업데이트 합니다.
- Controller가 View와 Model 사이를 연결 시켜주기 때문에 View와 Model은 서로에 대해 알 필요가 없습니다.
이 구조에서 Controller가 가장 적게 재사용됩니다.
따라서 특이한 로직들은 model이 아닌 controller에 넣어야합니다.
1.1 현실적인 Cocoa MVC
- Cocoa MVC는 사용자가 거대한 Viewcontroller를 작성하게 합니다.
View의 라이프사이클과 Controller가 너무 연관되어 있어 분리하기 어렵기 때문입니다.
여기서 View의 대부분의 일은 Controller에게 액션을 보내는 것입니다.
이 ViewController는 완전한 분리가 어렵기 때문에
결국 controller가 모든 것의 delegate와 datasource가 되고controller가 무거워집니다.
애플의 MVC는 단순하고 보편적이라 빠르게 개발을 해야할 때 적절합니다.
2. MVP (passive view variant = 수동적인 view 변화)
- Apple MVC와 같아 보이지만 다릅니다.
MVC에서는 view와 controller가 딱 붙어 있지만
MVP에서 중간 역할을 하는 presenter는 view controller에 아무런 영향을 끼치지 않습니다.
따라서 presenter에는 레이아웃과 관련된 코드가 없고 view의 데이터와 상태 갱신만 합니다.
iOS에서 MVP는 테스트하기엔 좋지만 코드가 길어진다는 단점이 있습니다.
3. MVVM
: MV(X)종류 중 가장 최근에 나온 좋은 아키텍쳐
- 사용자의 이벤트를 뷰가 뷰모델에 전달 -> 뷰모델에서 모델 업데이트
MVP와의 차이점
- MVVM은 viewcontroller를 view처럼 취급
- View와 model 사이에 결속력 없음
- View와 view model 사이에 binding있음
View model이란 view로부터 독립된 UIKit입니다.
Data binding과 command패턴을 사용해서 의존성 완전히 제거합니다.
View model은 model을 업데이트하고 변경을 호출받습는다.
MVVM은 View입장에서 바인딩을 하기 때문에 view를 갱신할 때 추가적인 코드 필요하지 않습니다. 또한 테스트에도 용이합니다
4. VIPER
- Interactor : entity의 새 인스턴스나 서버로부터 패칭하는 것과 같이 데이터- - (entity)나 네트워크와 관련된 로직을 포함합니다.
- Presenter : Interactor의 매서드를 호출하는 UI관련 로직을 포함합니다.
- Entity : 데이터 오브젝트들을 포함합니다.(데이터 접근은 Interactor에서)
- Router : viper 모듈들 간의 연결을 담당합니다.
MV(X)와 비교해보면, 책임을 분배하는데에 차이가 있음을 알 수 있습니다.
- Model(데이터처리) 로직이 interactor에 들어감
- Controller/presenter/viewmodel의 UI표현이 presenter로 들어감
VIPER는 router가 처리하는 네비게이션 역할을 처음으로 명시적으로 표시한 아키텍쳐입니다.
- 결론
책임 분배 (VIPER > MVVM > MVP > MVC)
- MVC : View, controller는 딱 붙어있고 view와 model은 분리되어있음
- MVP : Presenter와 model이 대부분의 일 처리함. View는 아무것도 하지 않음
- MVVM : MVP의 view 보다 MVVM의 view가 더 많은 일 함.
- VIPER : 가장 잘 분배
Testability (VIPER > MVVM = MVP > MVC)
- MVC : Model만 테스트 가능
- MVP : 좋음. View가 재사용가능하기 때문에 로직 테스트 가능
- MVVM : View model과 view는 서로를 모르기 때문에 테스트 가능
- VIPER : 분배 잘 되어 있기때문에 가장 테스트하기 좋음
사용성 (MVC > MVVM > MVP > VIPER)
- MVC : 다른 패턴에 비해 코드 적게 듬, 초보자도 쉽게 접근 가능
- MVP : MVC에 비해 코드 많이 듬
- MVVM : 바인딩 사용하면 MVP보다는 코드 적게 필요
- VIPER : 수많은 클래스를 작성해야해서 유지보수 비용 두 배정도 든다
세 특징 모두 우세한 아키텍쳐는 없기 때문에 개발자가 필요에 맞게 적절한 구조를 선택해서 쓰면 된다. 한 앱에서 여러 구조를 섞어 쓰는 것도 괜찮음
