MVC VS MVP VS MVVM

MVC, MVP, MVVM이라는 아키텍쳐 디자인 패턴을 공부하면서 느낀 것은 플랫폼마다 적절한 아키텍쳐가 있다는 것입니다.

Spring에서는 MVC가 가장 적절한 이유가 있고, Android에서는 MVVM이 현재 대세인 이유가 있는 것 같습니다. 또한 각 플랫폼마다 각 아키텍쳐의 구조도 조금씩 달라지니 유의하시기 바랍니다.

 

# 왜 아키텍쳐 디자인 패턴이 필요할까?

화면에 무언가 데이터를 보여주기 위해서는 데이터를 생성하고, 관리하는 Model이 필요하고, 이 데이터를 사용자에게 UI로 보여주기 위한  View는 공통적으로 필요합니다. 이렇게 Model, View만 사용하게 된다면 둘 사이의 의존성이 심해지고, 이는 이후 변경사항이 생겼을 때 유지보수에도 좋지않고, 테스트 코드를 짤 수도 없을 것입니다.

이러한 이유때문에 Model과 View사이에 관계를 어떻게 할것이냐에 따라 MVC, MVP, MVVM과 같은 패턴이 있습니다.

 

각 패턴에 M, V에 대한 용어는 공통적인 의미를 갖고 있습니다.

 - Model : (화면에 보여질 '무엇')실제 보여줘야할 데이터를 생성, 업데이트 등의 관리 (DB에서 가져오는 데이터 일수도, 서버로 부터 가져오는 데이터일 수도 있습니다.), 또한 내부 비즈니스 로직도 포함됩니다.

 - View : 데이터를 사용해 실제 사용자에게 보여질 UI, 프레젠테이션 로직은 화면에 어떤식으로 보여줄지 View에 관련한 로직이기 때문에 여기에 포함된다고 생각합니다.

 

 

# MVC

가장 기본이되는 패턴이면서 안드로이드, iOS, 서버 등 플랫폼마다 형태가 다른 패턴이기도 합니다. 사실 저는 MVC를 공부하면서 Spring에서는 이렇게 처리되지 않는것 같은데.. 이런 생각을 많이 했는데, 그 답은 플랫폼마다 패턴이 달랐기 때문이었습니다.

# original MVC 

https://medium.com/@esung/mvc-정말제대로알고계신가요-875f1323f6c0

Controller : 사용자로부터 요청이 들어오는 곳, Model과 View를 알고 있으며, 요청에 맞는 Model을 찾아 업데이트하고, 요청에 맞는 View를 찾아 화면에 보여질 수 있도록 합니다.

하지만, Model은 Controller를 알지 못합니다. Model의 의존관계를 줄여 테스트가 가능하다는 의미가 될 것입니다.

 

- 사용자에게 요청이 들어올 때 처리 과정

1. Controller가 요청을 보고 model의 업데이트가 필요한지를 판단합니다.

[Model의 업데이트가 필요하지 않은 경우]

2. Controller가 요청에 맞는 View를 선택해 update하도록 합니다. View에 맞는 데이터는 View가 Model의 변화를 감지함으로써 데이터를 가져오게 됩니다.

[Model의 업데이트가 필요한 경우]

2. Model은 데이터에 대한 업데이트를 수행합니다. Model은 Controller를 알지 못하므로, Controller로 부터 알게된 요청에 맞는 View에게 notify를 보냅니다.
3. View가 update를 하며, 그에 대한 데이터는 View가 Model의 변화를 감지함으로써 데이터를 가져옵니다.

 

이걸 보고 사실 저는 몇가지 의문점이 생겼습니다.
1. Model이 Controller를 알면 Model과 View와의 의존관계가 완전히 사라질 수 있는데, 왜 이렇게 할까?
2. Spring에서는 request를 받은 Controller가 model을 update시키고 리턴을 받은 다음, 알맞은 뷰에게 model에서 업데이트 된 데이터를 넘겨주는 형태로 저 구조와는 다른데...?? 

그래서 더 찾아보니 오리지널 MVC 패턴외에 또 다른 Cocoa MVC패턴이 있었습니다.

# Cocoa MVC

https://medium.com/@esung/mvc-정말제대로알고계신가요-875f1323f6c0

엇...? MVP 패턴과 상당히 비슷합니다. 그리고 이게 제가 아는 Spring에서의 MVC와도 유사하고, 찾아보니 iOS에서 권장하는 MVC패턴도 이러한 구조였습니다. (iOS MVC패턴 공식 문서)

왜 애플에서 그럼 MVP패턴을 쓴다고 하지 않고 MVC를 쓴다고 했을까? 그 답은 애플이 이 패턴을 정립할 당시 MVP패턴은 상대적으로 새롭고 덜 알려져있었기 때문이라고 합니다.

 

안드로이드에서의 MVC는 위 두개와 다른데, 따로 포스팅할 계획입니다.

 

다시 돌아와 전통 MVC의 단점은 Model과 View사이의 의존관계입니다. Cocoa MVC와 상당히 비슷한 MVP패턴은 이 단점을 해소했습니다.

 

# MVP

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

MVC와의 차이점은 두가지가 있습니다.

사용자의 입력이 View로 들어온다는 것.

Controller가 아닌 Presenter로 바뀌었는데, Presenter를 통해 Model과 View사이의 의존관계를 완전히 없애게 됩니다.

로직을 보면

출처 : https://brunch.co.kr/@oemilk/75

사용자의 입력이 View로 들어오면 Presenter에게 이벤트를 호출하고, Presenter가 적절한 Model을 업데이트합니다.

Model이 업데이트 한 결과를 Presenter에게 전달하고, Presenter가 다시 View에게 view를 업데이트하도록 전달합니다.

즉, View는 수동적인 존재로 Presenter가 업데이트를 하라고 해야 업데이트 하는 형태입니다.

 

- MVP패턴의 단점

위에서 보시다시피 View와 Presenter는 1:1관계입니다. 이 때문에 View가 많아질수록 Presenter도 많아지게 되는데, 특히 로그인이나 서로 다른 뷰에서 같은 데이터를 불러와야하는 로직이 있다면 코드 중복이 발생하는 단점이 있습니다. (물론 Presenter의 중복코드를 추상화 시킬 수 있지만 구조가 더 복잡해지기 때문에 근본적인 해결책은 아니라고 생각합니다.)

 

# MVVM

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

MVP패턴의 단점을 보완한 것으로 Presenter가 아니라 ViewModel을 사용합니다. ViewModel은 View에 사용되는 Model이라는 의미로 View에 보여질 데이터나 메소드를 구현합니다. View와 ViewModel의 관계를 보면 View는 ViewModel을 알고 있지만, ViewModel은 View를 알지 못하는데, 주로 커맨드 패턴이나 데이터 바인딩을 이용한다고 합니다. (FE쪽에서도 MVVM패턴을 쓴다고 하는데 여기에 적용되는 방식이지 않나 싶습니다. 안드로이드에서는 데이터 바인딩과 LiveData나 StateFlow같은 것을 이용해 해결하는데 LiveData는 옵저버 패턴이 좀 더 적합하다고 생각하기 때문입니다.)

이를 보면 MVP와 다르게 View는 좀 더 능동적이며, View와 ViewModel의 관계도 1:N도 가능하고 N:1도 가능하게 더 유연한 형태로 바뀔 수 있게 됩니다.

 

출처 : https://medium.com/@bansooknam/android-아키텍처-비교-mvp-mvvm-svc-1-f24e5f338523, https://brunch.co.kr/@oemilk/113