[Android] 디자인 패턴 - MVC/MVP/MVVM

 

MVC/MVP/MVVM 패턴 학습

디자인 패턴을 사용하는 이유는 이러한 패턴 없이 자유롭게 코드를 작성하게 되면 규모가 커질수록 하나의 액티비티가 복잡하고 비대해져 문제가 생길 수 있고, 유지보수 즉면에서도 어려움이 있을 수 있고, 액티비티 특성상 LifeCycle에 따른 영향도 있을 것이며 데이터도 안전하게 다루지 못하기 때문이다.
따라서 LifeCycle의 영향, 코드의 복잡, 비대에 대한 영향, 앱 사용 환경 등 다양한 이유와 문제점을 바탕으로 좀 더 안전하고 깔끔한 개발을 위해 아키텍처 패턴이 생겨났다.

 

MVC(Model View Controller)

MVC 패턴에서 사용자 입력은 컨트롤러(Activity)를 통해 들어오며 컨트롤러는 모델과 상호작용을 통해 View(xml)을 업데이트한다.
이 때 뷰는 모델을 참조한다.

특징

- Controller(Activity)
앱을 묶어주는 접착제 역할(Activity/fragment)
사용자에게 입력을 받아 해당하는 모델을 선택하여 처리한다.
모델의 데이터 변화에 따라 뷰를 선택한다.

- View(xml)
사용자에게 제공되는 UI
UI, 앱과의 상호작용에서 컨트롤러와의 통신
사용자가 어떤 액션을 하든 무엇을 해야할지 모름

- Model
데이터 + 상태 + 비지니스 로직
View나 컨트롤러에 묶이지 않아 재사용 가능

 

장단점

- 장점
Model과 View를 분리
Model의 비종속성으로 재사용 가능
구현하기 가장 쉬움

- 단점
컨트롤러가 View에 결합되며, View의 확장이 될 수 있음
View와 Model 사이의 업데이트를 위해 직/간접적으로 참조 이로 인해 서로간의 의존성을 완벽하게 없앨 수 없음
규모가 커질수록 컨트롤러에 많은 코드가 쌓여 비대화 문제 발생

 

MVP(Model View Presenter)

Model과 View는 MVC의 개념과 동일
Model과 View를 분리시키기 위해 사이에 Presenter라는 개념을 추가
사용자 입력은 View를 통해 들어옴
View는 이러한 이벤트를 Presenter로 전달하고 Presenter는 Model과의 상호작용을 통해 View에게 업데이트할 내용을 전달
내용을 전달받은 View가 최종적으로 업데이트됨
Presenter와 View는 1:1 관계 유지

 

특징

- Presenter
Model과 View의 상호작용 관리
컨트롤러와 본질적으로는 동일하지만 View에 연결되지 않는 단순 Interface
View에게 표시할 내용만 전달

- View
사용자에게 제공되는 UI
Activity/fragment가 View의 일부로 간주
사용자의 입력을 받고 이벤트를 Presenter로 전달

-Model
MVC와 동일

 

장단점

- 장점
Model과 View의 의존성이 존재하지 않는다.
Model은 Presenter의 요청만을 수행한다.

- 단점
규모가 커짐에 따라 Presenter도 추가 비지니스 로직이 모여 비대화됨
MVC에 비해 필요한 클래스 수가 증가
View와 Presenter의 1:1 관계로인한 의존성 증가

MVP는 Presenter가 Model과 View 사이에서 관리를 해주기 때문에 Model과 View 사이의 의존성이 없다.
그러나 규모가 커지면 Presenter와 View의 1:1 관계로 인해 의존성이 강해지는 문제점이 있다.
이러한 문제를 해결하기 위해 MVVM 아키텍처 패턴이 생겨났다.

MVVM

Model과 View는 MVC 개념과 동일
MVP와 마찬가지로 View와 Model을 분리시키기 위해 ViewModel이라는 개념이 들어옴
View는 사용자 입력에 따른 자신이 이용할 ViewModel을 선택해 바인딩하여 업데이트를 받는다.
ViewModel과 Model이 상호작용하여 Model이 변경되면 ViewModel을 이용하는 View가 자동으로 업데이트됨
View와 Model 사이의 의존성이 없고, MVP처럼 View와 ViewModel이 1:1관계가 아닌 독립적이기 때문에 둘 사이의 의존성이 없음

장단점

- 장점
View에 대한 의존성이 전혀 없으므로 유닛 테스트에 용이
중복되는 코드를 모듈화 할 수 있음

- 단점
ViewModel의 설계가 어렵다
View에 대한 처리가 복잡해질수록 ViewModel이 거대해짐
상대적으로 View는 아무 역할도 하지 않음
ViewModel이 또다른 형태의 액티비티 클래스 구현으로 변질될 우려가 있다.

특징

- ViewModel
View를 나타내주기 위한 Model + View의 로직 담당
View와 독립적
UI 관련 데이터 보관 및 관리
Model이 변경되면 해당 ViewModel을 사용하는 View가 자동으로 업데이트

- View
사용자에게 제공되는 UI
사용자의 입력을 받고 이벤트를 자신이 사용할 ViewModel로 전달

- Model
MVC와 동일

MVVM 패턴은 액티비티의 LifeCycle에 영향을 받지 않고 ViewModel의 인스턴스가 유지되면서 데이터를 안전하게 다룰 수 있다.
그러나 View가 할 일을 ViewModel이 대신하기 때문에 ViewModel에 로직들이 모이고 또다른 View 클래스를 생성한 꼴이 될 수 있으므로 유의하며 구현해야한다.

유닛 테스트(Unit test) 
컴퓨터 프로그래밍에서 소스 코드의 특정 모듈이 의도된 대로 정확히 작동하는지 검증하는 절차.
즉, 모든 함수와 메소드에 대한 테스트 케이스를 작성하는 절차를 말함.

 

참고 링크

• https://gitsu.tistory.com/38

MVC, MVP, MVVM 을 예제와 함께 알아보자 - android