아키텍처 패턴이란?
- 소프트 웨어의 구조를 패턴화 한 것
안드로이드 아키텍처 패턴의 종류
MVC(Model - View - Controller)
Model
- 어플리케이션의 데이터를 저장하고 처리하는 역할
View
- 사용자가 보게될 화면 구성을 담당(UI)
Controller
- View와 Model을 서로 연결하고 제어
- 사용자의 입력을 처리
Android 에서는 View 와 Controller가 Activity,Fragment 에 포함되어 있다
흐름
- 사용자-Controller-Model-Controller-View-사용자
장점
- 구현이 쉽다
- 가장 단순하다
- 이해가 쉽다
단점
- 각 클래스의 코드양이 증가한다
- View와 Model 간의 의존성이 높아서 기능 추가 및 유지보수가 어렵다
MVP(Model - View - Presenter)
Model
- MVC와 동일
View
- MVC와 동일
Presenter
- View에서 전달받은 이벤트를 처리하여 다시 View로 반환
- Model에 데이터 요청이 필요한 이벤트가 들어오는 경우 Model에 요청한 후 받은 데이터를 View에 전달
- Controller과 같은 역할을 하나, Interface로 이루어져 UnitTest에 자유롭습니다
흐름
- 사용자-View-Presenter-Model-Presenter-View-사용자
장점
- Model과 View의 의존성이 없다
- UI와 Data의 구분이 명확하다
단점
- View와 Presenter의 의존성이 강하다
- 기능이 커질수록 Presenter의 비중이 커져 분리가 어렵다
MVVM(Model - View - ViewModel)
Model
- MVC, MVP와 역할을 동일하지만 데이터가 변경되면 ViewModel을 거쳐서 View로 전달
View
- MVC, MVP와 역할을 동일하지만 View는 Model을 알지 못하기 때문에 ViewModel을 옵저빙하고 있다가 상태 변화가 전달되면 화면을 갱신
ViewModel
- View에 연결할 데이터와 명령으로 구성되어 있으며 변경 알림을 통해 View에게 상태 변화를 전달
- ViewModel은 Model은 알지만 View는 알지 못한다
- Model과 상호 작용하며, View에 종속되지 않고 1:N 구조를 갖는다
- View가 어떤 종속성도 가지지 않기 때문에 ViewModel을 다른 View에서도 활용할 수 있다
흐름
- 사용자-View-ViewModel-Model-ViewModel-View-사용자
장점
- Model과 View, View와 ViewModel의 의존성이 없다
- UI 컨트롤러의 책임을 분담하여 클래스가 거대해지는 것을 방지하고 유지 보수, 재사용성, 테스트 등 용이
단점
- ViewModel의 설계가 어렵다
- DataBinding 등 추가적인 공부가 필요하다.
AAC ViewModel???
MVI
참고
https://jionchu.tistory.com/entry/Android-Architectural-Pattern-MVC-MVP-MVVM
https://velog.io/@changhee09/%EC%95%88%EB%93%9C%EB%A1%9C%EC%9D%B4%EB%93%9C-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98-%ED%8C%A8%ED%84%B4MVC-MVP-MVVM
https://adjh54.tistory.com/60
https://meetup.nhncloud.com/posts/342
