개발노트/android

안드로이드에서의 디자인 패턴(MVC/MVP/MVVM)

시계속세상은아직돌아가는중 2024. 3. 27. 09:51

개요

 

안드로이드의 디자인 패턴을 다시 생각해보자
안드로이드에의 디자인 패턴은 대표적으로 3가지로 말할 수 있다.

 

MVC/MVP/MVVM

 

MVI패턴도 존재하지만, 아직은 내가 다뤄볼만한 디자인 패턴이 아닌 것 같다.

 

디자인 패턴의 사용 이유

 

관심사를 분리하기 위해서다.

관리사를 분리함으로써 프로그램을 좀 더 안정적이고 확장성 높게 만들기 위함이다.

 

관심사를 분리하지 않으면, 하나의 코드가 모든 클래스 안에 난잡하게 섞일 것이다.

 

레이아웃,데이터 처리, 이벤트 처리가 하나로 합쳐져 있다면, 이후 유지보수는 물론이거니와 협업 시 코드 읽기, 테스팅이 불가능할정도로 혼돈 그 자체일 것이다.

 

그렇기 때문에 우리는 본인이 개발하는 프로그램에 알맞게 디자인 패턴을 선택하여 관심사 분리를 통한 코드 확장성 및 안정성을 확보해야 한다.

 

코드의 의도를 명확하게 전달하고 협업하는 개발자/그리고 프로그래밍 하는 자기자신이 확장하고 이해도를 높일 수 있는 디자인 패턴에 대해 알아보자.

MVC

 

Model - View - Conroller로 관심사를 분리한다.

 

Model  데이터와 비즈니스 로직
View 사용자에게 보여지는 UI 로직이다.

Model의 데이터를 받아들이고 Controller로부터 갱신처리를 받아들이는 부분이다.

안드로이드에서는 xml이 이에 해당한다.
Controller  view - model를 이어주는 부분이다.

외부에서 전달받은 정보를 처리해서 view에 갱신한다.

모델로부터 데이터를 검색하거나 업데이트 받고 뷰에게 이러한 데이터를 표시/입력처리 등을 하여 모델을 변경할 수 있다.

 

그렇다면 MVC패턴에서 activity와 pragment는 view인가?

 

결론은 아니다.

 

MVC패턴에서 acitivity와 pragment는 Controller의 역활을 수행한다.

이는 MVC패턴의 단점으로도 작용하는 부분이다.

 

MVC 패턴의 장점


빠른 개발이 가능하다.

 

단순한 구조를 가지고 있고 기본적인 관심사의 분리가 이루어져 있다.

 

MVC 패턴의 단점

controller로 많은 코드가 모이게 된다.


어플리케이션이 확장될 수록 코드는 비대해지고 유지보수가 어려워진다.

 

또한 안드로이드의 특성상 acitivity와 pragment는 view역활과 controller의 역활을 둘 다 수행하게된다.

따라서 안드로이드에서 mvc 패턴을 사용한다면, 관심사의 분리가 제대로 이루어지지 않을 것이다.

 

MVP

Model - View - Presenter

 

Presenter : view로부터 정보를 전달받고 필요한 경우 model에서 데이터를 취득하여 view에게 데이터를 전달한다. 본질적으로는 Controller와 같은 기능을 하지만, 인터페이스를 통한 구현부를 나누므로 의존성이 해소되었다.

 

MVP의 장점

 

Model과 View의 의존성이 해소되었다.

또한 Controller와 View역활을 둘다 수행하던 acitivity/pragment가 온전히 view로써 기능을 할 수 있게 되었다.

 

MVP의 단점

 

인터페이스를 구현하게 되므로 구현 비능이 올라가게 된다. -> 클래스가 많아지고 코드 복잡성이 높아진.

V : P = 1 : 1이므로, 앱이 커질수록 두 요소의 의존성이 매우 커진다.

또한 기능이 커질수록 Presnter의 코드량이 많아지므로 분리가 점점 어려워진다.

 

MVVM

 

Model - View - ViewModel

 

View Model은 view를 만드는데 필요한 로직을 가진 model이다. viewmodel은 view를 참조히자 않는다.
View Model : View 가 1: n의 관계를 가지게 되었다. 따라서 중복된 코드를 ViewMoldel 하나로 묶어 관리할 수 있게 되었다.

따라서 안드로이드 개발에서 가장 널리 쓰이는 패턴이다.

 

MVVM패턴의 장점

 

View - Model 사이의 의존성이 없으며, ViewModel도 View의 의존성을 가지지 않는다.

참조는  View -> ViewModel -> Model의 단방향으로 이루어진다.

따라서 ViewModel에는 View의 코드가 없기 때문에 UnitTest를 쉽게 할 수 있으며 비즈니스 로직의 교체가 매우 재빠르고 편하게 이루어진다.

 

MVVM패턴의 단점

 

코드의 복잡성이 MVP보다 증가하였으며, 초기 설계 단계가 무척이나 오래걸린다.

따라서 소규모 프로젝트에서 사용 적합한지에 대한 고찰이 필요하다.

 

안드로이드 앱 아키텍처란?

 

구글에서 제공하는 안드로이드 개발 가이드라인으로, MVVM like pattern이다.

안드로이드 앱 아키텍처를 따르므로써, mvvm like pattern을 통해 안정적인 아키텍처를 설계하고 안정적인 구글 스토어의 생태계를 가질 수 있게된다.

 

현재 가이드 라인은 이러하다.

 

UI(view,viewmodel) - Domain(usecase) - Data(repositories, data sources)

 

Domain -> ViewModel이 가지고 있던 비즈니스 모델을 분리하게 된다.

Domain은 option이며 규모가 작은 프로젝트에서는 큰 의미를 가지기 어렵다.

저작자표시 비영리 변경금지 (새창열림)