1. MVC( Model - View - Controller ) 패턴
MVC 모델은 소프트웨어 공학에서 사용되는 소프트웨어 디자인 패턴입니다.
- Model
- 모델은 애플리케이션의 데이터를 의미하며, Database의 데이터를 조작하는 layer입니다.
- View
- 뷰는 사용자에게 보여지는 인터페이스를 의미하며, 웹에서는 HTML문서라고 생각하시면 됩니다.
- Controller
- 컨트롤러는 데이터(model)와 인터페이스(View)간의 상호 동작을 관리합니다.
- 즉, Model에 명령을 보내 데이터의 상태를 바꾸고, 어떤 화면을 사용자에게 보여줄지 View에 명령을 합니다.
사용자가 애플리케이션에 어떤 요청을 하는 순간부터 서버가 응답을 하기까지의 흐름은 다음과 같습니다.
- 브라우저가 페이지를 조회하기 위해 url을 입력하거나 링크를 클릭합니다. ( 요청을 보냄 )
- 라우터에서 url을 받아 적절한 Controller로 연결시킵니다.
- Controller에서는 응답을 보내기 위한 로직을 처리합니다.
- 데이터가 필요하다면 Model에서 데이터를 조회합니다. ( 쿼리를 통해 DB에서 데이터 조회 )
- 어떤 페이지를 사용자에게 보여줄지 렌더링을 해서 데이터와 함께 HTML문서를 응답합니다.
이 과정을 그림으로 표현하면 아래와 같습니다.
MVC 패턴을 사용하는 목적은 View와 Model사이에 Controller를 두어 View와 Model의 의존성을 없애기 위함입니다.
훌륭한 설계란 인터페이스 간의 의존성(Dependency)를 제거하는것에 있습니다.
의존성이란 애플(Apple) 회사를 예로 들어 말씀드리면 다음과 같습니다.
아이폰을 사면 아이폰 용 충전기, 이어폰을 사야하고, 아이폰 앱을 개발하려면 맥OS를 쓰는 것이 좋습니다.
즉, 애플 제품을 하나 구매하면 부가적으로 따라오는 제품들이 많습니다.
이렇게 애플 제품들끼리는 의존성이 깊습니다.
의존성이 깊으면 자사 제품을 계속 사용하도록 만들 수는 있겠지만, 다른 제품과의 호환성이 좋지 않게 되겠지요.
MVC 패턴은 이러한 의존성을 제거하기 위해 고안된 디자인 패턴입니다.
그러나 실제로는 View에서 Model을 이용하기 때문 View와 Model은 의존적입니다.
즉, Model이 업데이트 되면 View도 업데이트가 됩니다.
따라서 View와 Model의 의존성을 완벽하기 분리하기 위한 새로운 패턴이 등장했습니다.
2. MVP( Model - View - Presenter ) 패턴
MVP 모델은 MVC 모델의 Controller가 Presenter로 바뀐 것입니다.
Preseneter는 View의 인스턴스를 갖고 있으며 View에서 요청이 발생하면 이벤트에 따른 Model의 상태를 변경시킵니다.
즉, 철저하게 View와 Model를 분리시키고, View와 Model 사이에 다리 역할을 수행합니다.
MVC 패턴에서는 사용자 입력이 컨트롤러로부터 왔습니다.
대부분의 프레임워크에서 URL 요청을 받은 라우터는 컨트롤러로 연결됩니다.
그러나 MVP 패턴은 사용자 입력이 View에서 발생합니다.
쉽게 스마트폰을 생각하면 될 것 같습니다. ( 실제로 안드로이드 개발에 있어 MVP 패턴을 사용하곤 합니다. )
View에서 요청이 발생하면 Presenter로 전달하고 Presenter에서는 그 이벤트에 따른 Model의 상태를 업데이트 시킵니다.
Model이 업데이트 되면 Presenter에서는 그 결과를 다시 View에 전달하는 것이죠.
따라서 MVP 패턴은 View와 Model 간의 의존성을 분리시켰습니다.
그러나 View와 Presenter의 관계는 1 : 1이기 때문에 Presenter는 View와 의존성이 깊다고 할 수 있습니다.
MVP패턴 역시 View와 Presenter간의 의존성이 깊기 때문에 이 문제를 해결하려 새로운 패턴이 등장합니다.
3. MVVM ( Model - View - ViewModel ) 패턴
MVVM 모델은 MVC 모델의 Controller , MVP 모델의 Presenter 대신 ViewModel로 바뀐 모델입니다.
ViewModel은 View를 나타내기 위한 Model이라 이해하시면 됩니다.
MVVM 모델은 MVP 모델과 같이 View에서 입력이 들어옵니다.
입력이 들어오면 Command 패턴을 통해 ViewModel에 명령을 내리게 되고 ViewModel은 Model에게 필요한 데이터를 요청합니다.
Model은 ViewModel에 필요한 데이터를 응답하고 Data Binding을 통해 ViewModel의 값이 변화하면 바로 View의 정보가 바뀌게 됩니다.
즉, Command와 Data Binding을 통해 View의 의존성을 끊어버렸습니다.
이로써 View와 Model의 분리가 이루어졌고, MVP 패턴의 문제점을 해결되었습니다.
이상으로 MVC, MVP, MVVM 패턴에 대해 알아보았습니다.
MVC 패턴의 문제점을 해결하기 위한 것이 MVP 패턴이고, MVP 패턴의 문제점을 해결한 것이 MVVM 패턴이라고 해서 MVVM 패턴이 항상 좋고 옳지는 않습니다.
아직은 제가 어떤 상황에서 어떤 패턴을 사용해야 하는지 구분을 할 수는 없지만, 각 패턴마다 장단점이 있고 프로젝트 규모에 따라 적절한 선택을 하는 것이 중요하다고 생각합니다.
[ 참고 ]
https://magi82.github.io/android-mvc-mvp-mvvm/