반복되는 코드, 구조 등을 설계하고 정의내린 것을 디자인패턴이라한다.
즉, 효율적인 코드를 위한 하나의 방식이라고 할 수 있다.
개발자별로 개발 실력과 스타일이 다르기에 남의 코드를 읽는 것이 쉽지 않다.
이미 검증된 디자인패턴을 적용하면 익힌 사람들끼리 해석하기 용이하며 유지보수하기가 쉽고 기능의 소개와 전파 등 개발자들간의 커뮤니티 활성에 도움이 되기에 그만큼 개발 시간도 단축할 수 있다.
그래서 대표적인 디자인 패턴 MVC
MVP
MVVM
에 대해 알아보고자한다.
Moel , View , Controller 의 약자 MVC
이다.
Model
: 데이터와 비즈니스 로직을 관리
DB 및 API로 부터 데이터를 가지고 올 수 있고 데이터를 가지고 있을 수도 있다. 데이터가 변경되면 뷰에게 알린다.
View
: 사용자에게 보여지는 화면(UI) 부분
사용자가 볼 데이터(결과물,값)를 모델이나 컨트롤러로부터 받아와 화면에 보여준다.
Controller
: 사용자의 Input을 받고 처리
사용자의 액션이나 이벤트들에 해당하는 모델을 업데이트한다. 업데이트 결과에 따라 View를 선택한다. Controller는 View를 선택할 뿐, 직접 업데이트를 하지않는다.
💡 Controller는 여러개의 View를 선택할 수 있는 1:n구조이다.
Massive-View-Controller
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 사이의 의존성이 강해진다.
Model, View, ViewModel 의 약자 MVVM
이다. 앱의 대표적인 패턴으로 자주 사용된다.
Model
: 데이터와 데이터를 처리하는 부분
Model은 View, ViewModel 계층을 전혀 신경쓰지 않아도 된다.
View
: 사용자에게 보여지는 화면(UI) 부분
View Model
: View를 표현하기 위해 만든 View를 위한 ViewModel
View를 나타내기 위한 Model이자 View를 나타내기 위한 데이터를 가공,처리하는 부분이다.
💡 ViewModel 과 View가 1:N 관계이다.
💡 서로간의 의존성이 없다.
각 디자인 패턴들을 익혀두어 프로젝트에 맞게 적합한 것을 골라 사용할 줄 아는 센스, 패턴을 파악하는 눈이 필요할 것 같다.
그리고 무조건 패턴을 우선하여 패턴에 맞춰 개발하는 것이되면 오히려 독이 될 수 있겠다는 생각이 들었다. 혼자하는 작은 프로젝트 경우에는 패턴에 집착하다보면 오히려 시간을 지체하거나 더 복잡해질 수 있기에 구현을 목표로 하는것이 좋을 것 같다.