MVC와 MVP의 차이

이전에 MVC와 MVP가 무엇인지에 대해서 알아보았습니다.

오늘은 MVC가 왜 등장했고, 둘의 차이를 조금 더 쉽게 설명하겠습니다.

프로그램에서 순수한 데이터 파트만 나눈 부분을 Model(모델)이라고 합니다.
MVC에서 View는 순수하게 화면에 보여주는 것만 분리한 부분을 말합니다.

프로그래밍 초창기에는 데이터와 뷰가 너무 타이트하게 연결되어 있었는데요.
그래서 코드를 작성하는 것도 어려웠고, 읽기도 어려웠습니다.

처음에는 모델이란 개념 조차 없었습니다.
프로그램을 짤 때,
데이터 클래스1, 데이터 클래스2, 데이터 클래스3, 데이터 클래스4 …
View1, View2, View3, View4 …
아래 그림처럼 만든 다음

View1는 데이터 클래스 1,2,3가 필요하고,

View2는 데이터 클래스 1,2,5가 필요하고,

View3는 데이터 클래스 2,3,4가 필요하고,,,
필요한 애들끼리 이었습니다.

그러다보니 코드가 엉키게 되면서 너무 복잡하게 되고 코드를 읽을 수가 없었습니다.
그래서 "아! 이 방식은 아닌가보다. 이렇게하면 안된다." 라는 생각을 하게 되었습니다.

그렇다면 "어떻게 해야 이 복잡한 구조를 쉽게 바꿀 수 있을까?" 라는 고민을 했습니다. 그러다가 이 문제를 해결하기 위해 중재자 패턴(Mediator Pattren)이 등장하게 되고, MVC 아키텍처가 나오게 되었습니다.

둘의 차이를 간략하게 설명하자면.
중재자 패턴은 객체 간의 상호작용을 관리하고 조정하기 위한 패턴이며, 객체 간의 결합도를 낮추는 데 중점을 둡니다.
반면에 MVC 패턴은 애플리케이션의 구조를 분리하여 관리하기 위한 패턴으로, 사용자 인터페이스와 비즈니스 로직을 분리하고 각 요소의 역할을 직접적으로 정의 합니다.

기존에는 필요한 것들을 막 가져다 썻지만 MVC에서는

View ↔ 컨트롤러 ↔ Model(Data Class)

이제는 View와 Data Class가 직접 적으로 연결된 것이 아니라 컨트롤러를 통해 서로 연결시킵니다.

초창기 MVC는 직접적인 데이터, 직접적인 UI 직접적으로 이 둘을 관리하는 컨트롤러.

이렇게 해서 코드를 짰더니 어떤 문제가 발생했을까?

이 UI가 플랫폼에 너무 의존적이었습니다. 예를 들어 웹이면 HTML로 구현해야 하고, 안드로이드면 안드로이드, IOS면 IOS로 구현해야 합니다.

데이터가 안바뀌는 상황에서 내가 플랫폼을 바꾸면 컨트롤러를 바꿔야한다는 것입니다.

그러면 안드로이드용 컨트롤러, IOS용 컨트롤러 웹용 컨트롤러,, 플랫폼마다 각각의 컨트롤러가 필요하다는 것입니다.

그러면 플랫폼을 바꾸면 데이터 빼고 컨트롤러 뷰는 바뀌어야 합니다.

MVC에는 위와 같은 문제들이 있었습니다.

그러면 이 문제를 어떻게 해결해야할까요?
그러면 데이터는 똑같고, 뷰가 있는데 뷰의 개념을 바꾸자.

MVC에서는 화면에 직접적으로 보여지는 구체적은 것을 View라고 하는데 MVP에서는 V가 추상화 되어있는 개념입니다.

MVC에서 V는 구체적인 V이지만 MVP에서의 V는 추상화된 개념이다.
어떤 정해진 UI 표시 역할을 하는 것. UI 인터렉션 역할을 하는 어떤 기능으로 추상화 했습니다.
그래서 MVP에서 V는 구체적인 View가 아니고, View Interface라는 얘기입니다.

인터페이스에서 하는 기능을 예시로 들면 showMoney() 같은 추상화된 기능들.
draw(), name(), picture(), hideMoney() 함수 같이 추상화된 기능 정의됩니다.
View가 직접적으로 무엇을 그리는지, 보여주는지 숨기는지 정의되지 않습니다.

실질적으로 interface View를 구현하는 클래스가 만들어질 것이고, 실제 UI들의 Hierarchy(계층)이 만들어집니다.

만약 mock을 만들겠다고 하면 mock이 되는 것이도, 아니면 IOS용 implementation, 안드로이드용 implementation으로 만들 수 있다는 것입니다.

이것이 OCP이고 DIP, SRP입니다.
이것이 MVP의 목적입니다.

그렇다면 Android에서 MVC를 적용했을 때, Activity의 역할은 무엇일까?

결론부터 말하자면 Activity는 View입니다.
보통 안드로이드에서 MVC 패턴으로 앱을 만든다고하면 Activity에서 모델 데이터를 받아오고 UI를 컨트롤하지 않는가? 라고 생각할 수 있습니다.
그래서 Android의 전통적인 MVC에서는 이 역할을 담당하는 클래스를 명확하게 정의하기 어렵습니다.

전통적인 MVC에서는 Activity가 UI 역할을 하면서 동시에 사용자 입력 처리와 비즈니스 로직을 담당하는 경우가 많았습니다.

이는 코드의 복잡성을 증가시키고 테스트의 어려움을 가져오는 단점을 가지고 있습니다.

그래서 가장 큰 차이가 뭘까?

명확하게 한단어로 말하자면 컨트롤러입니다.

MVC의 View와 MVP의 View는 다릅니다.
MVP에서 V는 무조건 인터페이스로 추상화한 contract를 써서 정의해야합니다.
안드로이드에서 MVC에서는 Activity가 View가 될 수 없습니다.
직접적인 View가 아니기 때문입니다.
MVP에서는 Activity가 View가 될 수 있습니다. View의 역할을 하게 만들 수 있습니다.