사실 MVC 패턴 구조를 프로젝트할때도 많이 사용하였지만 프리코스 문제를 풀때만큼은 어떻게 적용해야할지 감도안오고 내 자신한태 물어봐도 제대로 속 시원하게 대답을 못했다. 그래서 요번 2차자동차게임 문제를 적용해 보기 위해서 쓰게되었다.
MVC 패턴이란
MVC는 Model -View - Controller 의 약자이다.
MVC 는 소프트웨어 디자인 패턴이며 MVC에서 모델은 어플리케이션 정보(데이터), View는 텍스트,체크박스 항목 등과 같이 사용자 인터페이스 요소를 나타내고 컨트롤러는 데이터와 비지니스 로직 사이의 상호 동작을 관리한다고 한다 . 이를 통해 관심사 분리가 이루어져 유지보수에 특히 탁월하다고 하고 다른 컴포넌트들에 종속되지 않아서 변경에 유리하다는 장점이 있다.
Model
Controller 에게 받은 데이터를 가공하는 역할을 수행하고, 각 Model이 수행해야 할 기능들,값을 가지는 형태이다. 특히 Model은 View,Controller에 대해서 어떤 정보도 알지 말아야하고 변경이 일어나면 그에 따른 처리방법을 구현해야한다.
View
사용자에게 어떤 View(UI)로 보여주며 화면에 무엇을 보여주기 위한 역할을 한다. 모델에서 처리한 결과를 View가 그 결과를 통해 사용자에게 출력할 화면을 만든다.
View 역시 Model과 똑같이 다른 컴포넌트들에 대해 알지 못해야 한다.
Controller
모델이 어떻게 처리할지를 알려주는 역할이다. 화면에서 사용자의 입력을 받아,처리 되는 부분이며 요청 내용을 토대로 Model,View에 업데이트 요청을 한다. 컨트롤러는 Model과 View 사이에 있는 셈이다.
역할을 보고나서 느낀점
분리된 역할이 분명하게 드러나면서 각 영역마다 하는 역할이 정해져있기때문에 클린코드 중 하나 함수(또는 메서드)가 한 가지 일만 하도록 최대한 작게 만들어라라는 부분을 해결 할 수 있을 것 같았다.
각 구성요소가 그 역할에 대해서 집중하고 다른 역할에 영향을 미치지 않도록 분리되기때문에 유연성을 갖고 유지보수성이 높아지는걸 알 수 있었던 것 같다.
MVC 의 한계
View 는 Controller에 연결되어 화면을 구성하는 단위요소여서 다수의 View를 가질수 있고 Model 도 Controller를 통해서 View와 연결 되기때문에 하나의 View에 연결될 수 있는 Model은 여러개가 될 수 있기때문에 뷰와 모델이 서로 의존성을 띄게 된다.
하지만 새 기능들이 점차 추가되면 프로젝트가 복잡해지고 커지기때문에 코드 분석/수정과 테스가 모두 힘들 수 있다는 점이 있다. 또한 model과 view는 여러 사이드 이펙트를 불러와 프로그램 운영을 힘들게 할 수 있다는 점이 있는것같다.
