개발자가 되기 위해 기본인 디자인 패턴(MVC, MVP, MVVM) 패턴을 정리해 보려고 한다.
◆ 공통 용어
● Model
내부적으로 쓰이는 데이터를 저장하고, 처리하는 역할을 한다. 흔히 '비즈니스 로직'이라고 부른다.
View, Presenter 등 다른 어떤 요소에도 의존적이지 않은 독립적인 영역이다.
● View
사용자 인터페이스(UI)라 불리는 영역이다. 안드로이드에서는 Activity, Fragment가 대표적인 예시이다.
각 디자인 패턴에 따라 그 용도에 차이가 있다.
# MVC (Model + View + Controller)
● Controller
어플리케이션이 실행하게 되면 작동하는 컨트롤러이다. Model과 View를 서로 연결해주는 역할을 하고 유저에게 액션을 받아 처리하는 역할까지 맡게 된다. 단순하게 유저의 액션을 받아서 처리할 수 있는 액티비티, 프래그먼트라고 생각하면 된다.
예를 들어 전화번호부 애플리케이션에서 전화번호를 등록한다고 할 때 사용자가 전화번호 및 기타 정보를 뷰로부터 입력받으면 컨트롤러는 해당 데이터를 모델로 전환하여 데이터베이스에 입력한다. 이때 보델의 상태가 바뀌면 모델은 등록된 뷰에 자신의 상태가 바뀌었다는 것을 알리고 뷰는 거기에 맞게 사용자에게 모델의 상태를 보여준다.
◆ MVC패턴 장점
- 완벽하게 모델과 뷰를 분리해준다
- 모델을 쉽게 테스트 할 수 있다.
- 규모가 작은 애플리케이션에 MVC패턴을 적용 시 개발기간이 짧아지고, 거의 모든 코드가 액티비티나 프래그먼트에 작성되는 경향이 있어서 코드를 파악하기 쉽다.
◆ MVC패턴 단점
액티비티 또는 프래그먼트가 뷰와 컨트롤러의 역할을 겸하는 구조라 코드량이 점진적으로 증가할 수밖에 없고, 그로 인해서 하나의 액티비티 또는 프래그먼트 클래스에서 수천 줄이 넘는 코드가 작성되기도 합니다. 그렇게 되면 스파게티 코드가 되고 유지보수 비용도 증가합니다.
# MVP (Model + View + Presenter)
● View
MVP의 View는 MVC 에서의 Controller에 있던 액티비티와 프래그먼트가 넘어왔다고 생각하면 된다.
Model에서 처리된 데이터를 Presenter를 통해 받아서 사용자에게 보여주며, 사용자 액션 및 Activity lifecycle 변화를 감지해서 Presenter에 보내는 역할을 한다. Presenter를 이용해 데이터를 주고 받기 때문에 Presenter에 의존적이다.
● Presenter
기본적으로 Controller와 같은 역할을 한다고 생각하면 된다. Controller와 다른점이 있다면 뷰에 직접 연결되는 것이 아니라 인터페이스로 연결이 된다.
Model과 View사이의 매개체이다.
View에서 캐치한 유저 액션을 전달받아서 Model의 로직을 호출하거나, Model의 로직으로부터 나온 결과를 전달받아서 View에 보내 UI 변경을 하는 등 둘 사이의 소통 역할을 한다. Model, View 모두에 의존적이다.
◆ MVP패턴 장점
Model과 View간의 결합도를 낮추면, 새로운 기능을 추가하거나 변경할 필요가 있을 때 관련된 부분만 수정하면 되기 때문에 확장성이 좋아지며, 테스트 코드를 작성하기 편리해지기 때문에 더 안전한 코드 작업이 가능하다.
◆ MVP패턴 단점
View와 Presenter 간의 의존성이 높고 1:1 관계를 유지해야 하고 Presenter를 재사용할 수 없어, View가 늘어날 때마다 Presenter도 같이 늘어나 클래스가 많아진다. 또한 애플리케이션의 기능이 추가될 수 록 Presenter가 거대해지는 단점이 있다.
# MVVM (Model + View + View Model)
● View
MVVM의 View는 MVC 에서의 Controller에 있던 액티비티와 프래그먼트가 넘어왔다고 생각하면 된다.
View는 ViewModel을 Observe(관찰)하다가 값이 변경되면 자동으로 화면을 갱신할 수 있다.
● View Model
ViewModel 은 View 의 추상화된 형태이다.
View에 보여야 하는 데이터와 명령들을 가지고 있다.
ViewModel 이 MVC 패턴의 Controller 나 MVP 패턴의 Presenter와 다른 점은, View 가 ViewModle을 observe(관찰) 하는 형태로 binding 되어 있기 때문에, data의 갱신을 View 가 자동으로 받을 수 있게 되어있다는 것이다.
◆ MVVM패턴 장점
- 뷰가 데이터를 실시간으로 관찰한다. LiveData, 즉 Observable 패턴을 이용하기 때문에 데이터베이스를 관찰하고 자동으로 UI를 갱신한다.
- 생명주기로부터 안전하고 메모리 릭을 방지한다. 뷰모델을 통해 데이터를 참조하기 때문에 액티비티/프래그먼트의 생명주기를 따르지 않는다. 화면 전환과 같이 액티비티가 파괴된 후 재구성되어도 뷰 모델이 데이터를 홀드하고 있기 때문에 영향을 받지 않는다. 또한 뷰가 활성화되어있을 경우에만 작동하기 때문에 불필요한 메모리 사용을 줄일 수 있다.
- 역할분리, 모듈화가 잘 되어있다. UI, 비즈니스 로직, 데이터베이스가 기능별로 모듈화 되어있어서 역할 별로 정리가 깔끔하여 유닛 테스트가 한결 용이해질 것이다.
공부하던 중 조금 더 이해가 쉬운 사진을 찾아와 봤다
참고 사이트
https://blog.yena.io/studynote/2019/03/16/Android-MVVM-AAC-1.html
https://blog.crazzero.com/m/152
https://healthcoding.tistory.com/14?category=951717
'안드로이드 공부 노트' 카테고리의 다른 글
| 안드로이드 Fragment LifeCycle(프래그먼트 생명 주기)알아보기! (0) | 2022.01.23 |
|---|---|
| Android Jetpack - 2편(View Binding) 예제를 이용한 사용법 (0) | 2022.01.22 |
| Android Jetpack - 1편 (Room) 예제를 이용한 사용법 (0) | 2022.01.20 |
| 안드로이드 4대 컴포넌트 (1) | 2021.12.18 |
| 안드로이드 액티비티 생명주기 (Life Cycle) (0) | 2021.12.15 |
