이러한 디자인 패턴은 각각의 책임을 분리해주어 결합도를 낮추고, 확장, 테스트, 유지 보수에 용이하다는 장점이 있다.
MVC 디자인 패턴은 하나의 애플리케이션을 Model, View, Controller로 이루어진 3개의 측면으로 분리하여 개발하는 디자인 패턴이다.
Model
Model은 View에 표시되기 위해 필요한 데이터. Model은 비즈니스 로직을 설명하는 클래스의 집합으로 구성된다. Model은 어떻게 데이터가 변경되고 조작될 수 있는지에 관한 규칙을 정의한다.
View
View는 Controller로 부터 받은 UI 데이터를 표시하는 역할을 한다.
Controller
Controller는 사용자의 요청을 처리하는 역할. Controller는 Model을 통해 받은 데이터를 처리하거나, 결과 값을 View에 반환하는 역할을 한다. 일반적으로 View와 Model사이를 중재하는 역할.
1) 사용자의 요청이 Controller에 들어옴.
2) Controller는 요청에 맞게 Model(데이터)을 업데이트.
3) Controller에서 업데이트된 Model을 나타내줄 View를 선택.
4) View는 업데이트된 Model을 사용자에게 보여주기 위해 UI 데이터를 업데이트.
Controller가 여러개의 View를 선택할 수 있는 일대다 구조이다.
가장 단순한 패턴으로 여러 개발 분야에서 보편적으로 사용되는 디자인 패턴이지만 View와 Model사이의 의존성이 높습니다. 이는 앱이 커질수록 유지보수가 어려워집니다.
MVP 패턴은 MVC와 유사한 디자인 패턴. 이는 MVC 패턴에서 파생되었는데, 기존 Controller의 역할을 Presenter가 한다고 보면된다.
Model & View
MVC와 같은 컨셉.
Presenter
Presenter는 View를 통한 사용자의 입력을 받는다. 그 다음 Model에 도움을 받아 사용자의 데이터를 처리하고 결과를 View로 다시 전달한다. Presenter는 interface를 통하여 View와 상호작용한다.
MVP 패턴에서 Presenter는 Model을 조작할 뿐만 아니라 View를 업데이트합니다. Presenter와 View는 서로 완전히 분리되어 인터페이스를 통해 통신합니다. 이 방식은 MVC보다 단위테스트가 훨씬 쉬워집니다.
1) 사용자의 Action은 View를 통해 들어옴.
2) View는 데이터를 Presenter에 요청.
3) Presenter는 Model에게 데이터를 요청.
4) Model은 Presenter에게 요청받은 데이터를 응답.
5) Presenter가 데이터를 가공하고 다시 View에게 응답.
6) View는 Presenter로 부터 데이터를 응답받고 UI 데이터를 갱신.
앞서 말했듯이 MVP패턴은 인터페이스를 통해 통신하기 때문에 MVC의 단점으로 지적되었던 View와 Model사이의 의존성이 없다. 그러나 View와 Presenter는 1:1 구조로 의존성이 높고, 앱이 커질수록 이 의존성은 더 강해진다.
MVC 패턴의 Controller가 ViewModel로 바뀐 패턴. MVVM 패턴은 양방향 데이터 바인딩을 지원한다. 이에 따라 뷰 모델 안에 있는 데이터의 변화를 View에 전파한다. 일반적으로 옵저버 패턴을 활용하여 View Model의 변경사항을 Model에게 알리게 된다.
Model & View
MVC, MVP와 같은 컨셉.
ViewModel
ViewModel는 View 상태를 유지 및 변화시키고, View에 대한 작업의 결과로 Model을 조작하고, View에서 발생되는 이벤트를 트리거하는데 도움이 되는 메서드, 명령, 또는 다른 속성들을 노출하는 역할을 한다.
View는 ViewModel에 관한 참조를 가지고 있지만, ViewModel은 View에 관한 정보를 모른다. ViewModel과 View 사이의 일대다의 의존관계가 생기며 다수의 View는 하나의 ViewModel에 매핑될 수 있다. 이로서 ViewModel은 다수의 View에 대해 완전히 독립적이다.
1) 사용자의 Action들은 View를 통해 들어옴.
2) View에 Action이 들어오면 ViewModel에 action을 전달.
3) ViewModel은 Model에게 데이터를 요청.
4) Model은 ViewModel에게 요청받은 데이터를 응답.
5) ViewModel은 응답 받은 데이터를 가공하여 저장.
6) View는 Data Binding을 이용해 UI를 갱신.
언뜻 보기에는 MVP와 비슷한 부분이 많다. 그러나 MVP는 View와 Presenter 사이의 의존관계가 1:1로 형성되어있다면, MVVM은 View와 ViewModel사이의 관계가 1대n으로 되어있다.
테스트 및 확장 용이성이 증가하고, 데이터 바인딩을 사용한다면 View와 ViewModel사이의 의존성 또한 없어집니다. 그러나 ViewModel의 설계가 쉽지 않습니다.
출처
https://medium.com/@ankit.sinhal/mvc-mvp-and-mvvm-design-pattern-6e169567bbad
https://wooooooak.github.io/android/2019/05/07/aac_viewmodel/
https://beomy.tistory.com/43
https://junghun0.github.io/2019/05/22/android-mvp/
https://upday.github.io/blog/model-view-controller/
profile