[디자인패턴] - MVC, MVVM 패턴
기존에 스프링 프레임워크를 사용한 백엔드 프로젝트를 제작시 스프링 프레임워크에는 MVC패턴을 기반으로 설계되어있다. 라고 학습한 경험이 있습니다.
현재 언리얼 엔진을 사용한 게임 클라이언트 관련 프로젝트를 진행하며 디자인 패턴 및 아키텍처 설계에 대해 고민하게 되었으며, 언리얼에서도 학습했던 MVC 패턴을 적용 할 수 있을지에 대해 고민하던 중, 다시 리마인드하며 학습한 MVC,MVVM패턴에 대해 작성하겠습니다.
MVC (Model - View - Controller) 패턴
정의
소프트웨어 아키텍처 설계시 사용 할 수 있는 디자인 패턴 중 하나입니다.
어플리케이션을 모델(Model), 뷰 (View), 컨트롤러(Controller)로 분리하여 관심사를 분리하며 유지보수성 및 확장성을 높이는 구조입니다.
UI기반의 어플리케이션 계층에서 자주 사용되는 패턴 중 하나입니다.
모델 (Model)
- 어플리케이션의 데이터 및 비즈니스 로직을 관리하는 부분
- 데이터베이스와 연동되거나, 내부적으로 데이터 처리, 유효성검사와같은 작업을 수행한다.
- 독립적으로 작동하며 뷰와 컨트롤러와 직접적으로 통신하지 않는다.
- 언리얼에서의 Model : 캐릭터 Info 관련 Property, 스킬, GameState및 GameInstance를 사용한 게임 상태 관리
뷰 (View)
- 유저에게 화면을 표시하는 역할
- 모델에서 받은 데이터를 시각적으로 표현한다.
- Model과 직접적으로 통신하는것이 아닌, Controller에 의해서 받아온다.
- 사용자의 입력을 받아 컨트롤러에 전달한다.
- UI (체력 바, 미니맵, 스코어 표시 등)
컨트롤러 (Controller)
- 사용자의 입력을 처리하며, 어플리케이션의 전체적인 흐름을 관리
- 뷰에서 전달한 사용자의 입력을 분석, 입력에 맞는 모델의 데이터를 변경, 뷰 최신화
- 키보드 입력과 같은 Input Action
- UI 버튼(뷰) 클릭 시 특정 기능 수행
MVC 패턴 장단점
- M-V-C 각각의 역할을 명확하게 구분하여 결합도가 낮다. 확장성이 높다.
- 모델은 독립적이며, 다른 View에서도 재사용이 가능하다. 재사용성이 높다.
- M-V-C 각각의 역할이 분리되어있어 코드 충돌을 방지하기 쉽다.
- 작은 프로젝트에서는 오히려 코드가 많아지고, 복잡도가 증가할 수 있다.
- M-V가 직접 연결되지 않는 설계가 필요하다.
- 모델 변경시 뷰가 자동 갱신되지 않으면 추가적인 데이터 바인딩이 필요할 수 있다.
MVVM (Model - View - ViewModel) 패턴
정의
MVVM(Model-View-ViewModel) 패턴은 MVC패턴과 같은 아키텍처 패턴 중 하나로, MVC패턴에서 확장된 패턴입니다.
Controller 대신 ViewModel이 사용되었으며, 뷰 모델이 모델에 있는 데이터 객체를 노출하는 책임을 지기때문에 객체를 관리하고, 표현하기 위해 확장되었습니다.
Model(모델)
- MVC패턴과 같은 역할을 한다.
- 데이터 처리, 로직, 유효성 검사 등
- HP,Level,Skill 등
View(뷰)
- 사용자가 화면에서 보는것들에 대한 구조, 배치, 외관 등 시각적 요소
- ViewModel과 데이터 바인딩을 통해 데이터를 표시한다.
- 체력 바, 점수, 미니맵 등
ViewModel(뷰 모델)
- Model과 View 사이의 중개 역할
- Model에서 데이터를 가져와 View가 이해할 수 있는 형태로 변환
- 데이터 바인딩을 사용한 View와 자동 동기화
- Model int32 HP -> View UTextBlock HP:100 표시 등
MVVM 패턴 장단점
- ViewModel 활용한 UI(View) ,Model간 데이터 자동 동기화
- UI와 비즈니스 로직을 분리할 수 있다.
- ViewModel이 중개자 역할을 하며 로직을 처리하므로 각각의 역할이 분리된다.
- UI를 변경해도 수정사항이 없다. 서로 관심사를 분리하여 유지보수성 및 확장성이 높다.
- 데이터 바인딩을 하는 추가작업 필요 및 바인딩으로 인한 메모리 소모가 크다.
출처 및 참고내역
D