1-1. 디자인 패턴 [03] - MVC 패턴, MVP 패턴, MVVM 패턴

1. MVC 패턴

MVC 패턴은 모델(Model), 뷰(View), 컨트롤러(Controller)로 이루어진 디자인 패턴이다. 애플리케이션 구성 요소를 세 가지 역할로 구분하여 개발 프로세스에서 각 구성 요소에만 집중해서 독립적으로 개발할 수 있다. 재사용성과 확장성이 용이하지만, 애플리케이션이 복잡해질수록 모델과 뷰의 관계가 복잡해지는 단점이 있다.

 

1) 모델 (Model)

모델은 애플리케이션의 데이터베이스, 상수, 변수 등의 데이터와 데이터를 조작하고 가공하는 규칙인 비즈니스 로직을 담당한다. 뷰나 컨트롤러에 대해 전혀 알지 못하며, 뷰에서 데이터를 생성하거나 수정하면 컨트롤러를 통해 모델을 생성하거나 갱신한다.

 

 

2) 뷰 (View)

뷰는 데이터를 시각적으로 보여주는 사용자 인터페이스 요소를 나타낸다. 모델의 데이터를 받아서 화면에 그리며, 사용자로부터 입력, 클릭 등과 같은 변경이 일어나면 컨트롤러에게 전달한다. 모델이나 컨트롤러에 대한 직접적인 로직은 포함하지 않는다.

 

 

3) 컨트롤러 (Controller)

컨트롤러는 모델과 뷰 사이의 중개자 역할을 한다. 뷰에서 전달된 사용자 입력을 처리하고, 모델의 비즈니스 로직을 호출하여 상태 변화를 뷰에 반영하도록 지시한다. 모델과 뷰의 생명주기도 관리하며, 애플리케이션의 흐름을 제어한다.

 

 

4) 안드로이드에서의 MVC 패턴

안드로이드의 액티비티는 UI(뷰)를 관리하는 동시에 사용자 입력을 처리하는(컨트롤러) 역할까지 수행하기 때문에 뷰와 컨트롤러의 역할이 명확하게 분리되지 않아 코드가 비대해지기 쉽다는 단점이 있다. 따라서 안드로이드 개발에서는 MVVM 패턴이 더 선호된다.

 

- Model : 데이터베이스(Room), 네트워크 통신(Retrofit), 비즈니스 로직을 담고 있는 Repository 클래스 등

- View : XML 레이아웃 파일, 액티비티(Activity), 프래그먼트(Fragment)

- Controller : 액티비티나 프래그먼트가 컨트롤러의 역할도 동시에 수행하는 경우가 많다.

 

 

 

2. MVP 패턴

MVC 패턴으로부터 파생되었으며, MVC에서 뷰와 컨트롤러의 책임이 명확하지 않았던 문제를 해결하기 위해 컨트롤러 대신 프레젠터(Presenter)로 교체된 패턴이다. 뷰와 프레젠터는 일대일 관계이기 때문에 MVC 패턴보다 더 강한 결합을 지닌다.

 

1) 프레젠터 (Presenter)

프레젠터는 뷰와 모델 사이의 중개자 역할을 한다. 뷰로부터 사용자 입력을 받아 모델에게 요청하고, 모델로부터 데이터를 받아서 처리한 후 뷰에 표시하도록 지시한다. 뷰를 직접 참조하며, 뷰의 상태를 업데이트 하는 로직을 가진다.

 

 

2) 안드로이드에서의 MVP 패턴

안드로이드의 액티비티가 비대해지는 문제를 해결하는 데 효과적이다.

 

- Model : 데이터베이스(Room), 네트워크 통신(Retrofit), 비즈니스 로직을 담고 있는 Repository 클래스 등

- View : 액티비티나 프래그먼트는 오로지 UI 관련 코드만 담게 되며, 모든 사용자 입력 처리는 프레젠터에게 전달한다.

- Presenter : API 호출, 데이터베이스 접근 등 비즈니스 로직과 데이터 처리를 모두 담당한다. 모델에서 데이터를 받아, 뷰가 제공하는 인터페이스 메서드를 통해 UI 업데이트를 요청한다.

 

 

3) MVP 패턴의 장점

- 프레젠터는 안드로이드 프레임워크에 대한 의존성이 없으므로, 뷰와 독립적으로 로직을 테스트할 수 있다.

- 뷰는 UI, 프레젠터는 로직으로 책임이 명확하게 분리되어 코드를 이해하고 관리하기 쉽다.

- 프레젠터의 로직을 다른 뷰에 재사용할 수 있습니다.

 

 

 

3. MVVM 패턴

MVVM 패턴은 MVP에서 발전했으며, MVC의 컨트롤러가 뷰모델(View Model)로 바뀐 패턴이다.

 

1) 뷰모델 (View Model)

뷰를 더 추상화한 계층이며, 뷰에 보여줄 데이터를 준비하고, 비즈니스 로직을 호출하는 중간 관리자 역할을 한다.  컨트롤러와는 다르게 커맨드와 데이터 바인딩을 가지는 것이 특징이다. 뷰와 뷰모델 사이의 양방향 데이터 바인딩을 지원하며, UI를 별도의 코드 수정없이 재사용할 수 있고 단위 테스팅하기 쉽다는 장점이 있다. 뷰에 대한 직접적인 참조가 없는 것이 MVP의 프레젠터와 가장 큰 차이점이다.

 

* 커맨드 : 여러 가지 요소에 대한 처리를 하나의 액션으로 처리하는 기법

* 데이터 바인딩 : 화면에 보이는 데이터와 메모리 데이터를 일치시키는 기법

// 데이터바인딩 코드 예시
<layout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    xmlns:tools="http://schemas.android.com/tools">

    <data>
        <variable
            name="category"
            type="com.example.exampleapp.data.model.Category" />
    </data>

    <androidx.constraintlayout.widget.ConstraintLayout
        android:layout_width="match_parent"
        android:layout_height="wrap_content">

        <com.google.android.material.imageview.ShapeableImageView
            android:id="@+id/iv"
            android:layout_width="64dp"
            android:layout_height="64dp"
            imageUrl="@{category.imageUrl}"
            app:layout_constraintEnd_toEndOf="parent"
            app:layout_constraintStart_toStartOf="parent"
            app:layout_constraintTop_toTopOf="parent"
            app:shapeAppearanceOverlay="@style/AppRoundedImage.Circle" />

        <TextView
            android:id="@+id/tv"
            android:layout_width="0dp"
            android:layout_height="wrap_content"
            android:text="@{category.label}"
            app:layout_constraintBottom_toBottomOf="parent"
            app:layout_constraintEnd_toEndOf="parent"
            app:layout_constraintStart_toStartOf="parent"
            app:layout_constraintTop_toBottomOf="@id/iv" />

    </androidx.constraintlayout.widget.ConstraintLayout>
</layout>

 

 

2) 안드로이드에서의 MVVM 패턴

 안드로이드 Jetpack 라이브러리(LivaData, ViewModel 등)와 함께 안드로이드 개발에서 가장 널리 사용된다.

 

- Model : 데이터베이스(Room), 네트워크 통신(Retrofit), 비즈니스 로직을 담고 있는 Repository 클래스 등

- View : 뷰모델에 있는 관찰 가능한 데이터를 구독하여 뷰모델을 직접 조작하지 않고도 뷰모델의 상태 변화를 자동으로 감지하여 화면을 업데이트한다.

- ViewModel : LiveData, StateFlow와 같은 관찰 가능한 데이터 홀더를 통해 데이터를 노출하여 뷰의 상태와 로직을 관리한다.

 

 

3) MVVM 패턴의 장점

- 뷰와 뷰모델은 LiveData를 통해 간접적으로 통신하므로, 서로의 존재를 직접적으로 알 필요가 없어 결합도가 낮아진다.

- 뷰모델은 안드로이드 프레임워크에 대한 의존성이 없으므로, 뷰와 독립적으로 로직을 테스트할 수 있다.

- LiveData는 안드로이드 컴포넌트의 생명주기를 인식하므로, 메모리 누수 걱정 없이 안전하게 데이터를 관찰할 수 있다.

- 데이터 바인딩을 활용하면 XML에서 뷰모델의 데이터를 직접 참조할 수 있어, findViewById와 같은 반복적인 UI 업데이트 코드를 줄일 수 있다.

 

 

 

4. MVC vs MVP vs MVVM

- MVC : 뷰와 컨트롤러가 서로를 직접 참조하며, 컨트롤러가 뷰를 제어한다.

- MVP : 프레젠터가 뷰를 직접 참조하며, 프레젠터가 뷰의 메서드를 호출해 UI를 업데이트한다.

- MVVM : 뷰가 뷰모델의 데이터를 구독하여 간접적으로 참조하고, 데이터가 변경되면 자동으로 UI가 갱신된다.