[Unity] MVC, MVP, MVVM 소프트웨어 디자인 패턴

 

● 소프트웨어 디자인 패턴

▶ 소프트웨어를 여러번 개발하다 보면 자연스럽게 앞의 개발에서 실수 한 부분들을 개선하면서 자신만의 소프트웨어 개발 템플릿이 만들어진다. 소프트웨어 디자인 패턴은 개인의 실수와 개선을 넘어서 다수의 개발자들이 소프트웨어를 개발하면서 시행착오를 겪었던 부분들을 수정하고 개선하면서 만들어진 템플릿이라고 할 수 있다.

▶ 따로 디자인 패턴을 배우지 않아도 경험이 쌓이면 자연스럽게 자신만의 스타일이 생기는데, 이런 시행착오를 적게 겪으면서 효율적인 개발을 하기 위해서는 소프트웨어 디자인 패턴을 학습할 필요가 있다. 

● MVC 패턴

▶ Model - View - Controller로 각각에 대한 역할을 구분하여 독립적인 기능을 수행하도록 설계하는 디자인 패턴이다.

▣ Model

: 어플리케이션에서 사용하는 데이터의 집합이라고 볼 수 있다.

▣ View

: 어플리케이션에서 사용자에게 보여지는 화면, UI 이라고 볼 수 있다.

▣ Controller

: Model과 View를 이어주는 징검다리의 역할로 사용자는 Controller를 사용하여 Model의 데이터를 수정하게 된다.

[ MVC 패턴 ]

: MVC 패턴은 Model의 업데이트에 따라 View에 적용이 되야하는 부분에서 서로 간의 의존성이 발생하게 된다.

● MVP 패턴

▶ MVC 패턴에서 파생된 디자인 패턴으로 Controller를 대신해 Presenter가 추가되었다.

▣ Presenter

: Controller의 역할 + Model과 View의 의존성을 끊고 View는 Presenter를 통해서 화면을 보여주게 된다.

[ MVP 패턴 ]

: Presenter에서 화면 갱신과 데이터 갱신을 모두 처리한다.

● MVVM 패턴

▶ MVP 패턴에서 파생된 디자인 패턴으로 Presenter를 대신해 ViewModel이 추가되었다.

[ MVVM 패턴 ]

: View와 View Model 사이의 모델 데이터가 바인딩되어 Model이 갱신되면 ViewModel의 데이터가 갱신되고, ViewModel의 갱신되는 순간 View도 같이 갱신된다. MVP, MVC가 Model이 갱신되면, 갱신되었다는 정보를 View에 전달하는 반면 MVVM은 데이터가 연결되어 갱신이 바로 발생한다.

● 게임에 어떠한 패턴을 적용할 것인가?

: 특정 디자인 패턴이 정답이다. 라고 말할 수 없는 영역이 게임 디자인 패턴이라고 할 수 있다. 프로젝트에 상황에 따라 특정 디자인 패턴이 좋을 수도 있고 나쁠 수도 있기 때문이다. 하지만 게임에서는 MVC, MVP, MVVM이 되었든, 데이터와 화면과 시스템은 각각 분리되어 처리되어야만 한다.

예를들어 데이터와 화면이 연결되어 있다고 했을 때, 서버에서 데이터를 받아서 화면을 보여는 상황이면 게임은 멈춰있을 수 밖에 없게 된다. 데이터를 받아와야지만 화면이 보여지기 때문이다. 하지만 위의 패턴을 사용하면 화면은 모델에 데이터가 없으면 없는 그대로 사용자에게 보여줄 수도 있고, 모델의 이전 데이터를 가지고 보여주다가 서버에서 데이터를 받아오면 갱신해서 보여줄 수도 있다.

: 개인적으로는 MVP 패턴이 게임에 좀 더 친화적인 패턴이라고 생각한다. 이유는 다음과 같다.

▶ MVC는 Model과 View의 의존성이 강하고 Controller의 역할이 약하기 때문에 코드의 복잡성이 올라갈 수 있다.

▶ MVVM은 ViewModel의 갱신이 View에 즉시 이루어지기 때문에, 유저의 상호작용이 없는 상태에서 화면이 갱신될 수 있는 위험성이 있다.

▶ MVP는 Presenter의 역할이 집중되지만 그만큼 Presenter만 잘 작성한다면 View와 Model의 의존성도 없고 시스템이 Presenter로만 돌아갈 수 있는 단순함이 생긴다.