Unity로 게임을 개발할 때 유지보수를 신경쓰지 않고 개발하면 데이터와 로직이 엉켜 스파게티 코드가 되기 십상이다. 그래서 어떻게 하면 유지보수에 용이할까 생각하다가 MVC패턴에 대해 알게되어 정리해보려 한다.
[MVC (Model-View-Controller) 패턴]
<MVC 패턴이란?>
MVC 패턴은 Model, View, Controller 라는 요소로 코드를 분리하여 구성하는 패턴이다.
<Model>
- 게임의
데이터와 비즈니스 로직을 처리- 데이터 저장소와의 상호작용을 통해 데이터를 관리하는 역할을 수행
<View>
- 게임에서
외적으로 보이는 모든 요소들이다.- 모델의 데이터를 시각적으로 나타내는 역할을 수행
<Controller>
- 게임의 핵심
로직들이다.- 사용자의 입력을 받아 Model을 조작하여 데이터를 업데이트하고 View를 갱신하는 역할을 수행한다.
조금더 자세히 상호작용 방식을 설명해보자면, 1. 사용자가 게임에서 입력을 하면, 2. View는 사용자의 입력을 감지하고 Controller에게 전달한다. 3. Controller는 사용자의 입력을 처리하고 Model의 데이터를 업데이트 시킨다. 4. Model은 데이터와 관련된 비즈니스 로직을 수행하고, 필요한 경우 데이터베이스와 상호작용한다. 이후 완료된 결과를 Controller에 반환한다. 5. Controller는 Model의 결과를 받아 View에 전달한다. 6. View는 이 데이터를 사용하여 사용자에게 보여지는 화면을 갱신한다.
사실 우리는 이 패턴을 이미 알고 있다. Unity의 Player로 예를 들어보면 Model은 PlayerInfo, View는 Player 객체, Controller는 PlayerController이다.
이제 MVC 패턴이 무엇인지 알았으니 어떻게 설계해야되는지 알아보자
<MVC 패턴 설계원칙>
-
Model은 Controller와 View에 의존하면 안된다.
Model은 자신이 갖고 있는 데이터들을 알려줄 순 있지만, 그 정보들이 View에서 사용되는 지, Controller에서 사용되는 지 몰라야한다.
-
View는 Model에만 의존해야하고, Controller에는 의존하면 안된다.
View의 내부에서는 Model과 관련된 로직이 있는 것은 상관없지만, Controller와 관련된 로직이 있으면 안된다.
-
Controller는 Model과 View에 의존해도 된다.
Controoler는 Model과 View를 이어주는 역할이므로 Model과 View에 관련된 로직이 존재하는 것은 당연하다.
-
View가 Model으로부터 데이터를 받을 때, 반드시 Controller를 통해서 받아야 한다.
View가 Model을 호출하는 것도 Model이 View를 호출하는 것도 안된다. 반드시 Controller를 통해 데이터를 넘겨 받도록 하자.
-
코드의 재사용성과 확장성을 고려해야한다.
각 구성 요소는 독립적이고 재사용 가능한 모듈로 개발해야한다. 그래야 프로젝트의 규모가 커질 때 쉽게 확장 및 수정이 가능하다. 코드를 최대한 재사용하기 쉬운 구조로 개발하여 다른 프로젝트에서도 사용할 수 있도록 개발하는 것이 베스트이다.
<MVC 패턴의 장점>
- 각 구성 요소가 독립적으로 개발되므로 명확하게 분리되어 있어 유지 보수가 용이하다.
- 구성 요소들 간의 결합도가 낮아 코드의 재사용성이 높아지며, 개별 구성 요소를 따로 개발할 수 있다.
