최근 진행하고 있는 프로젝트에서도 사용되는 패턴이라 관심은 가지고 있었는데,
마침 진행중인 교육 내용 중 MVC, MVP, MVVM 관련 내용이 있어서 개인적으로 이해한 내용들을 정리하려고 한다.
한국어로 된 다른 티스토리 글과 그림들을 몇가지 찾아보았는데, 거기서 예시로 올려둔 그림보다
위키피디아에 첨부된 그림이 더 이해하기에 적절하다고 느껴서 위키피디아 그림을 첨부한다.
문서를 찾아보고 여러 정리된 글을 찾아보아도 개발자들마다 설명의 디테일이 다르고,실제로 각 언어마다 구현되는 방식에 차이가 있기에 정확한 정답은 아니지만 개인적으로 이해한 내용을 참고용으로 남겨놓았다.
각 패턴 설명에 앞서,
MVC, MVP, MVVM 이런 MV- 로 선언된 디자인 패턴들은 모두
'Mode과 View 사이를 어떤 구조로 연결하고, 어떤 방식으로 동작시킬까?'
하는 고민을 해결하기 위한 방법들 이라고 정리해 볼 수 있다.
다시 말하자면,
사용자가 UI를 통해 받아보고 명령을 프로그램에 전달하는 창구인 'View'
프로그램에서 사용되는 데이터를 저장하고 변경하는 것과 관련된 'Model'
이 둘 사이를 'Controller' 가 처리해는지, 'Presenter' 가 처리해주는지, 혹은 'ViewModel' 이 처리해 주는지에
따라 패턴 명이 MVC, MVP, MVVM이 되는 것이다.
1. MVC
Model, View, Controller
위에 언급한 세가지 패턴들에서 Model 과 View 의 역할과 설명은 모두 동일하다.
Controller 가 어떻게 동작하는지 이게 사실 가장 중요한데,
Controller는 아래 그림 처럼 User가 View를 통해 준 명령 ( USES ) 를 처리하는 로직들을 담당하며
로직에 따라 Model 의 변경이 필요하다면, Model 에게 해당 동작을 전달하여 수행하게 한다. ( MANIPULATES )
그리고 Model 의 변경 사항이 Controller를 거치지 않고 View에 바로 화살표가 연결된 것을 볼 수 있는데 ( UPDATES )
여기서 View는 어떻게 Model 이 변경된 것을 알까?!
크게 2가지 방법이 있는데,
- View 가 계속해서 Model 의 상태를 확인하여 ( Polling ) Model 의 변화를 감지
- Model 이 변경되었을 때 View 에게 Notify
2가지 방법 모두 특정 View 객체와 특정 Model 객체가 어떤 객체를 주시하고, 어떤 객체에게 Notify를 할 것인지 정의되어 있어야만 가능한 방법이고, 그렇기 때문에 Model과 View 간 결합도가 높다는 특징이 있다.
장점 : 가장 간단하고, 자주 쓰이며 가장 유명하다는 점.
단점 : View 와 Model 간 결합도가 높고, Controller에 대부분의 로직이 몰려있어서 Controller가 비대해지는 문제 발생.
2. MVP
Model, View, Presenter
MVC 패턴에서 View 와 Model 간 결합도를 낮춰보고자 View와 1:1로 대응하는 Presenter를 중간에 두어 구성한 구조.
변경점이 발생했을 때 View 와 Model이 직접 서로에게 알려주는 것이 아니라,
MVC 패턴에서의 Controller의 역할 + Event Handling 기능이 추가된 Presenter 가 중간 전달자 역할을 하게 된다.
따라서 View와 Model 에서 발생한 모든 변경점이나 명령은 Presenter 를 거치게 되는 구조이다.
그래서 Presenter를 가운데 두고 Event 관련된 행위들이 수행되는 것을 그림에서도 확인할 수 있다.
( User Events, state-change events )
하지만 View와 Model 간 결합도를 낮춰보고자 한 시도는 좋았지만,
View 와 Presenter 사이에 높은 결합도가 발생하여 사실 조삼모사 처럼 느껴진다.
장점 : View 와 Model 간 결합도 낮춤.
단점 : View 와 Presenter 간 높은 결합도 존재.
3. MVVM
Model, View, ViewModel
MVVM Pattern
ViewModel 의 특징은 Data Binding 과 캡슐화된 Command 패턴을 이용하여
View 와 Model 간 결합도를 없애면서 View와 Model 사이에서 중간 관리자의 역할을 완벽하게 수행한다.
- Data binding : 객체 간 의존성을 부여하여 View 객체와 Model 객체를 연결하는 기능을 지원한다.
- Command 패턴 : 여러 객체에서 발생하는 일들을 Command 캡슐화를 통해 일괄적으로 처리하는 패턴
따라서 MVVM 패턴에서는 View 개발자는 Model 관련 코드가 아직 없어도
사전에 정의된 '어떤 객체와 바인딩 할 것인지, 어떤 명령들이 전달될 것인지' 정의된 내용들만 가지고도
각자 일정에 맞추어 개발을 진행한 뒤, 나중에 ViewModel 에서 협의된 양식에 맞게 결합을 해주면 된다.
장점은 View 와 Model 간 종속성 문제를 완전히 해결.
View 와 Model 간 종속성이 없기 때문에 다양한 플랫폼에 쉽게 적용할 수 있다.
단점은 ViewModel 코드 작성이 어렵다. View 와 Model 에서 각각 따로 독립적으로 구성되어있는 모듈과 객체들을 중간에서 적절하게 Binding 하고 Command 패턴을 적절히 설정하여 코드를 동작시켜야 하기 때문.
그리고 개인적으로 느꼈던 단점은, Binding과 관련한 오류가 발생했을 때, 디버깅이 어렵다.
Binding 이 제대로 안되어서 명령이 동작하지 않는 것인지 혹은 중간 로직에서 파라미터를 잘못 전달했는지, Binding 관련 오류인지 아니면 ViewModel 내부 로직이나 구현 오류인지 확실히 드러나지 않기에 시간이 오래 걸린다.
'개발' 카테고리의 다른 글
| 우분투 한글 설정 (0) | 2019.02.12 |
|---|---|
| Sequelize createdAt,updatedAt 컬럼 추가하기 (0) | 2018.04.04 |