[Unity] MVC, MVP, MVVM Pattern

개요

MVC, MVP, MVVM 패턴은 UI와 로직의 분리가 목적인 패턴이다. 로직을 분리하여 불필요한 종속 관계를 줄인다. 

오늘날의 UI는 과거보다 훨씬 정교해지고 수가 많아짐에 따라 혼자 작업할 수 없다. 여러명의 공동 작업을 진행할 때 구조를 얼마나 잘 짤 수 있을지가 관건이며, 구조의 짜임새가 중요하므로 다양한 패턴이 탄생하고 다양한 UI 프레임워크가 탄생했다. 

기존의 디자인 패턴은 클래스 다이어그램으로 표현이 가능하나, 해당 패턴은 SoC(Separation Of Concerns, 관심사 분리) 측면이다. 즉, 하나 하나의 클래스가 아닌 어떤 로직 단위들의 관계를 나타내는 개념으로 생각하면 된다. 그러다보니 디자인 패턴보다는 아키텍쳐 패턴으로 분류된다. 유니티에서의 툴셋 기반으로 진행되는 도구는 모두 해당 패턴이 사용되었다고 보면 된다. 해당 패턴의 주 목표는 잠재적인 스파게티 코드를 방지하며, UI/UX 프레임워크에 의존적이다. 

MVC(Model View Controller)

Model View Controller

소프트웨어에서 UI를 개발할 때 일반적으로 사용되는 디자인패턴이다. 소프트웨어의 논리적인 부분을 데이터와 분리하는 것이 궁극적인 목표이며, 결국 종속성과 스파게티 코드를 줄이는 것이 최종 목표이다. MVC 디자인은 각 레이어의 기능을 제한하여 단일 책임 원칙을 준수한다. 

• Model : 애플리케이션 데이터를 관리하고 값을 보관하는 데이터 컨테이너, 게임 플레이 로직을 수행하거나 계산 실행 X
• View : 화면에 데이터 그래픽을 사용자에게 표시하는 인터페이스 → UI Section
• Controller : 게임 데이터를 처리하고 런타임에 값이 어떻게 변하는지 계산, 입력을 처리하고 결과를 모델로 다시 전송, 그 자체로 게임 데이터를 포함하지 않음 → 입력 및 로직 처리 Section

뷰와 컨트롤러로 서로 역할을 나누게 되면 의존 관계 및 종속성을 줄일 수 있고 유지보수가 쉬워진다. 

MVC를 적용하면 뷰자체는 문제가 없다(UI Toolkit or Unity UI가 제공되므로). 그러나, 모델 데이터의 변경사항을 수신하기 위한 Vew별 코드가 필요하다. 이러한 문제로 인해 Unity에서는 MVC보다는 MVP 모델을 채용한다. 

MVP(Model View Presenter)

Model View Presenter

• Model : 데이터와 해당 데이터를 관리하는 규칙 포함(example> 게임의 현재 상태, 게임 속성, 캐릭터 레벨업, 체력, 점수 등) 데이터에 대한 로직), Model은 View에 대한 정보가 없음 → Model과 View를 분리시키는 것이 목표
• Presenter : Model과 View 사이에서 중재, View에서 사용자의 입력 이벤트를 처리, 게임의 조건이 변경되면 Model 및 View를 업데이트
• View : 사용자에게 데이터를 표시하는 애플리케이션의 UI, 사용자 상호작용을 Presenter로 전송, MVP 패턴의 View는 Model과 직접 상호작용하지 않음, UI 로직에 대한 별도 스크립트가 존재할 수 있으나, 게임의 비즈니스 로직 처리 X

MVC에서는 컨트롤러가 사용자 입력을 처리하고 Model을 조작하나, MVP에서는 뷰가 사용자의 입력을 처리하고 Model과 View를 중재하는 것이 Presenter가 된다. 

 

뷰는 UI Event를 통해 입력을 Presenter에게 전송하고, Presenter는 모델을 변경한다. 그리고 모델의 상태가 변경됐을 때 Presenter에게 이벤트로 통지하고, Presenter는 수정된 데이터를 뷰로 전달에 뷰는 UI를 갱신하는 프로세스로 진행된다. 

• 장점

1. 확장성 : 특정 작업을 처리하는 부분들이 나뉘어 있으면 코드 베이스 관리 및 확장 용이

2. 모듈성 : 한 구성요소의 변경사항이 전체 시스템에 영향을 미치지 않음, 각 구성요소는 독립적으로 개발, 테스트 및 수정 될 수 있음, 코드 디버깅 용이

3. 재사용성 및 유지 관리성 : 코드의 일부는 애플리케이션의 다른 부분에서 재사용 가능, 스파게티 코드가 될 확률 ↓

MVVM(Model View ViewModel)

MVP를 보완하여 생성된 패턴이 MVVM이다. 

Model View ViewModel

기존의 MVP에서 뷰와 Controller/Presenter의존성을 약화한 모델이다. 데이터 바인딩이 주 핵심이며, 뷰와 뷰모델 간의 데이터 바인딩을 통해 뷰모델 속성 변경이 자동으로 뷰에 반영된다. 데이터 바인딩 시스템은 프레임워크에 따라 제공해주는지 결정된다. 또한 뷰모델에서 UI 상호작용을 처리하는 커맨드 패턴을 사용한다. 마지막으로 뷰모델은 뷰에 대한 참조를 가지지 않으므로 테스트가 용이하다. 

• Model : 모델은 비즈니스 로직에서 사용되는 데이터를 포함하는 데이터 구조, 어떤 객체라도 될 수 있음  → ScriptableObject, MonoBegaviuor
• View : 사용자에게 데이터를 표시하고 상호작용 하는 UI, 일반적으로 UI Element로 구성, UI Toolkit에서는 USS 스타일 시트와 UXML 파일로 구성
• ViewModel : Model과 View 사이에서 중재, 사용자가 View와 상호작용할 때 Model을 업데이트 하는 역할, Model이 변경될 때 View를 업데이트하는 로직도 포함, ViewModel과 View는 데이터 바인딩을 통해 연결

데이터 바인딩

데이터 바인딩은 UI가 아닌 개체의 속성과 UI 요소간의 자동으로 동기화를 보장한다. exmple> MonoBehaviuor의 문자열 속성과 TextField 값의 속성

바인딩은 본질적으로 UI가 아닌 속성과 이를 수정하는 UI 요소간의 링크이며, 바인딩을 설정하면 기본 데이터와 해당 시각적 요소 간의 변경 사항이 자동으로 동기화 된다. → 각 UI 업데이트에 대해 수동으로 이벤트 핸들러 작성할 필요X

 

Unity6의 UI Toolkit은 런타임 데이터 바인딩을 지원한다. 해당 기능을 사용할 시 런타임 UI 작업 중에 C# 개체의 속성을 UI 컨트롤 속성에 바인딩이 가능하다. 웹개발에서의 영감을 얻어 구현된 시스템으로 생각하면 된다. 해당 글은 디자인 패턴에 대한 내용이므로, UI Toolkit에 대한 튜토리얼은 공개 강의가 많으니 링크를 참조하면 된다.

MVP VS MVVM

• MVP

Presenter는 상태 변경을 감지하기 위해 모델의 이벤트를 구독하고, 변경 사항이 통보되면 Presenter는 데이터를 View에 업데이트한다.

• MVVM

모델에 필요한 Converter를 등록하는 것부터 시작하며, ViewModel에서 데이터 바인딩을 설정한다. 설정을 사용하게 되면 모델의 변경 사항이 기존 바인딩을 통해 자동으로 보기를 업데이트 한다. 사용자 입장에서는 신경쓸 부분이 줄어든다. 

데이터 바인딩을 사용해 UI를 데이터와 동기화하는데 필요한 코드의 양을 줄일 수 있으며, 그러다보면 읽고 유지하기 쉬운 간결한 코드가 된다. 또한 데이터 바인딩을 통해 오래되거나 잘못된 데이터가 표시될 위험을 줄여 UI 일관성을 향상시킨다.

그러나 각 데이터 바인딩을 설정하는데 따른 추가 오버헤드가 발생한다. 데이터 소스, 데이터 소스 경로, 바인딩 모드, 컨버터 등을 설정하려면 번거로울 수 있다. 성능적으로 중요한 부분(시스템의 도움을 받는 등)에서는 좋지 않을 수 있다. 이러한 패턴은 간단한 UI 환경보다는 조금 더 복잡한 대규모 사용자 인터페이스에 적합할 수 있다. 

---

참고 문서

[유니티 TIPS] UI에 걸맞는 MVC, MVP, MVVM 패턴 | 프로그래밍 디자인패턴