디자인 패턴
반복되는 코드, 구조 등을 설계하고 정의내린 것을 디자인패턴이라한다.
즉, 효율적인 코드를 위한 하나의 방식이라고 할 수 있다.
개발자별로 개발 실력과 스타일이 다르기에 남의 코드를 읽는 것이 쉽지 않다.
이미 검증된 디자인패턴을 적용하면 익힌 사람들끼리 해석하기 용이하며 유지보수하기가 쉽고 기능의 소개와 전파 등 개발자들간의 커뮤니티 활성에 도움이 되기에 그만큼 개발 시간도 단축할 수 있다.
그래서 대표적인 디자인 패턴 MVC MVP MVVM에 대해 알아보고자한다.
MVC
Moel , View , Controller 의 약자 MVC이다.
Model : 데이터와 비즈니스 로직을 관리
DB 및 API로 부터 데이터를 가지고 올 수 있고 데이터를 가지고 있을 수도 있다. 데이터가 변경되면 뷰에게 알린다.
View : 사용자에게 보여지는 화면(UI) 부분
사용자가 볼 데이터(결과물,값)를 모델이나 컨트롤러로부터 받아와 화면에 보여준다.
Controller: 사용자의 Input을 받고 처리
사용자의 액션이나 이벤트들에 해당하는 모델을 업데이트한다. 업데이트 결과에 따라 View를 선택한다. Controller는 View를 선택할 뿐, 직접 업데이트를 하지않는다.
💡 Controller는 여러개의 View를 선택할 수 있는 1:n구조이다.
- 장점 : 단순함, 직관적인 구조로 이해하기쉽다.
- 단점 & 한계
Massive-View-Controller
View 업데이트를 위해 Model과 의존성이 존재, 복잡한 대규모 프로젝트의 경우 다수의 뷰와 모델이 컨트롤러를 통해 연결되기 때문에 컨트롤러가 불필요하게 커지는 현상이 발생한다. 복잡한 화면을 구성하는 경우에도 동일한 현상인 'Massive-View-Controller'가 발생한다. 앱이 복잡해질수록 유지보수가 어려워진다.
MVP
Model, View, Presenter 의 약자 MVP이다.
Model과 View는 MVC 패턴과 동일하고, Controller 대신 Presenter가 존재한다.
Model : 데이터와 비즈니스 로직을 관리
DB 및 API로 부터 데이터를 가지고 올 수 있고 데이터를 가지고 있을 수도 있다. View 또는 Presenter 등 다른 어떤 요소에도 의존적이지 않은 독립적인 영역이다.
View : 사용자에게 보여지는 화면(UI) 부분
모든 Input(입력,액션,이벤트 등)을 주시하며 Presenter로 전달한다.
Presenter를 통해 전달받은 데이터를 사용자에게 보여준다.
Presenter를 통해 데이터를 주고 받기에 Presenter에 매우 의존적이다.
Presenter: Model과 View사이의 매개체
View에서 요청한 정보로 Model을 가공하여 View에게 전달한다.
View와 Model의 인스턴스를 가지고 있어 둘을 연결하는 역할을 한다.
💡 View와 Presenter는 1:1 관계이다.
-
장점
Presenter를 통해서만 데이터를 전달 받기 때문에 MVC 패턴의 단점이었던 View와 Model의 의존성이 없다는 것이다. -
단점
MVC 패턴의 단점인 View와 Model 사이의 의존성은 해결되었지만, View와 Presenter는 1:1 관계이기에 어플리케이션이 복잡해 질수록 View와 Presenter 사이의 의존성이 강해진다.
MVVM
Model, View, ViewModel 의 약자 MVVM이다. 앱의 대표적인 패턴으로 자주 사용된다.
Model : 데이터와 데이터를 처리하는 부분
Model은 View, ViewModel 계층을 전혀 신경쓰지 않아도 된다.
View : 사용자에게 보여지는 화면(UI) 부분
View Model: View를 표현하기 위해 만든 View를 위한 ViewModel
View를 나타내기 위한 Model이자 View를 나타내기 위한 데이터를 가공,처리하는 부분이다.
💡 ViewModel 과 View가 1:N 관계이다.
💡 서로간의 의존성이 없다.
- 장점
MVVM 패턴 목표는 비즈니스 로직과 프레젠테이션 로직을 UI로부터 분리하는 것이다. 비즈니스 로직과 프레젠테이션 로직을 UI로부터 분리하게 되면, 테스트, 유지 보수, 코드 재사용이 쉬워진다.
즉, ViewModel이 따로 저장하는 데이터를 구독하여 자동 업데이트 하는 구조로 View가 독립적으로 변함으로써 Model, ViewModel 과의 의존성 문제를 해결했다.
UI 디자인이 나오지 않았더라도 Model과 ViewModel을 먼저 개발할 수 있기 때문에 개발 기간 동안 개발자와 디자이너가 동시에 독립적으로 작업할 수 있다.
- 단점
다른 패턴에 비해 상대적으로 이해가 어렵고 처음 설계가 복잡하다.
프로젝트가 커질수록 ViewModel도 비대해질 수 있으며 코드가 길어진다.
작고 단순한 프로젝트에서 사용하기에는 비효율적일 수 있다.
마치며...
각 디자인 패턴들을 익혀두어 프로젝트에 맞게 적합한 것을 골라 사용할 줄 아는 센스, 패턴을 파악하는 눈이 필요할 것 같다.
그리고 무조건 패턴을 우선하여 패턴에 맞춰 개발하는 것이되면 오히려 독이 될 수 있겠다는 생각이 들었다. 혼자하는 작은 프로젝트 경우에는 패턴에 집착하다보면 오히려 시간을 지체하거나 더 복잡해질 수 있기에 구현을 목표로 하는것이 좋을 것 같다.
