Android :: MVC, MVP 그리고 MVVM

💡MVC

MVC

Model + View + Controller

 

Model = 데이터

• 데이터 + 상태 + 비즈니스 로직 = 앱의 두뇌
• 어플리케이션에서 사용되는 데이터와 그 데이터를 처리하는 부분
• 뷰나 컨트롤러에 묶이지 않아 많은 곳에서 재사용 가능

View = xml

• 모델의 표현
• 사용자에게 보여지는 UI 부분
• UI를 그리고, 사용자와 앱과 상호작용할 때 컨트롤러와 통신
• 사용자가 버튼을 클릭하거나 값을 입력하는 등 행동을 할 때 무엇을 해야할 지 잘 모를수록 모델에 종속되지 않으므로 보다 변화에 유연

Controller = Activity / Fragment

• 사용자의 입력을 받고 처리하는 부분
• 앱을 묶어주는 접착제 역할
• 애플리케이션에서 발생하는 일을 담당하는 마스터 컨트롤러 역할
• 뷰가 컨트롤러에게 사용자가 버튼을 눌렀다고 알리면, 컨트롤러는 그에 따라 어떻게 모델과 상호작용할지 결정한다.
• 모델에서 데이터가 변화되는 것에 따라 컨트롤러는 뷰의 상태를 적절하게 업데이트하도록 결정할 수 있다.
• 안드로이드 앱에서는 컨트롤러가 주로 액티비티 or 프래그먼트

동작 과정

1. 사용자의 액션들은 Controller에 들어오게 된다.
2. 컨트롤러는 사용자의 액션을 확인하고 model을 업데이트
3. 컨트롤러는 model을 나타내줄 view를 선택
4. view는 model을 이용하여 화면을 나타낸다.

특징

• 코드 구성이 간단하고, controller에 기능이 몰빵되어 있다.
• 간단한 구조의 앱이라면 MVC 패턴으로 작성하는게 직관적이고 작업공수가 적게 든다.
• 단점 : View와 Model 사이의 의존성이 높고, 프로그램의 복잡도가 올라가면 controller의 길이가 점점 커지게 되어 유지보수가 힘들어짐

---

💡MVP

MVP

Model + View + Presenter => MVC에서 Controller 대신 Presenter

컨트롤러의 책임에 묶이지 않고도 뷰와 액티비티가 자연스럽게 결합하도록 한다.

 

Model : MVC와 동일

 

View

• 변한 것 : 액티비티 / 프래그먼트가 이제 뷰의 일부로 간주됨
• 액티비티가 뷰 인터페이스를 구현해서, 프리젠터가 코드를 만들 인터페이스를 갖도록 하는 것이 좋다.
• 이렇게 하면 특정 뷰와 결합되지 않고 가상 뷰를 구현해서 간단한 유닛 테스트를 실행할 수 있음

Presenter

• view에서 요청한 정보로 model을 가공하여 view에 전달해주는 부분 → view와 model을 붙여주는 접착제 역할
• 본질적으로는 MVC의 컨트롤러와 같지만, 뷰에 연결되는 것이 아니라 그냥 인터페이스라는 점이 다름
• 이에 따라 MVC가 가진 테스트 가능성 문제와 함께 모듈화/유연성 문제도 해결

동작 과정

1. 사용자의 액션들은 view를 통해 들어오게 된다.
2. view는 데이터를 presenter에 요청한다.
3. presenter는 model에게 데이터를 요청한다.
4. model은 presenter에서 요청받은 데이터를 응답한다.
5. presenter는 view에게 데이터를 응답한다.
6. view는 presenter가 응답한 데이터를 이용하여 화면을 나타낸다.

특징

• Presenter와 View는 1:1 관계
• 장점 : view와 model의 의존성이 없다. (MVC 패턴의 단점 - view와 model의 의존성 해결) ⇒ presenter를 통해서만 데이터를 전달받기 때문
• 단점 : view와 model의 의존성은 해결되었지만, MVC와 유사한 만큼 프로그램의 복잡도가 올라가면 presenter의 코드량이 커지고, view와 presenter 사이의 의존성이 높아진다. 그래서 MVC와 마찬가지로 유지보수가 힘들어짐

---

💡MVVM

MVVM

 

Model + View + ViewModel

 

위와 같이 MVC, MVP의 경우 액티비티가 무거워지거나 종속성이 강해져 테스트가 힘들고 유지보수가 어려워진다는 단점이 있었다. 이러한 문제점을 해결하기 위해 아키텍쳐 패턴이 등장했고, 그 중 하나가 MVVM이다.

안드로이드 데이터 바인딩을 사용하는 MVVM은 각각의 역할을 분리하여 가독성과 재사용성을 높였고, 테스트와 모듈화가 쉽고 뷰와 모델을 연결하기 위한 연결코드를 줄일 수 있다.

 

Model : MVC와 동일

 

View : MVC와 동일

• 뷰모델에 의해 보여지는 Observable 변수와 액션에 유연하게 바인딩

ViewModel

• view를 나타내주기 위한 model
• view를 나타내기 위한 데이터 처리를 하는 부분

MVC와 MVVM의 차이점

동작 과정

1. 사용자의 액션들은 view를 통해 들어온다.
2. view에 액션이 들어오면, command 패턴으로 view model에 액션을 전달한다.
3. view model은 model에게 데이터를 요청한다.
4. model은 view model에게 요청받은 데이터를 응답한다.
5. view model은 응답 받은 데이터를 가공하여 저장한다.
6. view는 view model과 Data Binding 하여 화면을 나타낸다.

=> 즉, 뷰에서 뷰모델로, 뷰모델에서 모델로 작업을 처리하며, 뷰에서 뷰모델을 관찰(Observe)하여 데이터의 변경 사항을 감지하고 자동으로 화면을 갱신한다.

 

특징

• MVVM 패턴은 Command 패턴과 Data Binding 두 가지 패턴을 사용하여 구현됨 ⇒ view와 view model 사이의 의존성 없앰
• viewmodel : view = 1 : n → 여러 뷰에서 재사용 가능, 코드의 양을 줄일 수 있다.

장점

• 뷰가 데이터를 실시간으로 관찰한다. (LiveData - Observer 패턴 이용)
• 생명주기로부터 안전하다. 메모리 누수를 방지한다. => AAC의 뷰모델을 통해 데이터를 참조하기 때문에 액티비티/프래그먼트의 생명주기를 따르지 않는다. 즉, 액티비티/프래그먼트의 생명주기 동안 계속 살아있고, onDestroy()가 호출될 때 사라지게 된다.
• 역할 분리 => UI, 비즈니스 로직, 모델이 기능별로 모듈화 되어 있음

---

 

참고 : https://blog.yena.io/studynote/2019/03/16/Android-MVVM-AAC-1.html