MVC vs MVP vs MVVM

▩ 목 차 ▩

1. 디자인 패턴

      1-1. 디자인 패턴이 뭘까?

      1-2. 디자인 패턴이 왜 필요할까?

      1-3. 나는 안드로이드를 공부하고 있고 여기선 VIEW를 사용한다. 그렇다면 VIEW를 사용하는 디자인 패턴의 특징은 무엇일까?

      

2. MVC 패턴

      2-1. MVC 패턴의 구조인  뷰(View), 모델(Model), 컨트롤러(Controller)에 대해 알아보자.

      2-2. MVC 패턴의 동작

      2-3. MVC 패턴의 특징

      2-4. MVC 패턴의 장점

      2-5. MVC 패턴의 단점

 

3. MVP 패턴 

      3-1. MVP 패턴의 구조인  뷰(View), 모델(Model), 프레젠터(Presenter)에 대해 알아보자.

      3-2. MVP 패턴의 동작 

      3-3. MVP 패턴의 특징

      3-4. MVP 패턴의 장점

      3-5. MVP 패턴의 단점

      

4. MVVM 패턴

      4-1. MVVM 패턴의 구조인  뷰(View), 모델(Model), 뷰 모델(View Model)에 대해 알아보자.

      4-2. MVVM 패턴의 동작

      4-3. MVVM 패턴의 특징

      4-4. MVVM 패턴의 장점

      4-5. MVVM 패턴의 단점

      4-6. MVVM 패턴 혹은 다른 디자인 패턴을 공부하려는 방법

 

---

( 개인사정으로 인해 개발 공부를 많이 하지 못할 것 같기에 f-lab의 수강을 2개월 정도 멈추었다.  원래 정지는 안되는것인데, 매니저님과 멘토님께서 편의를 봐주셔서 멈추게 되었다.. 정말 감사합니다.... 다시한번 말하지만 멈추는것은 안되는것이다.. )

나는 그래도 계속해서 시간을 내서 개발공부를 하려고 했고, 기업들이 요구사항에 많이 있는 MVVM 패턴에 대해 공부를 해보려고 한다.

MVVM과 같은 패턴을 디자인 패턴이라고 하는데, MVVM 패턴에 대해 공부하기 전에 디자인 패턴에 대해 공부를 하고 그 후, MVC, MVP, MVVM에 대한 이론공부를 하고 다음시간에는 예제를 직접 해봄으로써 몸으로 익혀보려고 한다.

MVC와 MVP에 대한 이론을 설명을 하며, MVVM과 비교하여 각각의 어떤 특징이 있는지 공부를 한 것을 설명하겠다.

---

 ■ 1. 디자인 패턴 ■

 

 ■ 1-1. 디자인 패턴이 뭘까?

단순하게 말하자면, 소스코드나 사용에 필요한 리소스를 어떤 방식으로 구조를 만들고 사용하는 것이다. 

 

 ■ 1-2. 디자인 패턴이 왜 필요할까?

무작정 막 짠 코드를 유지보수를 하려고 하는데 하나의 소스에 10만라인이 짜여져 있다고 가정을 하자. 만약 이것을 추후에 유지보수를 하려면 어디에 어떤 코드가 있고 그것을 고치는 것을 쉽지 않을 것이다. 이를 해결하기 위해 디자인 패턴을 사용하여 코드를 짜 유지보수를 용이하게 한다. ==> 이렇기에 디자인 패턴의 방식은 천차만별이다.

 

 ■ 1-3. 나는 안드로이드를 공부하고 있고 여기선 VIEW를 사용한다. 그렇다면 VIEW를 사용하는 디자인 패턴의 특징은 무엇일까?

그냥 소스를 짜도 프로그램은 동작하나, 너무 무작정 코드를 작성하면 소스가 몰리는 경향이 있다. 그렇기에 각각 역할을 나누어서 모듈화를 진행한다.

보통 MODEL, VIEW, @(Presenter, Controller, ViewModel) 

 

---

■ 2. MVC 패턴 ■

 

MVC 패턴은 Model + View + Controller 를 합친 용어로, 디자인 패턴중에 가장 범용적이며 오래되었고, 웹 프레임워크에서 널리 쓰인다.

 

 

■ 2-1. MVC 패턴의 구조인  뷰(View), 모델(Model), 컨트롤러(Controller)에 대해 알아보자.

• Controller : 사용자의 입력(Action)을 받고 처리하는 부분이다. (뷰의 모델을 변화 시키는 알고리즘이나 소스코드가 위치한 곳)
• View : 사용자에서 보여지는 UI 부분이다.
• Model : 어플리케이션에서 사용되는 데이터와 그 데이터를 처리하는 부분이다.

 ■ 2-2. MVC 패턴의 동작

1. 만약 버튼을 클릭했다면(사용자의 Action) Controller에 들어오게 된다.
2. Controller는 사용자의 Action을 확인하고, Model을 업데이트 한다.
3. Controller는 Model을 나타내줄 View를 선택한다.
4. View는 Model을 이용하여 화면을 나타낸다.

 ■ 2-3. MVC 패턴의 특징

• Controller는 여러개의 View를 선택할 수 있는 1:N 구조이다.
• Controller는 View를 선택할 뿐 직접 업데이트 업데이트 하지 않는다.(View는 Controller를 알지 못한다.)
• Django, Ruby on Rails, Sysmfony, Spring 등의 웹 프레임워크에 널리 사용된다.
• 모델, 뷰, 컨트롤러 로 나누어 프로젝트를 구성한다.
• 윈도우, 리눅스, 안드로이드, IOS 에서도 사용한다.
• 가장 범용적이고 오래되었으며, 비교적 구조가 단순한편인 디자인 패턴이다.

 

■ 2-4. MVC 패턴의 장점

• 코드 재사용 용이함
•  종속성이 적어지며 뷰를 재사용하기 편하다던지 클래스나 메서드를 분리해서 다른 프로젝트에서 사용 하기 편한다.
•  여러 인터페이스 적용하기 편하다.
•  비교적 단순한 구조 덕분에 개발자들 사이에선 대중적으로 널리 쓰인다.
•  디자이너를 이해시키기 용이하다.
•  가장 많은 프레임워크나 개발 프레임워크에서 사용되는편이다.

 

■ 2-5. MVC 패턴의 단점

• 컨트롤러에 소스코드가 집중되는 경향이 있음
• 안드로이드 같은 경우 뷰와 컨트롤러가 같은곳에 집중되는 경향이 있어서 한 곳에 소스코드가 집중이 되고 모듈화가 잘 안되는 경우가 발생한다. 이 경우에 프로젝트가 복잡하고 커질경우 코드 재사용성과 유지보수 효율성이 하락한다.
• 뷰와 모델의 의존성이 높으며 컨트롤러에 대한 의존성도 높다. ==> 그렇기에 어플리케이션이 커질수록 복잡하고 유지보수가 어렵게 만들 수 있다.

 

---

■ 3. MVP 패턴 ■

 

MVC 패턴에서 파생되어진 패턴으로 Model + View + Presenter를 합친 용어이다. Model과 View는 MVC 패턴과 동일하고, Controller 대신 Presenter가 존재한다.

 ■ 3-1. MVP 패턴의 구조인  뷰(View), 모델(Model), 프레젠터(Presenter)에 대해 알아보자.

• Presenter : View에서 요청한 정보로 Model을 가공하여 View에 전달해 주는 부분이다.(쉽게 말해 View와 Model을 붙여주는 역할)
• View : 사용자에서 보여지는 UI 부분이다.
• Model : 어플리케이션에서 사용되는 데이터와 그 데이터를 처리하는 부분이다.

 

 ■ 3-2. MVP 패턴의 동작

1. 버튼 클릭(사용자의 Action)은 View를 통해 들어온다.
2. View는 데이터를 Presenter에 요청한다.
3. Presenter는 Model에게 데이터를 요청한다.
4. Model은 Presenter에서 요청받은 데이터를 응답한다.
5. Presenter는 View에게 데이터를 응답한다.
6. View는 Presenter가 응답한 데이터를 이용하여 화면을 나타낸다.

 

 ■ 3-3. MVP 패턴의 특징

Presenter는 View와 Model의 인스턴스를 가지고 있어 둘을 연결하는 접착제 역할을 한다.

Presenter와 View는 1:1 관계이다. ==> Presenter와 View 사이의 의존성이 높아짐

 

 ■ 3-4. MVP 패턴의 장점

MVC View와 Model의 의존성 문제를 해결해서 View와 Model의 모듈화를 해결해준다.(Presenter를 통해서만 데이터를 전달 받기 때문에)

 

■ 3-5. MVP 패턴의 단점

MVC 패턴의 단점인 View와 Model 사이의 의존성은 해결되었지만, View와 Presenter 사이의 의존성이 높은 가지게 되는 단점이 있습니다. 어플리케이션이 복잡해 질 수록 View와 Presenter 사이의 의존성이 강해지는 단점이 있다.

 

---

■ 4. MVVM 패턴 ■

 

MVVM 패턴은 Model + View + View Model를 합친 용어이다. Model과 View은 다른 패턴과 동일하다.

 

■ 4-1. MVVM 패턴의 구조인  뷰(View), 모델(Model), 뷰 모델(View Model)에 대해 알아보자.

• View Model : View를 표현하기 위해 만든 View를 위한 Model이다. View를 나타내 주기 위한 Model이자 View를 나타내기 위한 데이터 처리를 하는 부분이다.
• View : 사용자에서 보여지는 UI 부분이다.
• Model : 어플리케이션에서 사용되는 데이터와 그 데이터를 처리하는 부분이다.

 

 ■ 4-2. MVVM 패턴의 동작

1. 버튼 클릭(사용자의 Action)들은 View를 통해 들어오게 된다.
2. 버튼 클릭(View에 Action)이 들어오면, Command 패턴으로 View Model에 Action을 전달한다.
3. View Model은 Model에게 데이터를 요청한다.
4. Model은 View Model에게 요청받은 데이터를 응답한다.
5. View Model은 응답 받은 데이터를 가공하여 저장한다.
6. View는 View Model과 Data Binding하여 화면을 나타낸다.

 ■ 4-3. MVVM 패턴의 특징

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

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

View Model과 View는 1:N 관계이다.

 

 

 ■ 4-4. MVVM 패턴의 장점

• 모듈화에 장점을 가진다.
• 모듈화가 잘되면 유닛테스트가 수월해진다.(*유닛테스트:하나의 모듈을 기준으로 독립적으로 진행되는 가장 작은 단위의 테스트)
• 뷰와 모델 간의 간섭이 줄어들어 프로젝트 장기화시 소스코드를 보기가 편하다.
• 일부만 수정시 코드 변경을 최소화 할 수 있다.
• 뷰를 직접 조작하는 빈도를 줄여 영역이 독립적으로 동작한다.

 

■ 4-5. MVVM 패턴의 단점

• 간단한 사용자 인터페이스 만들때는 과하다.
• 큰 프로젝트의 경우 선언적 데이터를 바인딩하고, 시작하기 떼문에 이로인한 메모리 사용률 증가(바인딩된 데이터가 많을 경우)
• 비교적 구현구조가 복잡한편이고 설계가 쉽지 않다.
• 설계를 잘 못하는 경우 의미가 없어진다. 

 

■ 4-6. MVVM 패턴 혹은 다른 디자인 패턴을 공부하려는 방법

내가 궁극적으로 배울 패턴은 MVVM이기 때문에 MVVM 패턴을 공부하는 방법을 적어보겠다.

• 이론적인 설명과 내가 왜 이러한 패턴을 적용을 해야만 하는지 충분한 공감 및 필요성을 깨닫는다.
• 각 플랫폼마다 지원하는지 확인한다. (MVVM 패턴을 플랫폼에 지원하지 않는다면 내가 아무리 스스로 잘한다고 하더라도 완벽한 MVVM 패턴을 만들지는 못한다.
• 데이터바인딩과 관련된 디자인패턴은 해당 플랫폼에서 구조나 사용방법을 제공해야만 제대로 사용할 수 있다.
• 미리 데이터바인딩을 어떻게 하는지 확인하고 실습해본다.
• 초보때 처음 공부하기보단 앱을 만들어보고 능숙해진다음 해보는것을 추천한다.

---

■ MVC, MVP, MVVM 정리 ■

 

정리를 해보자면,

MVC 패턴은 웹 프레임워크에서 자주 사용되는 패턴 및 다른 프레임워크에서는 소규모 프로젝트에서 많이 사용하곤 한다.
왜냐하면 안드로이드 경우에 Cotroller에 소스코드가 집중되는 경향이 있고, 뷰와 모델의 의존성이 높으며 컨트롤러에 대한 의존성이 높기 때문이다. 

(컨트롤러와 View의 관계는 1:N)

MVP 패턴은 MVC 패턴에서 파생된 패턴으로 Controller가 아닌 Presenter를 통해 뷰와 모델의 종속성 문제를 해결함으로써 뷰와 모델의 모듈화를 해결해준다. MVP 패턴도 MVC 패턴의 컨트롤러에 소스코드가 몰린다는 단점과 같이 프레젠트에 소스가 몰린다는 단점이 있다.
(Presenter와 View는 1:1) ==> Presenter와 View 사이의 의존성 높아짐

MVVM 패턴은 MVP 패턴에서 파생된 패턴으로 Presenter가 아닌 View Model를 사용한다. View Model을 사용함으로써 뷰와 모델의 종속성 문제를 해결하였으니, MVP 패턴에서 해결하지 못한 View Model과 View사이의 의존성을 없애기 위해 Command 패턴과 Data Binding을 이용하여 View와 View Model사이의 의존성을 없앴다.
(View Model과 View는 1:N)