프로젝트에서 인벤토리의 기능들을 어느정도 완료하고 팀원들과 회의를 하던 도중
인벤토리를 MVC패턴으로 구조화 하면 좋을 것 같다는 요청이 있어서 실행해보려고 한다.
하지만 MVC패턴에 대한 개념과 이를 왜 쓰는지 이유를 정확히 알아야 구현과 유지보수에 있어서
흔들리지 않을 것이다. 그럼 MVC패턴이 무엇인지 살펴보자.
1. MVC(Model-View-Controller)
MVC란 모델, 뷰, 컨트롤러로 영역을 나눠서 기능을 담당하는 패턴이다.
Model
모델에서는 게임의 데이터, 데이터의 처리, 비즈니스 로직을 담당한다.
비즈니스 로직이란 어떻게 데이터가 생성되고 저장되고 수정되는지를 정의한다.
이말인 즉, 게임의 로직은 들어가면 안되며 비즈니스적인 로직만 담당해야 한다.
View
뷰에서는 영어 뜻 그대로 게임 내 외적으로 보이는 모든 요소들을 관리한다.
Controller에서 받은 데이터들을 화면에 출력하는 역할을 한다.
Controller -> View : Model의 Update된 데이터 전송
View -> controller : 외부 Event 전송
Controller
뷰와 모델의 상호작용을 관리하는 곳이며 게임의 핵심 로직을 관리한다.
모델과 뷰가 결합도의 영향이 생길만한 부분을 컨트롤러에서 모두 처리한다.
MVC 패턴에서 가장 중요한 것은 Model과 View는 Controller의 존재를 몰라야 한다.
Model, View, Controller 3가지 영역으로 나눈 이유는 각자의 기능을 독립적으로 담당하기 위해서인데
서로서로가 영향을 가지고 있다면 결합도가 증가하여 MVC패턴을 사용하는 목적을 잊게 될 것이다.
2. 인벤토리에서의 MVC 적용
Model
모델에서는 주로 게임의 로직이아닌 데이터의 처리나 데이터의 정보를 관리한다.
여기서 데이터의 처리는 데이터가 변경되는 것을 저장하고 서버에 보내주는 것까지 담당하는 것을 말한다.
그럼 모델 부분에 들어갈만한 인벤토리 내용은 아이템의 정보(데이터 정보), 아이템 리스트(데이터), 아이템의 추가, 삭제(데이터 처리) 와 같은 데이터 관련 정보들이 담겨있으면 좋을 것 같다.
View
뷰에서는 실제로 보여지는 부분을 담당하고 있기 때문에 UI의 처리를 담당하는 기능이 들어가면 좋을 것 같다.
예상 기능으로 인벤토리의 데이터를 업데이트 하여 UI를 다시 출력해주는 Update 기능이 들어갈 것 같다.
Controller
컨트롤러는 모델과 뷰의 상호작용을 다루기 때문에 모델에서의 데이터 변경, 처리 기능을 실행하고
View를 통해 UI를 업데이트 해주는 핵심 로직이 담겨있으면 좋을 것 같다.
결론
확실히 MVC 패턴 바로 적용해야지! 라는 마음으로 무작정 하는 것보다
개념을 바로 잡고 정리를 하니 내일 어떻게 구조를 바꿔야 할지 감이 잡힌다.
MVC패턴이란게 전공에서도 듣고 정보처리기사 할 때도 질리도록 들은 것 인데
직접 사용해보질 않으니 확실한 개념이 잡히지 않았었다. 하지만 이번 기회에
실제로 사용해보며 MVC 패턴을 확실하게 숙지해야겠다.
'프로젝트 기록 > Project N' 카테고리의 다른 글
인벤토리 개발 기록 (창고와 인벤토리) (0) | 2024.04.03 |
---|---|
UIManager 구현 기록 (1) | 2024.02.13 |
UIManager는 왜 만드는 걸까? (0) | 2024.02.07 |
인벤토리 기능 MVC 적용 (0) | 2024.02.01 |
팀원 코드 분석 / CSV란? (CSV Data) (2) | 2024.01.30 |