MVC, MVP, MVVM패턴들은 UI와 로직의 분리가 목적인 패턴들이다.
불필요한 종속 관계를 줄이는 패턴으로 아키텍쳐 패턴이라고도 불린다.
결과적으로 최종 목표는 스타게티 코드가 되는 것을 방지하는 것이다.
소개는 넘어가고 그래서 이게 뭐냐 하나씩 알아보자.
MVC( Model View Controller)
MVC는 소프트웨어의 논리적 부분을 데이터와 프레젠테이션에서 분리하여, 불필요한 종속성과 스파게티 코드를 줄일 수 있다.
결국 각 레이어의 기능을 제한하여 단일책임원칙을 지킬 수 있게 된다.
M => 모델: 어플리케이션 데이터를 관리하는 역할
- 값을 보관하는 데이터 컨테이너
- 게임 플레이 로직을 수행하거나 계산을 실행하지 않는다.
V => 뷰: 데이터를 사용자에게 표시하는 역할(UI라고도 할 수 있음)
- 화면에 데이터의 그래픽을 표현하는 인터페이스
C => 컨트롤러: 입력 및 로직을 처리하는 역할
- 게임 데이터를 처리하고 런타임에 값이 어떻게 변하는지 계산
- 입력을 처리하고 결과를 모델로 다시 전송
- 그 자체로 게임 데이터를 포함하지 않는다.
한계도 존재한다.
View(UI) 자체는 문제가 없지만(UI Toolkit,UnityUI등을사용) , 모델 데이터의 변경 사항을 수신하기 위해서는 뷰 별로 코드가 필요하다는 것이다.
그래서 유니티에서는 보통 MVC보다는 MVP모델을 주로 사용한다.
MVP(Model View Presenter)
M => 모델:
- 여기에는 데이터와 이 데이터를 관리하는 규칙이 포함된다.
- 예를들어 게임의 현재 상태, 게임 속성, 데이터에 대한 로직(레벨업, 체력, 점수 등)
- Model은 View에 대한 정보가 없다.
V => 뷰:
- 사용자에게 데이터를 표시하는 어플리케이션의 UI
- 사용자 상호작용(버튼 클릭같은)을 Presenter로 전송
- MVP 패턴의 View는 Model과 직접 상호작용하지 않는다.
- UI 로직에 대한 별도의 스크립트가 있을 수 있지만, 게임의 "비즈니스 로직"을 처리하지 않는다.
P => 프레젠터:
- Model과 View 사이에서 중재하는 역할
- View에서 사용자 입력 이벤트를 처리한다.
- 게임의 조건이 변경되면 Model을 업데이트하고, View를 업데이트한다.
MVVM( Model View ViewModel)
위에 있는 MVP를 조금 더 발전시킨 형태로 Presenter와 View의 의존성을 더 옅게 만든 모델이라고 생각하면 될 거 같다.
주요 특징으로는 데이터 바인딩이다.
뷰와 뷰모델 간의 데이터 바인딩을 통해 뷰모델 속성 변경이 자동으로 뷰에 반영되도록 한 것.
MVVM은 프레임워크의 의존을 많이 받는데 데이터바인딩을 지원하는 시스템이면 가능하지만 안될수도 있고 뭐 하다.
하지만! 유니티6부터는 데이터 바인딩을 지원한다고 한다. 바로 유니티6로 넘어가자.
마지막으로 왼쪽부터 MVC, MVP, MVVM이다 사진으로 보며 마무리해보자.
