참고자료
MVC가 제일 먼저 나왔고 MVP, MVVM 순서로 등장했다.
따라서 순서대로 살펴보겠다.
초창기에는 소스코드를 한군데에 몰아서 코드를 작성했었다. 그렇게 하다 보니 프로젝트가 커지면서 소스코드의 규모가 커지고 가독성이 떨어져 유지보수가 어려워지는 현상이 있었다. 그래서 만들어진게 MVC패턴이다.
1. MVC패턴
Model-View-Controller의 약자로 애플리케이션을 세 가지 주요 구성 요소로 분리하는 디자인 패턴.
1) 뷰(View)
- 사용자 인터페이스를 담당. 화면상에 보여지는 부분이다.
- 사용자가 인풋을 발생시키면 Controller에 사용자 상호작용을 전달한다.
2) 모델(Model)
- 데이터와 비즈니스 로직을 나타낸다.
3) 컨트롤러(Controller)
- View와 Model을 연결하여 상호작용하는 중간 관리자 역할을 한다.
- 사용자의 인풋을 관리하고, Model을 업데이트하고, View를 새로고친다.
화면에 보이는 요소는 View가 담당, 데이터는 Model이 담당, 둘 사이에서 Controller가 컨트롤 해주는 디자인 패턴이다.
1) 사용자는 View를 보고 인풋
2) 들어온 인풋을 Controller가 받음
3) Controller가 인풋에 대한 처리를 진행함
- Controller는 모델에게 데이터를 요청
- Model은 View에게 데이터를 반환
4) 컨트롤러는 뷰에게 데이터를 이용해 아웃풋을 내보내라고 명령함
Controller가 너무 많은 역할을 담당해 코드가 복잡해지는 이슈가 있다.
이를 위해 나온 아이디어가 MVP패턴이다.
2. MVP패턴
Model-View-Presenter 약자
1) 뷰(View)
- 사용자 인터페이스를 담당. 화면상에 보여지는 부분이다.
- 사용자 인풋을 받아 Presenter에게 전달하고 Presenter로부터 받은 데이터를 화면에 표시
2) 모델(Model)
- 데이터를 관리하고 관련 비즈니스 로직을 처리한다.
3) 프리젠터(Presenter)
- View와 Model을 연결하여 상호작용하는 중간관리자 역할을 한다.
사용자의 이벤트를 받아서 처리하고 그 결과를 모델에 반영한다.
화면에 보이는 요소는 View가 담당하고 버튼 레이블 포함하여 전부 가져가게 되어 사용자로부터의 인풋도 View가 받는다. 데이터는 Model이 담당.
Presenter는 화면에 어떤 내용이 보여질지만 담당한다.
1) 사용자는 View를 보고 인풋
2) View는 들어온 인풋을 Presenter에게 전달
3) Presenter는 인풋을 처리
- Presenter는 Model에게 데이터를 요청
- Model은 Presenter에게 데이터를 반환
4) Presenter는 데이터를 통해 View에게 아웃풋을 내보내라고 명령함
MVC와의 차이점은 Presenter가 MVC의 Controller에서 화면만 떨어져 나간 중간관리자라는 점이다. Presenter는 View는가 어떤 요소를 보여줘야 할 지 결정만 해주고 인풋 아웃풋에 대한 모든 처리를 지니고 있지만 화면과는 상관이 없다. 따라서 View는와 Presenter가는 1:1관계로 의존성이 강하게 연결되어있다.
그런데 View의 개수가 많아지면 View를 하나 만들때마다 Presenter를 같이 만들어야했다. 비슷한 구성의 View여도 Presenter를 매번 만들어야했다. View에서 들어오는 인풋을 무조건 Presenter가 받아서 처리해야하기 때문에 View가 많으면 Presenter도 많아져서 귀찮아진다.
그래서 생겨난 패턴이 Presenter가 공통으로 처리하자는 아이디어로 생겨난 MVVM패턴이다.
3. MVVM패턴
1) 뷰(View)
- 사용자 인터페이스를 담당. 화면상에 보여지는 부분이다.
- ViewModel을 주시하며 필요한 데이터를 가져와 화면에 아웃풋한다.
2) 모델(Model)
- 데이터를 관리하고 관련 비즈니스 로직을 처리한다.
3) 뷰모델(ViewModel)
- 화면에 그려지는 데이터 요소만 가지고 있는다.
- View에게로부터 인풋을 전달받고 Model과 상호작용하여 데이터를 받는다.
1) 사용자는 View를 보고 인풋
2) View는 들어온 인풋을 ViewModel에게 전달
3) ViewModel은 인풋을 처리
- Model과 교류하며 데이터를 받음
4) View는 ViewModel을 주시하고 있다가 필요한 데이터가 들어오면 데이터를 가져가 사용자에게 아웃풋을 내보냄
여러 화면 View가 있더라도 비슷한 데이터를 가지고 있다면 ViewModel을 공유할 수 있다.
UI와 데이터 로직이 분리되어있어 관리가 쉽지만 간단한 애플리케이션에 MVVM을 적용하면 오히려 코드가 복잡해질 수 있다.
정리하자면 MVC, MVP, MVVM 중 어느 하나가 최고다가 아닌 본인의 방식, 프로젝트의 특성에 맞게 설계하면 되겠다.
