개발을 하다보면 필연적으로 데이터와 로직이 결합된 상태로 개발하게 된다.
규모가 커지면 커질수록 점점 코드는 복잡해지고, 데이터와 로직이 뒤섞여 더 이상 유지보수가 힘든 상황이 이르게 된다.
따라서 데이터(Model)와 로직(Controller)을 분리해주는 패턴으로부터 개발을 시작하는 게 좋다.

1. MVC패턴

MVC패턴이란 Model, View, Controller라는 요소가 들어있는 패턴이다.

요소

1. Model(데이터)

• 게임의 데이터가 저장되는 스크립트
• 로직이 아닌 순수 데이터가 들어가야 됩니다.
• 뷰나 컨트롤러에 대한 어떠한 정보도 가지지 않음.

2. Controller(조작)

• 게임의 핵심 로직들을 담당한다.
• Model들을 조작하고 업데이트된 Model들을 View에 통지해준다.

3. View(표시)

• 게임 내 외적으로 보이는 모든 요소를 조작한다.
• Controller에서 받은 데이터를 화면에 출력한다.
• Model에 대한 정보를 따로 저장해서는 안됨.
• Model이나 Controller에 대한 정보를 가지면 안됨.
• 재사용이 가능하면 최고!

마지막으로 결합도를 줄이기 위해 Model과 View는 Controller의 존재를 몰라야 한다.

장단점

장점

• 각 역할 별로 코드를 분리함으로서 각 기능에만 집중 가능. 관련 처리에 관해서 효율적이다.
• 부속 간 의존성이 낮아지고, 로직이나 화면을 수정 시 서로에게 영향을 주지 않고 수정할 수 있음.
• 유지보수에 용이하고, 확정성이나 재사용성이 높음
• 뷰와 비지니스 로직이 분리가 된는 만큼 디자이너와 개발자 사이 분업이 가능.

단점

• 설계 시간이 꽤 소요됨.
• MVC에서 View는 Controller에 연결되어 화면을 구성.(n:1의 관계)
  => 즉 Controller는 View의 Lifecycle과 강하게 연결되며 분리가 어렵다.
• 결과적으로 Model과 View 사이에 의존성을 띄우게 됨.(서로간의 의존성을 완전히 제거할 수 없음)
• 규모가 커질수록 MVC는 어쩔 수 없이 Controller에 많은 로직이 모임
  결과적으로 화면이 복잡할 경우 역으로 유지보수나 확장이 어려워짐

처리 과정

컨트롤러에서 데이터를 불러와서 활용할 수 있게 처리한 값을 뷰에 반환한다. 뷰에서는 받은 값으로 화면에 출력하던가 객체를 이동시킨다.
사용자(요청) -> Controller -> Model -> Controller -> View(응답)

결론

이 패턴의 장점은 데이터와 로직, 그리고 뷰를 나눠서 개발할 수 있다는 장점이 있다.
그러나 단점으로는 패턴에 대한 숙지가 먼저 되어있어야 하고, 고작 큐브 움직이는 코드를 만드는데도 꽤 많은 스크립트 파일이 만들어진다.

그러나 단점은 유지보수 측면으로 보았을 때 충본히 보완이 가능하다고 생각한다. 기존 개발 방식에 문제점을 느끼고, 새로운 방식의 개발 방법을 찾는다면 한번 시도해봐도 좋을 것 같다.

이러한 MVC의 단점을 보완한 MVVM패턴이나 MVP패턴이 등장
단 이들의 기초가 되는 만큼, MVC를 완벽히 이해하는 것이 중요하다.