[Android] 아키텍처 패턴(MVC,MVP,MVVM)에 대하여

아키텍처 패턴이란🤔

아키텍처를 설계할 때 참조할 수 있는 전형적인 해결 방식 또는 예제를 의미합니다.

• 소프트웨어 시스템의 구조를 구성하기 위한 기본적인 윤곽을 제시합니다.
• 아키텍처 패턴에는 서브 시스템들과 그 역할이 정의되어 있으며, 서브 시스템 사이의 관계와 여러 규칙, 지침 등이 포함되어 있습니다.

 

아키텍처 패턴의 장점👍🏻

• 시행착오를 줄여 개발 시간을 단축시키고, 고품질의 소프트웨어를 생산할 수 있습니다.
• 검증된 구조로 개발하기 때문에 안정적인 개발이 가능합니다.
• 이해관계자들이 공통된 아키텍처를 공유할 수 있어 의사소통이 간편해집니다.
• 시스템의 구조를 이해하는 것이 쉬워 개발에 참여하지 않은 사람도 손쉽게 유지보수를 수행할 수 있습니다.
• 시스템이 특성을 개발 전에 예측하는 것이 가능해집니다.

그럼 이제 안드로이드 개발 시 많이 사용되는 아키텍처 패턴들에 대해 알아보도록 하겠습니다.🔍

 

---

MVC

MVC 패턴

 

UI로직이 Business 로직이 더 자주 변경되는 경향이 있는 프로젝트에서 개발자는 UI로직을 분리하는 방법이 필요했습니다. 이에 대한 해결책이 MVC패턴입니다.

• Model : Business 로직을 관리하고 네트워크 또는 DB API를 처리하는 데이터 계층
• View : UI레이어, Model의 데이터 시각화 역할
• Controller : Business 로직 계층으로 사용자의 동작을 전달받고 필요에 따라 Model을 업데이트합니다.

MVC 패턴은 Controller와 View가 모두 Model에 의존한다는 것을 의미합니다.

Controller는 데이터를 업데이트하고 View는 데이터를 가져옵니다.

그러나 당시 개발자에게 가장 중요한 것은 Model이 분리되어 UI와 독립적으로 테스트를 할 수 있다는 것입니다.

이에 MVC의 여러 변형이 나타났는데, 가장 잘 알려진 것은 Model이 수동적인지, 아니면 능동적으로 그것이 변경됨을 알리는 것과 관련 있습니다.

 

Passive Model

 

MVC Passive Model

• Passive Model에서의 Controller는 Model을 조작하는 유일한 클래스입니다.
• 사용자의 작업에 따라 Controller는 Model을 수정해야 한다.
• Model이 업데이트된 후 Controller는 업데이트가 필요함을 View에 알림, View는 Model로부터 데이터를 요청합니다.

 

Active Model

 

MVC Active Model

 

• Controller가 Model을 수정하는 유일한 클래스가 아닌 경우 Model은 Observer Pattern을 이용해 View와 다른 클래스에 업데이트에 대해 알립니다.
• Model에는 업데이트에 관심이 있는 Observer의 컬렉션이 포함되어 있습니다.
• View는 Observer 인터페이스를 구현하고 모델에 관찰자로 등록합니다.
• Model이 업데이트될 때마다 Observer 컬렉션을 반복하고 update 메서드를 호출하여 최신 데이터 요청이 트리거 됩니다.

 

Android에서 MVC를 적용하는 방법

Activity 나 Fragment는 MVC에서 View여야 합니다. Controller는 Android 클래스를 확장하거나 사용하지 않는 별도의 클래스여야 하며 모델에서도 동일해야 합니다. Controller는 View에 업데이트를 지시해야 하기 때문에 Controller를 뷰에 연결할 때 한 가지 문제가 발생합니다. Passive Model MVC 아키텍처에서 Controller는 View에 대한 참조를 보유해야 하는데, 이를 해결할 방법은 Activity/Fragment/View가 확장되는 BaseView 인터페이스를 갖는 것입니다.

 

MVC의 장점

• 코드의 테스트 가능성을 높일 뿐만 아니라 확장을 더 쉽게 만들어 새로운 기능을 쉽게 구현할 수 있습니다.
• Model 클래스에는 Android 클래스에 대한 참조가 없으므로 단위 테스트가 간단합니다. Controller도 또한 Android 클래스를 확장하거나 구현하지 않으며 View의 인터페이스 클래스에 대한 참조가 있어야 합니다. 이러한 방식으로 Controller의 단위 테스트도 가능합니다.

 

MVC의 단점

• View가 Controller와 Model 모두에 의존한다는 점을 감안할 때, UI 로직의 변경은 여러 클래스의 업데이트가 필요하므로 패턴의 유연성이 떨어집니다.
• UI로직을 처리하는 것이 View의 역할이므로 UI로직을 단위 테스트하는 것은 불가능합니다.

---

MVP

 

MVP

 

MVC 패턴의 단점을 보완하기 위해 등장한 패턴입니다. MVC 패턴은 View가 Model에 강력하게 의존합니다. MVP는 각 요소를 명확하게 분리하여 커플링을 낮추기 위해 등장했습니다.

 

 

• Model : 데이터 계층. Business 로직을 처리하고 네트워크 및 데이터베이스 계층과의 통신을 담당합니다.
• View : UI레이어. 데이터를 표시하고 Presenter에게 사용자 작업에 대해 알립니다.
• Presenter : Model에서 데이터를 검색하고, UI 논리를 적용하고 View의 상태를 관리하고, 표시할 항목을 결정하고 View의 입력 알림에 반응합니다.

Presenter는 View와 Model의 인스턴스를 가지고 있어 둘을 연결하는 역할을 합니다. Presenter와 View는 1:1 관계입니다. 단순 Interface이기 때문에 테스트가 용이하고 모듈화/유연성 문제가 해결된다는 특징이 있습니다.

 

MVP의 장점

• 문제를 매우 훌륭하게 분리할 수 있다.

 

MVP의 단점

• 작은 앱이나 프로토타입을 개발할 때 오버헤드(추가적인 메모리, 시간, 자원이 사용되는 현상)처럼 보일 수 있습니다.
• Presenter가 모든 것을 아는 클래스가 됩니다. 하지만 이는 코드를 더 많이 분해하고 단위 테스트가 가능한 클래스를 만들면 해결 가능합니다.

---

MVVM

 

MVVM

 

 

안드로이드 Databinding을 사용하는 MVVM은 테스트와 모듈화가 쉽고 View와 Model을 연결하기 위해 사용해야 하는 연결 코드를 줄일 수 있다는 장점이 있습니다.

• View : 사용자의 작업에 대해 ViewModel에 알립니다.
• ViewModel : View와 관련된 데이터 스트림을 노출합니다.
• Model : 데이터 소스를 추상화합니다. ViewModel은 Model과 함께 작동하여 데이터를 가져오고 저장합니다.

언뜻 보기에 MVVM은 MVP패턴과 매우 유사해 보입니다. 둘 다 View의 상태와 동작을 추상화하는 데 훌륭항 역할을 하기 때문입니다. MVP는 특정 UI와 독립적인 View를 추상화하는 반면에 MVVM은 사용자 인터페이스의 이벤트 기반 프로그래밍을 단순화하기 위해 생성되었습니다.

 

MVVM에서 ViewModel은 View가 바인딩할 수 있는 이벤트 스트림을 노출합니다. 이와 같이 ViewModel은 Presenter처럼 View에 대한 참조를 더 이상 보유할 필요가 없습니다. 이것은 또한 MVP패턴에 필요한 인터페이스가 이제 삭제되었음을 의미합니다.

 

또한 View는 ViewModel에 다른 작업에 대해 알립니다. MVVM 패턴은 View와 ViewModel 간의 양방향 데이터 바인딩을 지원하며 View와 ViewModel 간의 다대일 관계가 있습니다. View에는 ViewModel에 대한 참조가 있지만 ViewModel에는 View에 대한 정보가 없습니다. 데이터 소비자는 생산자에 대해 알아야 하지만 생산자(ViewModel)는 누가 데이터를 소비하는지 모르고 관심도 없습니다. 

 

MVVM의 장점

• 테스트하기가 쉽습니다.
• UI 요구사항이 다시 변경되면 쉽게 바꿀 수 있습니다.

 

MVVM의 단점 

• Activity와 Fragment의 코드가 많아질수록 유지보수가 힘듭니다.
• 중첩된 콜백이 많으면 코드를 변경하거나 새로운 기능을 추가하기 어렵고 이해하기가 어렵습니다.
• Activity와 Fragment에 많은 로직들이 구현되어 있어 단위 테스트가 가능하지만 어렵습니다.

반응형

출처👀
아키텍처 패턴이란
MVC
MVP
MVVM