그동안 정말 많이 듣고보고 익숙하게 사용은 하고 있지만 정확이 어떤 개념인지는 모르고있는 디자인 패턴에 대해서 정리를 해보겠습니다.
기존 환경 내에서 반복적으로 일어나는 문제들을 어떻게 풀어나갈 것인가에 대한 일종의 솔루션 같은 것
제가 느낀 디자인 패턴은 일종의 코드의 조립설명서
같은 느낌입니다.
레고나 프라모델 조립을 하기 전에 조립설명서를 보지않고 하면 완성품까지 가는 시간도 오래걸리고 완성했더라도 기능이 제대로 작동할거란 보장도 없습니다. 그래서 이를 방지하기 위해 조립설명서를 보고 조립을 합니다.
코드 또한 똑같습니다.
시간도 단축하고 협업하는 개발자들끼리 디자인패턴을 얘기를 맞추고 개발을 하면 불필요한 시간을 단축시켜주고 효율적으로 개발을 할 수 있습니다.
그래서 이 수많은 디자인 패턴 중에서 가장 대표격인 MVC
MVP
MVVM
이 세가지 디자인 패턴에 대해서 알아보려합니다.
Model + View + Controller
Model
: 어플리케이션에서 사용되어지는 데이터
와 그 데이터를 처리
하는 부분View
: 사용자에게 보여지는 UI
부분Action
)을 받고 처리하는 부분Action
)을 Controller
가 감지Action
을 확인하고 Model
을 업데이트Controller
는 Model
을 나타낼 View
를 선택View
는 Model
을 이용해 화면에 나타냄Controller
는 여러개의 View
를 선택할 수 있는 1:n
구조Controller
는 View
를 선택할 뿐 직접 업데이트를 하지 않음(View
는 Controller
를 알수 없음)널리 사용되고 있는 패턴이라 가장 단순함
View
와 Model
사이의 의존성이 높음
어플리케이션이 커질수록 복잡하고 유지보수가 어려울 수 있음
Model + View + 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 관계
Presenter
는 View
와 Model
의 의존성이 없음
View
와 Presenter
사이의 의존성이 높음
어플리케이션이 복잡해질수록 View
와 Presenter
사이의 의존성이 강해짐
Model + View + ViewModel
Model
: 어플리케이션에서 사용되는 데이터
와 그 데이터를 처리
하는 부분View
: 사용자에게 보여지는 UI
부분View Model
: View
를 표현하기 위해 만든 Model
View
를 나타내주기 위한 Model
이자 View
를 나타내기 위한 데이터 처리
를 하는 부분Action
들은 View
를 통해 들어옴View
에 Action
이 들어오면, Command 패턴으로 View Model
에 Action
을 전달View Model
은 Model
에게 데이터를 요청Model
은 View Model
에게 요청 받은 데이터를 응답View Model
은 응답 받은 데이터를 가공하여 저장View
는 View Model
과 Data Binding하여 화면을 나타냄Command 패턴
과 Data Binding
두 가지 패턴을 사용해 구현
View Model
과 View
는 1:n 관계
View
와 Model
사이의 의존성이 없음
Command 패턴
과 Data Binding
을 사용해 View
와 View Model
사이의 의존성 또한 없앤 디자인 패턴
각각의 부분은 독립적이기 때문에 모듈화하여 개발 가능
View Model
의 설계가 쉽지 않음