[Architecture] MVC, MVP, MVVM 아키텍처 패턴

안녕하세요😊 오늘은 아키텍처 패턴 몇가지에 대해 정리해볼까 합니다!

아키텍처에 대해 공부해야겠다고 생각한 이유는 MVC 패턴으로 개발하며

VC가 모든 역할을 담당하다보니 점점 무거워지는 것을 느꼈고..

이러한 MVC 패턴의 단점에 대한 대안으로 MVVM 패턴이 있다는 것을 알게 되었습니다.

그래서 이번 포스팅에서 MVC, MVP, MVVM 아키텍처 패턴에 대해 차이점을 위주로 정리해보려고 합니다!

아키텍처 패턴이란?

먼저, 아키텍처 패턴이란 무엇일까요?

 

위키피디아에 따르면,

아키텍처 패턴이란, 주어진 상황에서의 소프트웨어 아키텍쳐의 공통적인 발생 문제에 대한 일반적인, 재사용 가능한 해결책을 의미한다. 아키텍처 패턴은 소프트웨어 디자인 패턴과 유사하지만 더 큰 범주에 속한다.

 

간단히 말하면, 아키텍처 패턴은 소프트웨어의 전체적인 그림, 구조를 만드는 해결책이라고 할 수 있을 것 같습니다.

MVC (Model-View-Controller)

먼저, 가장 기본적인 디자인 패턴인 MVC부터 살펴보겠습니다!

MVC 패턴은 Model, View, Controller 이렇게 세 가지 요소로 구성된 패턴입니다.

 

• Model: 데이터 처리 담당
• View: 사용자에게 보여지는 UI
• Controller: 사용자의 Input을 받고 처리

Controller로 사용자의 Input(입력)이 들어오게 되면, 데이터 처리를 담당하는 Model을 통해 데이터를 업데이트하거나 불러오고,

해당 데이터를 보여줄 View를 선택해서 화면에 보여지도록 합니다.

 

iOS에서의 MVC 패턴은 기존의 MVC 패턴과는 약간 다르게 동작합니다.

iOS에서는 View와 Controller가 강하게 연결되어있기 때문에 ViewController가 거의 모든 일을 담당합니다.

위의 그림과 같이 Controller의 역할은 UIViewContoller가 담당하여 Controller가 사용자 입력도 받고, 그에 대한 처리도 해서 그 결과를 화면에 뿌리는 것까지 모두 맡기 때문에 Controller가 거의 모든 일을 하게 됩니다.

View와 Controller의 강한 연결성 때문에 결국 Massive View Controller가 되는 문제가 발생하게 되는 것이죠..

그래서 등장하는 것이 바로 MVP 입니다.

MVP (Model-View-Presenter)

 

MVP 패턴은 Model, View, Presenter 세 가지 요소로 구성된 패턴입니다.

앞서 설명했던 MVC패턴에서의 단점이었던 Massive한 Controller의 역할을 분리하기 위해 고안된 패턴입니다.

 

• Model: 데이터 처리 담당
• View: 사용자에게 보여지는 UI
• Presenter: 로직에 대한 처리를 담당. View에서 요청한 정보를 Model로부터 가공하여 View로 전달

UIViewController가 MVC에서는 거의 모든 역할을 담당했지만, MVP패턴에서는 화면에 보여지는 UI만 담당합니다.

대신 Presenter가 화면에 어떤 것을 보여줄지를 처리해줍니다.

사용자의 Input을 받는 것은 View이지만, 사용자의 입력이 View에 들어오게 되면 View는 이를 Presenter에 알립니다.

Presenter는 Model의 데이터를 이용해 로직을 처리해서 View에서 요청한 것을 View로 다시 전달해주어 View를 갱신하는 역할을 합니다. 다시 말해, View는 화면에 출력하는 역할만 하고 데이터에 대한 처리는 Presenter와 Model이 담당하는 것으로 역할이 분리 된 것입니다. 

하지만, 그림과 같이 View와 Presenter가 1:1의 관계를 맺고 있기 때문에 공통된 로직으로 구성된 뷰라도 화면하나당 Presenter가 하나 더 필요하게 되어 코드가 더 늘어나거나 비효율적인 구성이 될 수 있다는 단점이 있습니다.

MVVM (Model-View-ViewModel)

MVVM 패턴은 Model, View, ViewModel 세 가지 요소로 구성된 패턴입니다.

앞의 두 패턴의 단점을 보완하기 위해 고안된 패턴으로, MV종류 중 가장 최근에 등장한 패턴입니다.

View와 Model의 역할은 MVP와 비슷하고 Presenter 대신 ViewModel이 View와 Model 사이의 중재자 역할을 한다는 것이 가장 큰 특징입니다.

 

• Model: 데이터 처리 담당
• View: 사용자에게 보여지는 UI
• ViewModel: View를 표현하기 위해 만들어진 View를 위한 Model. View와는 binding을 하여 연결 후 View의 액션을 받고 업데이트

View로 사용자의 Input이 들어오면 ViewModel에 알립니다. 

ViewModel은 필요한 데이터를 Model에 요청하고, Model로부터 받은 데이터를 가공해서 저장합니다.

이후, ViewModel이 View에게 이를 다시 전달해주진 않지만, data binding으로 인해 자동으로 View가 갱신됩니다.

여기서 data binding이란‼️
MVVM 패턴에서 필수적으로 요구되는 것으로, 쉽게 말해 Model과 UI요소 간의 싱크를 맞춰주는 것이라고 할 수 있습니다.
이 패턴을 통해 View와 로직이 분리되어 있어도 한 쪽이 바뀌면 다른 쪽도 업데이트가 이루어져 데이터의 일관성을 유지할 수 있습니다.View 부분을 SwiftUI로 하여 관련된 바인드를 Combine의 도움을 받아 할 수 있고, RxSwift를 활용하여 효율적으로 data binding을 구현하여 MVVM 패턴에 활용할 수 있습니다.

 

위의 그림에서 View와 ViewModel 사이의 화살표가 양방향이 아닌 것처럼 View가 ViewModel을 구독하기만 하고,

ViewModel은 가지고 있는 데이터 요소를 View의 요청에 따라 바꾸기만 하면 View가 이에 맞게 바뀌게 됩니다.

즉, UI와 관련된 값을 수정하는 것은 모두 View에서 이루어지기 때문에 ViewModel에서 View의 값에 대한 수정은 전혀 이루어지지 않으며 데이터 요소를 가지고만 있는 것입니다. View는 ViewModel을 바라보고 있으며 ViewModel의 데이터가 바뀌면 이에 따라 UI를 갱신합니다.

 

여기까지 MVC, MVP, MVVM 3가지 아키텍쳐 패턴 사이의 차이점에 초점을 맞추어 정리해보았는데요!

대표적인 아키텍처 패턴에 대해 이해하는 데 조금이나마 도움이 될 수 있으면 좋을 것 같네요 :)

긴 글 읽어주셔서 감사합니다😊😊

 

---

[참고자료]

https://www.youtube.com/watch?v=bjVAVm3t5cQ 

https://medium.com/ios-os-x-development/ios-architecture-patterns-ecba4c38de52

https://velog.io/@sangjin98/iOS-디자인-패턴MVC-MVP-MVVM-VIPER