MVP 개념에 대해

본격적으로 코드를 작성하기 전에 구조에 대한 컨셉트에 대해 이야기 할 필요가 있다.

MVP와 MVVM

정석적인 MVP에 대해

  • 정석적인 MVP라고 한다면, Model, View, Presenter를 각각 만들고 서로에 대해 의존성을 떨어뜨리기 위해 서로 구체적인 구현을 고려하지 않고 Interface만을 통해서 통신하는 구조로 만들어야만한다.

  • 이는 각각의 UI 요소에 대한 재활용성을 고려한 설계이며, 프로젝트 전체적으로 재사용될만한 UI 구조가 많은 경우에 매우 유효한 방식이다.

  • 그러나 이렇게 설계를 하는데에는 상당한 시간/노력이 발생한다.

정석적인 MVVM에 대해

  • MVVM은 Presenter측에서 view측에 데이터를 일일히 수정하는 수고를 덜어내는데 큰 방점이 있는 방식이다.

  • View Model 측에서 View와 Model의 데이터를 서로 바인딩 함으로서, Model의 값 변화가 원하는 타이밍에 바로바로 View측의 UI에 바로 표시되도록 한다.

정통적인 방식의 문제에 대해

Unity 게임의 특성

  • 게임이라는 프로그램의 특성상 일반적인 앱이나 웹과는 다르게 재사용되는 UI 구조가 거의 없다.

    • 정확히 표현하자면 여러 화면에 걸쳐 재사용되는 UI컴포넌트, 즉, MVP를 뽑아내는데 어려움이 많다.

    • 그리고 기획적으로 조금만 달라지더라도, 큰 범위의 수정이 필요한 경우가 많다.

    • 이때 오히려 정통적인 방식의 엄격한 MVP, MVVM 구현이 오히려 프로젝트 진행의 발목을 잡는 경우가 많다.

  • MVVM과 UGUI

    • MVVM의 핵심인 데이터 바인딩은 UI 프레임워크 레벨에서 반드시 지원해주어야 구현이 가능하다.

    • UGUI는 이를 전혀 고려하지 않고 설계된 UI 프레임워크이다. (최근 유니티에서 푸시하고 있는 UIToolKit은 이를 Unity6 LTS에서 부터 지원하나, 아직 UIToolKit은 실 제품에 사용하기에는 미완성인 프레임워크이다.)

    • 또한 UI에 데이터를 바인딩한다는 것은 퍼포먼스 이슈와도 깊게 관련되어있다. (일반 앱/웹 보다 이 퍼포먼스 이슈에 게임은 훨씬 큰 영향을 받는다)

나는 이렇게 하기로 정했다.

MVP는 서로 한 세트

  • MVP를 구현할때 다른곳에서 사용될 수 있다는 가능성을 배제하고, MVP의 한 세트로 작성한다.

  • 한 화면에 Model은 반드시 한개, View는 반드시 한개, Presenter는 반드시 한개.

  • 즉, 인터페이스등을 사용하여 공용 로직부분을 추출하지 않는다.

  • 기획이 바뀌면 그 한 세트만 수정하면 되고, 다른 화면의 UI에 영향을 주지 않는다.

  • 이렇게 함으로서 오히려 빠른 개발 사이클을 진행할 수 있고, 빠른 수정이 가능하다는 것을 경험한 바 있다.

MVRP 사용

  • UniTask나 UniRx(R3) 등에서 지원하는 ReactiveProperty 등을 이용하여 UI에 데이터를 일종의 바인딩을 한다.

공용로직 추출은 나중에

  • 프로젝트를 진행하다가 정말 공용되는 UI가 반복적으로 2-3회 이상 사용된다고 판단되면 그때 그 부분을 인터페이스로 추출해도 늦지 않다.

MVP & MVVM의 하이브리드

위 두 방식을 사용함으로서, 게임이라는 도메인 특성에 맞는 UI 코드 구조를 갖추었다고 생각한다.

Last updated