웹 개발을 공부하면서 주로 MVC 디자인 패턴을 사용하였고, SW 개발에서는 MVVM 디자인 패턴을 사용을 했었다. 이렇게 목적에 따라 디자인 패턴이 달라지는데 이번에는 디자인 패턴에 대해서 자세히 정리를 해보겠다. 오늘 다루는 디자인 패턴으로는 MVC, MVP, MVVM 이 세가지 패턴에 대해서 알아보겠다.
MVC
우선 MVC 패턴에 대해서 정리를 하겠다. MVC는 Model + View + Control을 합친 용어로 웹 어플리케이션 개발에 가장 많이 쓰이는 디자인 패턴 중 하나이다.
- Model : 백그라운드에서 동작하는 비즈니스 로직(데이터) 처리
- View : 사용자에서 보여지는 UI 부분
- Control : 사용자의 입력 처리와 흐름 제어 담당. 화면과 Model과 View를 연결시켜주는 역할
동작원리
- Controller에서 사용자의 Action들을 받는다.
- Controller는 Action을 확인하고, Model을 업데이트한다.
- Controller는 Model을 표시할 View를 선택한다.
- View는 Model을 이용해 화면을 나타낸다.
특징
- UI로부터 비즈니스 로직을 분리하여 애플리케이션의 시각적 요소나 그 이면에서 실행되는 비즈니스 로직을 서로 영향 없이 쉽게 고칠 수 있는 애플리케이션을 만들 수 있다.
- Controller는 여러 개의 View를 선택할 수 있는 1:n 구조이다.
- Controller는 View를 선택할 뿐 직접 업데이트하지 않는다. (View는 Controller를 알지 못한다.)
장점
기능별로 코드를 분리하여 가독성과 코드의 재사용성을 높일 수 있다. 단순하고 직관적이다.
단점
View와 Model 사이의 의존성이 높아 어플리케이션이 커질수록 복잡해지고, 유지보수가 어렵다.
MVP
MVP 패턴은 Model + View + Presenter를 합친 용어입니다. Model과 View는 MVC 패턴과 동일하고, Controller 대신 Presenter가 한다.
- Model : 백그라운드에서 동작하는 비즈니스 로직(데이터) 처리
- View : 사용자에서 보여지는 UI 부분
- Presenter :View에서 요청한 정보로 Model을 가공하여 View에게 전달하는 역할
동작원리
- 사용자의 Action들은 View를 통해 들어온다.
- View는 데이터를 Presenter에게 요청한다.
- Presenter는 Model에게 데이터를 요청한다.
- Model은 Presenter에서 요청받은 데이터를 응답한다.
- Presenter는 View에게 데이터를 응답한다.
- View는 Presenter가 응답한 데이터를 이용하여 화면을 나타낸다.
특징
- Presenter는 View와 Model의 인스턴스를 가지고 있어 둘을 연결하는 역할을 한다.
- Presenter와 View는 1:1 관계이다.
장점
View와 Model의 의존성이 없다.
단점
View와 Model 사이의 의존성은 해결되었지만, View와 Presenter 사이의 의존성이 높아지는 단점이 있다. 어플리케이션이 복잡해질수록 View와 Presenter 사이의 의존성이 강해진다.
MVVM
MVVM 패턴은 Model + View + ViewModel를 합친 용어입니다. Model과 View은 다른 패턴과 동일합니다.
- Model : 백그라운드에서 동작하는 비즈니스 로직(데이터) 처리1
- View : 사용자에서 보여지는 UI 부분
- ViewModel : 모델을 작동하기 위한 명령을 나타내고, 뷰의 상태를 유지시키고 뷰의 이벤트를 활성화 시킨다.
동작원리
- 사용자의 Action이 View를 통해 들어온다.
- View에서 Action이 들어오면, Command 패턴으로 ViewModel에 Action을 전달한다.
- ViewModel은 Model에 데이터를 전달한다.
- Model은 ViewModel로 요청 받은 데이터를 응답한다.
- ViewModel은 응답 받은 데이터를 가공하여 저장한다.
- View는 ViewModel과 Data Binding하여 화면을 보여준다.
특징
- MVVM 패턴은 Command 패턴과 Data Binding 두 가지 패턴을 사용하여 View와 View Model 사이의 의존성을 없앴다.
- View Model과 View는 1:n 관계이다.
장점
View와 Model 사이의 의존성이 없으며, Command 패턴과 Data Binding을 사용하여 View와 View Model 사이의 의존성이 없다.
단점
View-Model의 설계가 어렵다.
참고 문서 및 링크
