[이론] MVC, MVP 패턴 + MVVM 패턴과 비교

목표

MVC와 MVP의 개념을 이해하고 그 차이점을 확인할 수 있다. 자신의 프로젝트에 따라 MVC, MVP, MVVM 등을 어떻게 적용할지 확인할 수 있으며 각각의 장단점을 서술할 수 있다.

---

1. MVC (Model + View + Controller)

MVC는 MVVM에서 모델, 뷰가 포함이 되어있으나 여기서 컨트롤러가 포함이 되어있다. MVVM과 3가지의 역할로 나눈 것은 맞는 것 같은데 이번에는 '무엇인가를 조종하는 듯한 역할'이 포함되어 있는 것이 특징이다.

 

'모델'이라고 하는 부분은 어플리케이션 상태의 데이터와 데이터 처리 부분이므로 일반적인 모델과 같다.

'뷰'라고 하는 부분은 사용자에게 보이는 시각적인 부분이므로 이것도 일반적인 뷰와 같다.

근데, 컨트롤러는 무엇인가? 

 

컨트롤러

- 모델로부터 데이터를 검색하고, 데이터를 뷰에 전달하여 사용자 인터페이스를 생성하도록 하는 역할을 한다.

 

이렇게 보듯이 뭔가 '생성'을 하도록 한다. 뭔가 '주문'을 하는 듯한 느낌이 강하다. 그럼 이것을 한번 도식화 하여 생각을 해보자.

 동작의 순서는 다음과 같다.

1. User가 Controller에게 Action을 부여한다 (Controller가 user의 Action을 받는다)

2. Controller는 Action을 '확인'한 다음에 어떤 Model에게 보낼지 등을 고려하여 Model을 업데이트 할 수 있도록 한다 (Manipulate라고도 한다).

3. Model은 DB나 파일처럼 데이터를 제어하고 그 결과를 return한다.

4. 그럼 return한 결과를 토대로 controller는 Model을 표시할 View를 선택한다.

5. View는 Model을 사용해 업데이트를 하면서 사용자에게 화면을 표시한다. 

 

정말 말 그대로 Controller이다. Model을 선택하여서 데이터의 정리와 View의 선택까지, 즉, 화면에 보여지기까지의 모든 중간 단계를 관리한다고 보면 된다. 이런 Controller에게 '선택된' view는 (1) Model을 이용해 직접 업데이트 하거나 (2)Model이 '알려주어(notify)'하여 업데이트 하거나 (3) 주기적으로 Model의 변경을 감지 하여 업데이트를 하는 방법을 취한다.

 

자, 이러한 MVC 모델은 또다시 두가지의 모델로 구분이 가능하다. 모델1과 모델2가 각각 그것인데 한번 다시 살펴보자.

 

모델1

뷰와 컨트롤러의 역할이 합쳐져있는 상태이다.  웹을 개발하다 보면 JSP(JavaServer Pages)라는 것을 종종 듣게 될 것인데, HTML코드에 JAVA 코드를 넣어 동적웹페이지를 생성하는 도구이다. 여기서 JSP라고 하는 것은 뷰와 컨트롤러의 역할을 모두 담당한다.

이렇게 보면 JSP는 뷰와 컨트롤러의 역할을 모두 하고 있으므로 설계가 간단하여 개발 속도가 빠르며 작은 프로젝트에 맞다는 단점이 있지만 JSP에 결국 Java라던가 Html, CSS 등이 모두 섞이게 되어 소스가 결국 복잡하여 읽기가 힘들어진다.

 

모델2

유지보수가 힘든 모델1의 경우 소형 혹은 개인 프로젝트에 적합하다면 모델2는 훨씬 더 대형 프로젝트에 적합하다. JSP는 여기서 뷰의 역할만 감당하고 컨트롤러의 역할은 Servlet이 맡는다. 서블릿이라고도 하는데 이 서블릿은 서버 쪽에 실행하여 클라이언트의 요청에 따라 동적으로 서비스를 제공하는 자바 클래스 이며, Java 코드 안에 HTML 코드가 있다. 

MVC1과 다르게 2에서는 사용자의 호출을 서블릿이 받아주고 여기서 비즈니스 로직을 수행하여 모델을 호출한다음 데이터를 요청하기 때문에, Html과 Java 코드가 분리되어 확장이 용이하고 유지보수가 수월해진다. JSP는 Java 코드를 사용하지 않고 JSTL을 사용하여 화면을 보여준다. 하지만 모델1과는 다르게 초기 개발 비용이 많이 발생하며 개발에 시간이 오래걸린다는 단점이 있다.

 

그럼 왜 MVC 패턴일까?

• Model과 View가 다른 컴포넌트에 종속하지 않는다.
• 어플리케이션의 확장성과 유연성이 유리하다.
• 비즈니스 로직과 UI의 분리가 가능하다.

그럼 왜 MVC 패턴이 아닐까?

• Controller가 연결성을 나타낸다는 것을 알 수 있다. 즉, 다수의 View를 가질 수 있다.
• Controller에 의해서 하나의 View에 연결되었던 Model이 여러개의 View와도 연결이 될 수 있어 View-Model간의 의존성이 강해진다.
• 결국 Model-View의 복잡한 연결이 발생하는 위험성이 존재한다.

 

2. MVP (Model + View + Presenter)

MV는 MVC와 동일하나 Controller 대신에 Presenter가 들어갔다. MVC와의 다른 점은 UI(View)와 로직(Model)을 분리하고 서로간의 상호작용을 Presenter가 중재함으로써 의존성을 낮춘다는데 그 의의가 있다.

 

'모델'이라고 하는 부분은 어플리케이션 상태의 데이터와 데이터 처리 부분이므로 일반적인 모델과 같다.

'뷰'라고 하는 부분은 사용자에게 보이는 시각적인 부분이므로 이것도 일반적인 뷰와 같다.

근데, 프레젠터는 또 무엇인가? 

 

Presenter

view로 부터 사용자의 입력 이벤트를 수신하고, 입력에 대한 처리 로직을 구현한다. 모델로부터 데이터를 검색하고 데이터를 가공하여 뷰에 전달한다. 이 과정에서는 뷰와 모델의 결합도를 줄여주어 의존성을 낮춰준다. 자 그럼 도식화를 해보자

조금 더 뭔가 간단해졌다. 작동방식은 다음과 같다.

1. 사용자의 Action이 View를 통해 들어온다.

2. View는 데이터를 Presenter에게 요청한다.

3. Presenter는 다시 Model에게 데이터를 요청한다.

4. Model이 Presenter에게 응답을 한다.

5. Presenter는 View에게 응답한다.

6. Presenter가 제공한 데이터로 View가 화면상에 나타낸다.

 

자, 왜 Presenter인지 알겠는가? 'Present'라고 하는 영어의 의미를 알고 있다면 대충 감이 올 것이다. 무엇가를 Present하다, 즉, 무언가를 계속 보여주면서 둘 사이를 계속해서 연결해주고 있는 형태이다. Presenter는 View와 Model의 인스턴스를 보유하고 있으며, Presenter와 View는 1:1의 관계이다.

 

그래서 왜 MVP 인가?

View와 Model의 의존성이 없다는 것이 가장 큰 장점이다. Presenter의 의도가 더 단순하고 명쾌하며, View에게 추가적인 요구를 통해 특정 정보를 표시하도록 방법을 알려주는 대신 표시할 내용만 알려주는 형태가 된다.

 

근데 왜 MVP는 아닌가?

의존성은 없더라도 결국 View와 Presenter간의 의존성은 높아진다. 결국 분리하기 어려운 Presenter를 추후에 발견하게 될 것이다.

 

 

어? 그럼 MVVM은 무엇인가? 뭔가 비슷했던 느낌이 드는데...

 

3. MVVM (Model + View + View model)

문득 보면 View Model만 변한 것 빼고는 아무런 차이가 없는 듯 하다. 뷰모델을 간략하게 다시 설명하자면 뷰가 필요로 하는 데이터와 동작을 정의 하고 뷰의 상태를 관리를 하며 뷰의 UI요소에 대해서 데이터를 가지고 있다. 이 데이터의 경우 모델에서 가져온 데이터를 가공한 결과이다. 뷰의 발생 이벤트를 처리하기도 하며 이벤트에 대한 액션을 수행한다.

 

그럼 작동방식도 한번 보자.

1. 사용자 Action이 View로 들어온다.

2. View에 Action이 들어오면, Command패턴을 통해 View Model에 Action을 전달한다.

3. View Model은 Model에게 데이터를 요청한다.

4. Model은 View Model에게 요청받은 데이터를 제공한다.

5. View는 View model과 Data Binding으로 화면을 나타낸다.

 

View와 Presenter의 의존성을 없앤 부분이 바로 이 2,5번 부분이다. Command 패턴과 Data Binding 패턴을 통해 의존성을 없앴다. View와 Viewmodel은 그래서 1대다의 관계로 연결 될 수가 있다. 모든 부분이 독립적이여서 모듈형 개발이 가능하다.

 

참고

- Command 패턴: 메서드 호출을 캡슐화 하여 객체화 하는 것이며, 이를 통해 재사용성이 높은 클래스를 설계하는 패턴이다.

- Data binding 패턴: 뷰와 뷰모델간의 데이터 연결을 자동으로 처리하여, 뷰의 데이터를 업데이트시 뷰모델에도 데이터가 자동으로 업데이트 하도록 만드는 패턴이다.

 

하지만 단점이 있다면 View Model의 설계가 생각보다 쉽지 않다는 점이다.

 

지금까지 MVC, MVP, MVVM에 대해서 알아보았다. 경험상으로 MVC 모델은 Django를 사용하면서 활용을 했었었고 MVVM의 경우 Flutter에서 많이 본듯하다. 혹자들은 자연어에 가까울수록 자동화된 디자인패턴을 많이 사용한다고 하던데, 아직 나같은 배울 것이 많은 사람에게 모든 언어는 자연어와는 상당히 떨어진듯하다. 

 

여튼 지금까지 배운 내용을 토대로 각각의 패턴들에 대해서 도식화를 그릴 수 있고 특정 단어들을 기반으로 동작원리를 설명할 수 있다면, 해당 패턴에 대한 개념을 크게 나마 잡을 수 있을 것이다.

 

참고

(1) Once Story (https://onejuny.tistory.com/entry/JavaJsp-MVC-1-MVC-2-차이-및-장단점)

(2) 코딩공부일지 (https://cocoon1787.tistory.com/733)

(3) 춤추는 개발자 (https://frtt0608.tistory.com/94)

(4) Wisdom (https://doqtqu.tistory.com/332)

(5) heejeong Kwon (https://gmlwjd9405.github.io/2018/07/07/command-pattern.html)