MVC, MVP, MVVM, MVI

---

MVC 

MVC의 구성요소로는 Controller, Model, View 가 있다.

Controller, Mode, View의 관계도

 

이러한 로직으로는 Model에 대한 테스트는 쉽지만, View와 Controller의 테스트는 복잡해진다. 이때,

최소한 비즈니스 로직이라도 분리되면 테스트 가능성이 열리고, View가 아닌 로직에 대한 테스트가 가능해진다.

 

MVP : MVC의 문제 해결방안

 

MVC의 한계를 해결하기 위해 나온 개념이다. MVP 패턴에서는 MVC의 Controller 역할을 View에서 처리한다. 로직을 분리하고, Model에 대한 직접 접근 역시 고리를 끊었다.

 

안드로이드 액티비티의 패턴

액티비티(Activity)는 View로 분리할 수 있다. (View는 Activity와 xml로 분리해 설명할 수 있기 때문이다.)

MVP의 Presetner와 MVVM의 ViewModel의 역할?

둘 다 비즈니스 로직을 처리한다. 이 경우 View와 1:1 관계로 결합되었는가 아님 유연하게 필요한 통지만 받을 수 있는가의 차이가 있다. MVP와 MVMM의 핵심은 코드 분리와 함께 유닛 테스트도 동반되어야 한다. 유닛 테스트는 Robolectric을 활용하면 해결이 된다.  또한, 테스트를 하지 않더라도 테스트가 가능한 형태여야 한다. 이때의 테스트는 Mockito를 가지고서도 테스트가 가능해야 한다.  또한 모든 함수는 테스트 가능해야 한다. 추가적으로, View 로직에 대한 검증을 실시해야 한다.

 

• 코드의 분리
• 재사용 가능한 코드의 가능성
• 테스트를 통해 로직에 대한 오류 예측

왜 코드를 이렇게 분리해야할까 에 대한 고민은 중요하다.

 

MVVM

MVVM은 1:1관계를 요구하는 MVP에 비해 유연하다. 클린 아키텍처인 UseCase를 활용하는 경우에는 View와 ViewModel을 공통화하지 않는 특징이 있다. 하지만 1개의 View와 1개의 View Model를 사용하는 경우를 살펴보자. View는 공통화를 하고, ViewModel은 이 View 내용을 포함해 뷰 로직을 처리한다. 이때, xml로 작성하는 경우에는 커스텀 레이아웃을 만들어야 하는데 Compose로 하면 매우 간단해질 수 있다. MVVM을 이용하면 1:1 형태의 뷰와 뷰 모델까지 만들 수 있다.

1:1 형태의 MVVM 뷰가 많아질수록 좋은데 단순히 조립하면 뷰가 하나 나오고, 그에 다른 로직까지 처리되기 때문이다. 

 

MVI

 

MVI라면 최소한 View가 스스로 모든 상태를 파악할 수 있어야 한다. MVVM에서 공통화 시켜둔 코드가 많아지면 MVI 일부라고 볼 수 있다.