MVC vs MVP vs MVVM: 일반적인 Android 아키텍처 패턴 설명

개발자로 일하면서 아키텍처 패턴에 대해 들어봤을 것입니다. Android 세계에서 가장 잘 알려진 것은 MVC , MVP 및 MVVM 입니다. 당신은 아마도 그들의 특성을 알고 있지만 차이점과 언제 사용해야하는지 알고 있습니까?

스스로에게 이러한 질문을 던진다면 이 기사는 당신을 위한 것입니다.

MVC – 모델-뷰-컨트롤러

MVC(Model-View-Controller) 는 애플리케이션의 구조를 구성하는 데 도움이 되는 아키텍처 패턴입니다. 책임을 Model, View, Controller의 세 계층으로 나눕니다.

Android 전문가가 필요하십니까?

우리와 함께 일하십시오!

• 모델 – 비즈니스 로직을 관리하고 네트워크 또는 데이터베이스 API를 지원하는 데이터 계층입니다. 모델은 원격 및 로컬 데이터 원본과 함께 작동하여 데이터를 가져오고 저장합니다. 여기에서 비즈니스 로직이 처리됩니다.
• 보기 – 모델에서 사용자까지의 데이터 시각화를 담당하는 UI 계층입니다. 그래픽 인터페이스를 포함하여 데이터가 표시되는 방식을 관리합니다.
• 컨트롤러 – 보기 및 모델 계층을 통합하는 논리적 계층입니다. 컨트롤러의 역할은 사용자 입력을 넘겨받아 무엇을 할 것인지 결정하는 것입니다.

아래 그래픽에서 개별 구성 요소가 통신하는 방식을 매우 빠르게 확인할 수 있습니다.

어떻게 작동합니까?

몇 년 동안 여러 MVC 변형이 등장했지만 여기서는 가장 인기 있는 두 가지 변형인 수동 모델과 능동 모델을 언급하겠습니다.

패시브 모델

이 버전의 MVC에서 컨트롤러는 모델을 조작하는 유일한 클래스입니다. 이 프로세스를 잘 설명하기 위해 아래 그래픽을 사용하겠습니다.

1. 컨트롤러는 사용자의 작업에 응답하고 모델에 연결합니다.
2. 모델이 변경되면 컨트롤러는 뷰에 데이터를 업데이트하도록 지시합니다.
3. 보기는 모델에서 업데이트된 데이터를 가져와 사용자에게 표시합니다.

활성 모델

이 버전의 MVC에서는 컨트롤러 이외의 다른 클래스가 모델을 조작합니다.

이때 Observer 패턴을 사용하며 View는 Model Observer로 등록된다. 덕분에 View는 Model이 변경될 때 지속적으로 업데이트됩니다.

장점

1. MVC 패턴은 분리 문제를 크게 지원합니다. 코드의 테스트 가능성을 높이고 확장을 용이하게 하여 새로운 기능을 쉽게 구현할 수 있습니다.
2. Model 클래스에는 Android 시스템 클래스에 대한 참조가 없으므로 단위 테스트가 매우 쉽습니다.
3. 컨트롤러는 Android 클래스를 확장하거나 구현하지 않습니다. 단위 테스트를 가능하게 합니다.

단점

1. 보기는 컨트롤러와 모델 모두와 관련이 있습니다.
   • View의 Model 의존성은 주로 고급 View에서 문제를 일으킵니다. 왜요? 모델의 역할이 원시 데이터를 제공하는 것이라면 View는 사용자 인터페이스 논리를 처리합니다.
     반면에 모델이 표시를 위해 직접 준비된 데이터를 표시하는 경우 비즈니스 로직과 UI 로직을 모두 지원하는 모델을 얻게 됩니다.
   • 모델을 적극적으로 구현하면 각 데이터 유형에 대해 관찰자가 필요하기 때문에 클래스와 메서드 수가 기하급수적으로 증가합니다.
   • 뷰가 컨트롤러와 모델 모두에 의존하는 경우 UI 로직을 변경하려면 여러 클래스에 대한 업데이트/변경이 필요할 수 있으므로 패턴의 유연성이 감소합니다.
2. UI 로직 처리는 하나의 클래스로 제한되지 않습니다. 새로운 프로그래머에게 이것은 상당한 문제이며 Model, View, Controller 사이의 책임 분담 가능성이 매우 높습니다.
3. 시간이 지남에 따라 특히 빈혈 모델이 있는 응용 프로그램에서 점점 더 많은 코드가 컨트롤러로 전송되기 시작하여 컨트롤러 가 부풀어 오르고 부서지기 쉽습니다.

요약

View가 Model에 의존하고 View에 로직이 있으면 애플리케이션의 코드 품질이 크게 저하될 수 있습니다. 다른 패턴, 특히 모바일 애플리케이션에 제안된 패턴을 선택하여 이러한 위험을 줄일 수 있습니다. 아래에서 그들에 대해 읽어보십시오.

MVP – 모델-뷰-발표자

MVP( Model-View-Presenter )는 MVC 패턴의 약점을 처리하는 데 사용할 수 있는 아키텍처 패턴입니다. 모듈성, 테스트 가능성 및 훨씬 더 명확하고 쉽게 코드베이스를 유지 관리할 수 있는 기능을 제공합니다.

MVP는 애플리케이션 구조를 View , Model 및 Presenter 레이어로 나눕니다.

• 모델 – MVC 패턴과 유사합니다.
• 보기 – 발표자가 지정한 방식으로 사용자에게 데이터를 표시하는 UI 계층입니다. 활동, 프래그먼트 또는 모든 공통 보기로 구현할 수 있습니다.
• 발표자 – 보기와 모델 계층 사이를 중재하는 논리 계층입니다. View 및 Model 레이어에 모두 연결하고 사용자가 수행한 작업에 반응합니다.

어떻게 작동합니까?

MVP 에서 View와 Presenter는 완전히 분리되어 추상화를 통해 서로 통신합니다. Contract 인터페이스 클래스는 이들 간의 관계를 정의합니다. 덕분에 코드가 더 읽기 쉽고 계층 간의 연결이 이해하기 쉽습니다. 구현 세부 정보에 관심이 있는 경우 Model-View-Presenter: Android 지침을 읽어보세요.

Presenter는 Android 전용 API에 대한 참조를 가질 수 없습니다.

개별 구성 요소 간의 데이터 교환 프로세스에 대한 개요는 아래 그림을 참조하십시오. 이 문서의 목적을 위해 이 예는 단순화되었습니다.

1. 사용자가 작업을 수행합니다.
2. Presenter는 사용자의 작업에 반응하고 적절한 요청을 Model에 보냅니다.
3. 모델이 업데이트되고 새 데이터가 발표자에게 전송됩니다.
4. Presenter는 표시할 데이터를 준비하고 View로 보냅니다.
5. 보기는 사용자에게 데이터를 표시합니다.

장점

1. Presenter 로직은 Android 전용 보기 및 API에 연결되어 있지 않으므로 쉽게 테스트할 수 있습니다 .
2. View와 Presenter는 완전히 분리되어 있어 보기를 쉽게 조롱하고 MVC에서보다 단위 테스트를 더 피상적으로 만듭니다.
3. 보기 표시와 관련된 모든 것을 처리하는 클래스는 Presenter뿐입니다 .

단점

1. 발표자 는 컨트롤러와 마찬가지로 추가 비즈니스 로직을 축적하는 경향이 있습니다. 이 문제를 해결하려면 코드를 분해하고 한 가지 책임으로만 클래스를 만드는 것을 기억하십시오.
2. 이것은 Android 앱에 대한 훌륭한 패턴이지만 작은 앱이나 프로토타입을 개발할 때 압도적으로 느껴질 수 있습니다.

요약

MVC에 비해 이 패턴이 훨씬 좋습니다. MVC 패턴의 두 가지 중요한 문제를 해결합니다.

1. 보기는 더 이상 컨트롤러와 모델을 모두 참조하지 않습니다.
2. 뷰의 프레젠테이션과 관련된 모든 것을 처리하는 단 하나의 클래스인 Presenter만 있습니다.

MVVM – 모델-뷰-뷰 모델

MVVM( Model-View-ViewModel )은 이벤트 기반 패턴입니다. 덕분에 설계 변경에 빠르게 대응할 수 있습니다. 이 아키텍처 패턴을 사용하면 MVC 또는 MVP의 경우보다 훨씬 더 비즈니스 및 동작 논리에서 UI를 분리할 수 있습니다.

• ViewModel – 모델에서 뷰 레이어로 데이터를 전달하고 사용자 작업을 처리합니다. View에 대한 데이터 스트림을 제공한다는 점은 언급할 가치가 있습니다.
• 보기 – UI 계층은 그래픽 인터페이스에서 데이터, 시스템 상태 및 현재 작업을 표시하는 역할을 합니다. 그 외에도 ViewModel을 초기화하고 View 요소와 바인딩합니다(ViewModel에 사용자 작업에 대해 알려줍니다).
• 모델 – MVC와 동일 – 변경 없음.

어떻게 작동합니까?

MVVM 패턴 의 개념은 주로 ViewModel 레이어에서 변화하는 데이터를 관찰하고 데이터 바인딩 메커니즘을 통해 변화에 대응하는 View 레이어(Observer 패턴)를 기반으로 합니다.

MVVM 패턴의 구현은 여러 가지 방법으로 달성할 수 있습니다. 그러나 데이터 바인딩 메커니즘을 포함할 가치가 있습니다. 덕분에 View 계층의 논리가 최소화되고 코드가 더 정리되고 테스트가 더 쉬워졌습니다.

MVP 패턴이 프리젠터가 무엇을 표시할지 View에 직접 지시했다는 것을 의미했다면 MVVM ViewModel 은 Views가 연관될 수 있는 이벤트 스트림을 노출합니다. ViewModel은 더 이상 Presenter와 마찬가지로 View에 대한 참조를 저장할 필요가 없습니다. 이것은 또한 MVP 패턴에 필요한 모든 인터페이스가 이제 불필요하다는 것을 의미합니다.

또한 보기는 위의 그래픽에서 볼 수 있는 것처럼 ViewModel에 다양한 작업을 알립니다. 따라서 MVVM 패턴은 View와 ViewModel 간의 양방향 데이터 바인딩을 지원합니다. View에는 ViewModel에 대한 참조가 있지만 ViewModel에는 View에 대한 정보가 없습니다.

장점

1. 보기에 중독되지 않았기 때문에 단위 테스트가 더 간단 합니다. 테스트할 때 모델이 변경됨에 따라 관찰 가능한 변수가 올바르게 배치되었는지 확인하는 것으로 충분합니다.
2. ViewModel은 단순히 상태를 노출하기 때문에 단위 테스트에 더욱 친숙 하므로 데이터가 어떻게 사용되는지 테스트하지 않고 독립적으로 테스트할 수 있습니다. 요컨대, 보기에 의존하지 않습니다.
3. View에만 ViewModel에 대한 참조가 포함되어 있으며 그 반대는 아닙니다. 이것은 단단한 결합 문제를 해결합니다. 단일 View는 여러 ViewModel을 참조할 수 있습니다.
4. 복잡한 View의 경우에도 동일한 계층 구조에 다른 ViewModel을 가질 수 있습니다 .

단점

1. 복잡한 UI에서 ViewModel과 해당 상태를 관리 하는 것은 초보자에게 때때로 도전적인 일입니다.

요약

MVVM 은 데이터 바인딩 및 이벤트 기반 통신의 이점을 사용하면서 MVP가 제공하는 이점을 결합합니다. 그 결과 높은 코드 분리 및 테스트 가능성으로 모델이 가능한 한 많은 작업을 제어하는 ​​패턴이 생성됩니다.

MVC 대 MVP 대 MVVM: 비교

MVC 대 MVP 대 MVVM: 요약

MVP 패턴과 MVVM 패턴 모두 MVC 패턴보다 훨씬 더 나은 성능을 보입니다. 선택하는 방법은 실제로 선호도에 따라 다릅니다. 그러나 이 기사가 이들 간의 주요 차이점을 보여주고 선택을 더 쉽게 해주기를 바랍니다.

대안을 찾고 계십니까?

크로스 플랫폼을 선택하십시오!

서지:

1. Cervone, S. (2017) Model-View-Presenter: Android 지침.
2. Dang, AT (2020) MVC 대 MVP 대 MVVM.
3. Muntenescu, F. (2016) Android 아키텍처 패턴 1부: 모델-보기-컨트롤러.
4. Muntenescu, F. (2016) Android 아키텍처 패턴 2부: 모델-보기-발표자.
5. Muntenescu, F. (2016) Android 아키텍처 패턴 파트 3: 모델-뷰-뷰모델.