MVC, MVP, MVVM 패턴

MVC 패턴

Model(모델), View(뷰), Controller(컨트롤러)로 이루어진 디자인 패턴입니다.
이 패턴은 주로 인터페이스를 가진 응용 프로그램에서 사용되며, 애플리케이션의 개발과 유지 보수를 쉽게 하기 위해 데이터, 프레젠테이션, 프로세싱을 서로 분리합니다.

 

MVC 패턴 (출처 : 면접을 위한 CS 전공지식 노트)

 

 

애플리케이션의 구성 요소를 세가지 역할로 구분하여 개발 프로세스에서 각각의 구성 요소에만 집중해서 개발할 수 있습니다.

재사용성과 확장성이 용이하다는 장점이 있고, 애플리케이션이 복잡해질수록 모델과 뷰의 관계가 복잡해지는 단점이 있습니다.

(🧑🏻‍💻 저는 여기서 모델과 뷰의 관계가 복잡해진다는 거에 궁금증이 생겼는데 밑에서 설명하겠습니다!)

 

🍓 Model (모델)

모델은 애플리케이션의 데이터인 데이터베이스, 상수, 변수 등을 뜻합니다.

 

1. 사용자가 편집하길 원하는 데이터를 가지고 있어야 한다.

: 예를 들어 사각형 모양의 박스 안에 글자가 들어 있다면 그 사각형 모양의 박스 위치 정보, 글자 내용, 글자 위치, 글자 포맷(utf-8 등)에 관한 정보를 모두 가지고 있어야 합니다.

 

2. 뷰나 컨트롤러에 대해서 어떠한 정보도 알 수 없어야 한다.

: 데이터의 변화가 일어났을 때, 모델이 직접 UI를 수정하는 로직을 가지면 안 된다는 의미입니다.

 

3. 변화가 있을 때, 변화에 대한 처리 방법을 구현해야 한다.

: 모델에 변화가 있을 때, 이벤트를 발생시켜 전달해야 하며, 이벤트에 반응하는 로직을 구현해야 합니다. (뷰에서 데이터를 생성하거나 수정하면 컨트롤러를 통해 모델을 생성하거나 갱신합니다.)

 

 

🍑 View (뷰)

뷰는 inputbox, checkbox, textarea 등 사용자 인터페이스 요소를 나타냅니다. 즉 모델을 기반으로 사용자가 볼 수 있는 화면을 뜻합니다.

 

 

1. 모델이 가지고 있는 정보를 따로 저장해서는 안된다.

: 값을 표시하기 위해, 모델이 가지고 있는 정보를 전달받는다. 그 정보를 유지하기 위해 임의의 뷰 내부에 저장해서는 안 된다.

 

2. 모델이나 컨트롤러와 같이 다른 구성요소들을 알면 안된다.

: 자기 자신을 빼고는 다른 요소를 참조하면 안 된다. 뷰는 데이터를 받고 표시해주는 역할만 합니다.

 

3. 변화가 있을 때, 변화에 대한 처리 방법을 구현해야 한다.

: 모델과 같이 변경이 일어나면, 변경을 알리는 이벤트를 받아 동작하는 로직을 구현해야 합니다.

 

🥑 Controller (컨트롤러)

컨트롤러는 하나 이상의 모델과 하나 이상의 뷰를 잇는 다리 역할을 하며 이벤트 등 메인 로직을 담당합니다. 또한 모델과 뷰의 생명주기도 관리하며, 모델이나 뷰의 변경 통지를 받으면 이를 해석하여 각각의 구성 요소에 해당 내용에 대해 알려줍니다.

 

1. 뷰와 모델에 대한 정보를 갖고 있다.

: 뷰와 모델은 서로에 대한 정보를 갖지 않습니다. 변경을 외부로 알리고, 수신하는 방법만 갖고 있는데 이를 컨트롤러가 중재자 역할을 하기 위해 뷰와 모델에 대한 정보를 갖습니다.

 

2. 뷰나 모델의 변경을 모니터링 해야한다.

: 뷰나 모델의 변경 이벤트를 받으면 해석하여 각각의 구성 요소에게 해당 내용을 알려야 합니다.

 

 

MVC 패턴을 지키기 위한 5가지 규칙

• Model은 Controller와 View에 의존하지 않아야 한다.
• View는 Model에만 의존해야 하고, Controller에는 의존하면 안된다.
• View가 Model로부터 데이터를 받을 때는, 사용자마다 다르게 보여주어야 하는 데이터에 대해서만 받아야 한다. 
• Controller는 Model과 View에 의존해도 된다.
• View가 Model로 부터 데이터를 받을 때, 반드시 Controller에서 받아야 한다.

5가지 규칙을 정리한 것

 

 

 

(🧑🏻‍💻 위에서 얘기한 모델과 뷰의 관계가 복잡해지는 것에 대한 설명입니다.)

View는 Controller에 연결되어 화면을 구성하는 단위 요소이므로 다수의 View를 가질 수 있습니다.
Model은 Controller를 통해 View와 연결되지만, Controller에 의해서 하나의 View에 연결될 수 있는 Model로 여러 개가 될 수 있어 View와 Model이 서로 의존성을 띄게 됩니다.
즉, 애플리케이션이 복잡해질수록 모델과 뷰 관계가 복잡해지는 단점이 있습니다. 몇 가지 이유는 다음과 같습니다.

1. 다양한 뷰와 모델: 복잡한 애플리케이션에서는 여러 개의 뷰와 모델이 필요할 수 있습니다. 이에 따라 각각의 뷰와 모델이 서로 다른 방식으로 상호 작용하게 되면서 복잡성이 증가할 수 있습니다.

2. 이벤트 및 상호 작용 처리: 사용자 입력이나 다른 이벤트에 대한 처리가 늘어날수록, 이를 효과적으로 관리하고 모델과 뷰 사이에서 데이터 흐름을 조절하는 것이 복잡해질 수 있습니다.

3. 프레젠테이션 로직의 증가: 뷰는 사용자에게 정보를 표시하는데 중점을 두고, 이로 인해 복잡한 프레젠테이션 로직이 추가될 수 있습니다.

이러한 문제를 완전히 해결하는 것은 어려울 수 있습니다. 따라서 대규모 애플리케이션에서는 추가적인 패턴이나 아키텍처 요소를 도입하여 복잡성을 관리하는 것이 일반적입니다. 예를 들면 MVP (Model-View-Presenter), MVVM (Model-View-ViewModel) 등의 패턴이 사용될 수 있습니다.

 

---

 

MVP 패턴

MVP 패턴은 MVC 패턴으로부터 파생되었으며 MVC에서 C에 해당하는 컨트롤러가 프레젠터(presenter)로 교체된 패턴입니다.

 

Presenter는 MVC의 Controller와 매우 유사하지만, 다른 점이 있다면 View에 남아 있는 모든 비즈니스 로직을 전부 Presenter로 통합하는데 차이점이 있습니다.

 

 

MVP 패턴

 

 

❓그렇다면 MVC 패턴과 MVP의 차이점은 무엇일까요?

MVC 패턴과 MVP의 차이점

MVC 패턴 View : Controller = n : 1

MVP 패턴 View : Presenter = 1 : 1

 

 

뷰와 프레젠터는 1:1 관계이기 때문에 MVP 패턴은 MVC 패턴보다 더 강한 결합력을 지닌 디자인 패턴입니다.

• MVC는 하나의 컨트롤러에서 여러 뷰를 컨트롤 할 수 있으나, MVP는 각 뷰마다 프레젠터가 할당됩니다.
• MVC에서는 컨트롤러에서 user event를 처리하지만, MVP는 뷰에서 user event를 받습니다.
• MVC의 컨트롤러에서 user evenet에 따른 데이터 로직을 수행합니다.
• MVP에서 뷰는 오로지 user event를 프레젠터로 전달만 합니다.

 

장점

: 뷰와 모델의 의존성이 없다는 점입니다. MVC 패턴의 단점이었던 뷰와 모델의 의존성을 해결할 수 있습니다.

단점

: 뷰와 프레젠터 사이의 의존성이 높아진다는 단점이 있습니다. 어플리케이션이 복잡해질수록 뷰와 프레젠터 사이의 의존성이 강해지는 단점이 있습니다.

 

 

간단히 요약하자면

MVC에서 컨트롤러는 주로 중재자 역할을 하고, 뷰는 직접적으로 업데이트됩니다.

MVP에서 프레젠터는 뷰에 직접적으로 연결되어 업데이트를 수행하며, 뷰와의 통신이 더 직접적입니다.

 

 

---

MVVM 패턴

MVVM 패턴은 MVC에 C에 해당하는 컨트롤러가 뷰모델(ViewModel)로 바뀐 패턴입니다.
이 패턴의 목표는 비즈니스 로직과 프레젠테이션 로직을 UI로부터 분리하는 것입니다.
두 로직을 UI로부터 분리하게 되면 테스트, 유지보수, 재사용성이 쉬워집니다.

 

 

 

ViewModel (뷰모델)

하나의 소프트웨어를 최대한 기능적으로 작은 단위로 분할해 테스트가 쉽고 큰 프로젝트를 관리하기 상대적으로 쉬운 도구입니다.
모든 입력은 View로 전달되며, ViewModel은 입력에 해당하는 로직을 처리하여 View에 데이터를 전달합니다.

 

 

MVVM 패턴은 Command 패턴과 Data Binding 두 가지 패턴을 사용하여 구현되었습니다.

Command 패턴과 Data Binding을 이용하여 View와 View Model 사이의 의존성을 없앴습니다.

ViewModel은 View를 따로 참조하지 않기 때문에 독립적이며 ViewModel : View  = 1 : n 관계입니다.

 

 

❗️여기서 잠깐

Command 패턴과 Data Binding이란❓

 

📍Command 패턴

: 요청을 객체의 형태로 캡슐화하여 사용자가 보낸 요청을 나중에 이용할 수 있도록 메서드 이름, 매개변수 등 요청에 필요한 정보를 저장 또는 로깅, 취소할 수 있게 하는 패턴 -> 행동패턴

 

(참고하시면 좋을 것 같습니다 :) https://refactoring.guru/ko/design-patterns/command)

 

📍Data Binding

: xml에 Data를 연결하는 작업을 말합니다. Android JetPack 라이브러리 중 하나입니다. 

 

 

 

장점 

: MVVM 패턴은 뷰와 모델 사이의 의존성이 없습니다.(MVP 패턴과 동일!)

또한 Command 패턴과 Data Binding을 사용하여 View와 View Model 사이의 의존성 또한 없앤 디자인패턴입니다. 각각의 부분은 독립적이기 때문에 모듈화 하여 개발할 수 있습니다.

 

단점 

: View Model의 설계가 어렵다.

 

 

참조

https://velog.io/@oyunseong/MVC-%ED%8C%A8%ED%84%B4%EC%9D%B4%EB%9E%80

https://beomy.tistory.com/43