[Design Pattern] MVC, MVP, MVVM 패턴 비교 및 정리

MVC, MVP, MVVM은 모두 소프트웨어 개발에서 사용되는 디자인 패턴으로, 애플리케이션의 구조와 역할을 분리하여 코드를 더 잘 구성하고 유지보수성을 높이기 위해 고안된 패턴들입니다. 이번 포스트에서는 각 패턴의 주요 차이점과 특징들을 정리하겠습니다.

MVC 패턴

MVC패턴은  View와 Model 사이의 중개자 역할을 수행하는 Controller를 두는 패턴입니다. 이를 통해서 View는 사용자 인터페이스에 집중할 수 있고, Model은 데이터와 비즈니스 로직에 집중할 수 있게 해줍니다.

MVC 패턴 구조

 

MVC 패턴은 Model, View, Controller 세 부분으로 나눕니다. MVC의 각각의 세 부분은 다음과 같은 역할을 합니다.

 

Model -> Model은 데이터와 비즈니스 로직을 담당합니다.

View -> View는 사용자 인터페이스를 담당하는 부분으로 모델의 상태를 시각적으로 보여주며 사용자 입력을 받습니다.

Controller -> Controller는 View와 Model간의 중재를 통해 의존성을 낮추기 위한 논리적 계층으로 UI로부터 들어오는 요청의 처리를 담당합니다. 들어온 요청을 Model을 통해 데이터를 처리하고 업데이트 된 결과물을 다시 View에게 전달합니다.

특징

Controller가 View와 Model 사이를 중재하여 View와 Model 사이의 의존성을 낮춤 -> View와 Model 사이의 의존성이 낮아지기는 하지만 완전한 분리는 이루어지지 않습니다.

Controller와 View는 1:N 관계 -> 하나의 Controller는 여러 개의 View를 처리할 수 있기 때문에 같은 데이터를 기반으로 다양한 뷰를 만들 수 있습니다. 사용자의 입력에 따라 해당 View와 Model을 업데이트하는 역할을 Controller가 수행하게 됩니다.

장점

코드의 분리 -> MVC 패턴은 Model, View, Controller로 애플리케이션의 구조를 나누어 개발하므로 각 부분을 독립적으로 개발할 수 있습니다.

빠른 개발 프로세스 -> 구현이 쉬워 빠르게 개발할 수 있습니다.

단점

프로젝트가 커질수록 코드가 복잡해짐 -> Controller와 View가 1:N 관계이므로 프로젝트가 커질수록 Controller 또한 커지며 Controller가 여러 View와 상호작용하게 되면 특정 기능의 코드가 Controller에 중복될 수 있습니다.

각 구성 요소들 사이에 의존성이 높음 -> View와 Model 사이의 의존성이 높고, View와 Controller 사이의 의존성 또한 양방향 통신으로 인해 의존성이 높으므로 유지보수가 어려울 수 있습니다.

 

요약하면, MVC 패턴은 코드의 구조화와 유지보수를 향상시키는 데 많은 장점을 가지고 있지만, 대규모 애플리케이션에서 복잡성이 증가하고 중복 코드가 발생할 수 있습니다. 이를 이해하고 잘 활용하면 강력한 아키텍처 패턴으로서 사용할 수 있습니다.

MVP 패턴

MVP 패턴은 View와 Model 사이에 Controller 대신에 Presenter를 두어 MVC에서 발생하는 문제점을 해결하기 위해 만들었으며, View와 Model 사이의 의존성을 낮추고 테스트를 용이하게 만든 패턴입니다. 하지만, View와 Presenter 사이의 의존성이 높은 편입니다.

MVP 패턴 구조

 

MVP 패턴의 각각의 세 부분은 다음과 같은 역할을 합니다.

 

Model -> Model은 데이터와 비즈니스 로직을 담당합니다.

View -> View는 사용자 인터페이스를 담당하는 부분으로 모델의 상태를 시각적으로 보여주며 사용자 입력을 받습니다. MVC와는 달리 View는 Model에 직접 접근하지 않고 Presenter를 통해 상호 작용합니다.

Presenter -> Presenter는 사용자 입력을 받고, Model을 업데이트하며 View에게 데이터를 전달합니다. 이때 View와 Model은 서로 직접적으로 알지 못하며, Presenter가 인터페이스를 통해 중재자 역할을 수행합니다. 

특징

View와 Model의 완전한 분리로 독립성이 보장됨 -> MVP 패턴은 Presenter로 인해 View와 Model 사이의 의존성이 없고 뷰와 비즈니스 로직을 분리하여 테스트 용이성과 유지보수성을 개선할 수 있습니다. 

View와 Presenter는 양방향 관계이며 1:1 관계 -> View를 만들면 Presenter 하나를 추가해야 합니다.

장점

View와 Model의 독립성이 보장됨 -> View는 Model에 직접 접근하지 않고 Presenter를 통해 상호 작용하므로 뷰와 모델은 서로 완전히 분리되며 각각을 독립적으로 테스트하기 더 편해집니다.

View와 Busniess logic 사이의 분리로 인해 코드의 가독성이 높아짐 -> View는 사용자 인터페이스에만 집중하게 되고, Presenter는 Busniess logic에만 집중할 수 있으므로 코드의 가독성이 높아집니다. 

단점

Presenter의 복잡성 증가 ->  Presenter가 View와 Model 사이의 중재하는 역할을 수행하기 때문에 Presenter의 코드가 복잡해질 수 있습니다. 특히, 대규모 애플리케이션에서는 관리하기 어려울 수 있습니다.

View와 Presenter사이의 의존성이 강해짐 -> View와 Presenter는 1:1 관계이므로 View를 추가할 때 마다 Presenter 하나가 추가로 필요하므로 구조가 복잡해지고 코드 양도 많아질 수 있습니다.

 

요약하면, View는 오직 Presenter에만 의존하고, Model에 대한 직접적인 접근이 없습니다. View는 사용자 입력을 Presenter에게 전달하고, Presenter는 Model에게 필요한 작업을 지시하고 다시 View에게 업데이트를 전달합니다. MVP 패턴은 뷰와 비즈니스 로직의 완전한 분리로 인해 많은 장점을 가지고 있습니다. 하지만, Presenter의 복잡성과 코드 양의 증가 등의 단점도 고려해야 합니다.

MVVM 패턴

MVVM 패턴은 마찬가지로 View와 Model 사이에 ViewModel을 두어 View와 Model 사이의 의존성을 해결했을 뿐만 아니라 View와 Controller 사이의 양방향 의존성까지 해결한 아키텍처입니다.

MVVM 패턴 구조

 

MVVM 패턴의 각각의 세 부분은 다음과 같은 역할을 합니다.

 

Model -> Model은 데이터와 비즈니스 로직을 담당합니다.

View -> View는 사용자에게 보여지는 UI 부분이며 데이터 바인딩을 통해 데이터의 변화를 업데이트합니다.

ViewModel -> ViewModel은 View를 그리기위한 Model들을 포함합니다. ViewModel과 MVP 패턴의 Presenter의 주요 차이점은 Presenter는 View에 대한 참조가 있는 반면 ViewModel은 View를 참조하지 않는다는 점입니다. 그렇다면 ViewModel은 View를 어떻게 업데이트 시키지 할 수 있는데, View는 ViewModel의 프로퍼티에 직접 바인딩하여 View를 업데이트합니다. 그러므로, 효율적으로 동작하기 위해서는 데이터 바인딩을 위한 기술이 필요합니다.

특징

View와 Model의 완전한 분리로 독립성이 보장됨 -> MVVM 패턴은 ViewModel로 인해서 View와 Model 사이의 의존성이 없기 때문에 뷰와 비즈니스 로직을 분리하여 테스트 용이성과 유지보수성을 개선합니다. 

View는 ViewModel에 대해 단방향 의존성을 가짐 -> View는 ViewModel에 대해 데이터 바인딩을 통해 View를 업데이트 하므로 ViewModel은 View에 대한 참조가 없습니다.

View와 ViewModel는 N:1 관계 -> 즉, 하나의 ViewModel이 여러 개의 View와 연결될 수 있습니다. 이는 MVVM 패턴이 여러 개의 View에서 동일한 데이터를 사용하고자 할 때 유용하게 사용될 수 있기 때문입니다. 여러 개의 View가 동일한 데이터를 사용하는 경우가 많습니다.

View와 ViewModel 사이의 연결은 데이터 바인딩을 통해 이루어짐 -> View는 ViewModel의 데이터를 바인딩하여 ViewModel의 상태를 통해 View를 업데이트 하며 사용자 입력을 ViewModel로 전달합니다. 반대로, ViewModel은 View에 대한 참조를 가지지 않고, 순수한 비즈니스 로직과 상태를 처리하며, 필요한 데이터를 View에 제공합니다. 또한, 데이터 바인딩을 통해 코드 중복을 줄이고, 데이터의 일관성과 업데이트의 효율성을 높일 수 있습니다. 따라서, MVVM은 많은 현대적인 프레임워크와 플랫폼에서 많이 사용되는 아키텍처 패턴 중 하나입니다.

장점

View와 ViewModel 간의 데이터 바인딩 -> 데이터 바인딩을 통해 View와 ViewModel 사이의 동기화를 자동화하므로, 수동으로 View를 업데이트하는 코드를 작성할 필요가 없으므로 코드가 간결해집니다.

코드의 유지보수성이 높아짐 -> 코드의 분리로 인해 특정 부분을 수정할 때 전체 코드를 수정할 필요가 없습니다. 따라서 유지보수가 용이하며, 새로운 기능 추가나 버그 수정 등이 훨씬 간단해집니다.

코드의 확장성이 높아짐 -> 새로운 기능을 추가하거나 기존 기능을 수정할 때 기존 코드의 영향을 최소화할 수 있으므로 애플리케이션의 확장성을 높일 수 있습니다.

테스트 하기 쉬워짐 -> 각 부분을 독립적으로 테스트할 수 있기 때문에 단위 테스트 작성이 용이합니다. Model, View, ViewModel 각각을 테스트하여 애플리케이션의 안정성을 높일 수 있습니다.

단점

낮은 호환성 -> 모든 플랫폼에서 사용할 수 있는 것은 아니며 UI 컴포넌트의 자동 업데이트를 위해 데이터바인딩을 위한 Observable을 설계해야합니다.

데이터 바인딩의 오버헤드 -> 잘못된 데이터 바인딩의 사용은 많은 메모리 소모 및 잦은 UI 리빌드를 야기할 수 있으며 앱의 성능을 저하시킬 수 있습니다.

학습 곡선이 높음 -> MVVM 패턴은 처음 접하는 개발자들에게는 학습 곡선이 높을 수 있습니다. 특히, 데이터 바인딩 및 관련 라이브러리를 이해하고 적용하는 데 어려움을 겪을 수 있습니다.

 

요약하면, MVVM 패턴은 뷰와 비즈니스 로직의 완전한 분리로 인해 많은 장점을 가지고 있습니다. 하지만 처음 사용하는 개발자들에게는 학습 곡선이 높을 수 있으며 오버헤드가 발생할 수 있습니다. 하지만, MVVM 패턴을 잘 활용하면 가장 장점이 많은 패턴이라고 할 수 있으며 프로젝트의 특성에 맞게 사용하는 것이 중요합니다.

정리

이번 포스트에서는 MVC, MVP, MVVM 각 패턴의 특징과 장단점들을 정리해보았는데, 어떤 패턴이 가장 좋고 나쁘고 할 것 없이 각 패턴마다의 장단점이 존재하므로 프로젝트의 특성에 맞는 패턴을 고르는게 중요할 것 같습니다.

References

https://beomy.tistory.com/43

[디자인패턴] MVC, MVP, MVVM 비교

https://brunch.co.kr/@oemilk/113

MVC, MVP, MVVM, MVI

StudyFork 아키텍처 스터디

StudyFork