[개발일기] 디자인패턴에 대해 알아보자! (MVC, MVP, MVVM)

🕵️ 디자인 패턴이란 ?

소프트웨어 디자인 패턴은 소프트웨어 공학의 소프트웨어 디자인에서 특정 문맥에서 공통적으로 발생하는 문제에 대해 재사용 가능한 해결책이다. 소스나 기계 코드로 바로 전환될수 있는 완성된 디자인은 아니며, 다른 상황에 맞게 사용될 수 있는 문제들을 해결하는데에 쓰이는 서술이나 템플릿이다. 즉 '효율적인 코드를 만들기 위해 등장한 방법론'이라고 생각하면 되겠다.

소프트웨어 디자인 패턴 - 위키백과, 우리 모두의 백과사전

이번 시간에는 아주 다양한 디자인 패턴들 중에 대표적으로 MVC, MVP, MVVM에 대해 알아보고자 한다.
알아보기에 앞서 아래에 MVC, MVP, MVVM에 대해 간단하게 정리된 그림을 보도록 하자.

출처 : https://tomyrhymond.wordpress.com/2011/09/16/mvc-mvp-and-mvvm/

📜MVC

MVC는 Model-View-Controller의 약자이며, 하나의 애플리케이션, 프로젝트를 구성할 때 그 구성요소를 세가지의 역할로 구분한 패턴이다. 모든 입력은 Controller에서 처리가 되며, Controller에 Input이 들어올 때, Controller는 Input에 해당하는 Model을 조작하고, Model을 보여줄 View를 선택한다. 

Controller에 Input(Action) 입력 => Controller가 Input에 해당되는 Model (CRUD) => Controller가 Model을 보여줄 View 선택 => View가 Model 을 직접 사용해 업데이트

1) 장점
- 가장 단순하고 보편적인 디자인 패턴이다.
2) 단점
- View와 Model의 의존성이 높다. 때문에 프로젝트가 커질 수록 복잡해지고 유지보수가 어렵다.

📜MVP

MVP는 Model-View-Presenter의 약자이며, MVC와는 다르게 Input이 View에서 이루어진다. Presenter는 View의 인스턴스를 갖고 있으며 View와 1:1관계이다. 또한 Presenter는 해당하는 Model의 인스턴스도 갖고 있어서 View - Model사이에서 Controller와 같은 다리 역할을 수행한다. 수행 순서는 아래와 같다.

View에서 이벤트가 발생 => Presenter로 전달 => Presenter에서 이벤트에 따라 Model을 조작한 뒤 View에 바인딩

1) 장점
- View와 Model의 의존성이 없다.
2) 단점
- 대신 View와 Presenter의 의존성이 높아진다. 이 또한 프로젝트가 커질 수록 복잡해진다.

📜MVVM

MVVM는 Model-View-View Model의 약자이며, ViewModel이라는 새로운 개념은 말 그대로 View를 나타내기 위한 Model로 보면 된다. 이는 Model과 좀 더 유사한 디자인으로 구성되어있다. MVVM은 MVP와 같이 View에서 입력이 처리된다. Command를 통해 Behavior를 View의 이벤트와 연결해서 ViewModel의 속성과 View의 속성을 바인딩하여 ViewModel 속성이 바뀔 때마다 View를 업데이트 시키는 방식이다.

View에서 이벤트 발생 => Command 패턴으로 ViewModel이 Action을 전달받음 => ViewModel은 Model에게 요청한 데이터를 받음 => ViewModel은 응답받은 데이터를 가공한 뒤에 저장 => View는 ViewModel 속성이 바뀐 것을 체크하여 화면을 업데이트 함

1) 장점
- MVP의 의존성이라는 단점을 없앤 디자인패턴이다.
2) 단점
- 대신 ViewModel의 설계가 어렵다.

 

다음 개발일기에는 이러한 양방향 데이터 바인딩 패턴을 개선하고자 나온 단방향 데이터 바인딩 패턴인 Flux, 그리고 이 패턴에 이어 등장한 Redux, Vue의 Vuex에 대해 알아보겠다. 
그럼 다음 시간에 계속!