Summry
본 문서에서는 MVC 패턴에 대해 정리한다.
send me email if you have any questions.
MVC 패턴?
MVC패턴은 디자인패턴 중 하나이다.
- 디자인 패턴이란 프로그램이나 어떤 특정한 것을 개발하는 중에 발생했던 문제점들을 정리해서 상황에 따라 간편하게 적용해서 쓸 수 있는 것을 정리하여 특정한 “규약”을 통해 쉽게 쓸 수 있는 형태로 만든 것을 말한다.
사용이유
어떠한 앱을 만든다고 한다면 그 앱을 유지보수를 하고 또 다른 개발자들과 공유를 하면서 만들어야 할 때 좀 더 쉽고 깔끔하게 만들 수 있는 방법을 우리는 고안해야 한다. 만약 이러한 방법들을 명확히 하지 않는다면 우리는 클래스 함수들을 일일히 다 만들어야 하게 될 것이다.
예를 들어 어떠한 data를 만들고 이 data를 수정할 로직을 짠다. 그리고 그 data를 보여주는 부분을 만들 때 이거 하나하나가 로직이 분리가 안되있고 한꺼번에 정의가 되어있다면 나중에 유지보수하기가 힘들것이다.
- 이것을 쉽고 편리하게 개발 및 유지보수를 할 수 있도록 만든 특정한 방법을 디자인 패턴이라고 한다.
- 디자인 패턴은 스트래티지 패턴, 옵저버 패턴 등등 여러가지가 있고 그 중에 하나가 바로 MVC패턴이다.
정리하면, MVC Pattern을 사용하는 것으로 서로 분리되어 각자의 역할에 집중할 수 있게끔하여 개발하는 것이 가능해지며 그렇게 만든 애플리케이션은 유지보수성, 확장성, 유연성이 증가하게 되고 코드의 중복또한 사라지게 될 것이다.
여기서 유연성이란 클라이언트의 새로운 요구사항에 대해 최소한의 비용으로 보다 유연하게 대처할 수 있는 것을 말한다.
MVC란
MVC는 Model, View, Controller의 약자이다.
- 하나의 애플리케이션, 프로젝트를 구성할 때 그 구성요소를 세가지의 역할로 구분한 패턴.
사용자가 controller를 조작하면 controller는 model을 통해서 데이터를 가져오고 그 정보를 바탕으로 시각적인 표현을 담당하는 View를 제어해서 사용자에게 전달하는 방식이다.
Model
Model은 어플리케이션이 “무엇을” 할 것인지를 정의 한다.
- 내부 비지니스 로직을 처리하기 위한 역할을 할 것이다.
- 처리되는 알고리즘, DB 와 상호작용(CRUD Create Read Update Delete), 데이터 등등..
모델의 규칙
- 사용자가 편집하길 원하는 모든 데이터를 가지고 있어야 한다.
- 뷰나 컨트롤러에 대해서 어떤 정보도 알지 말아야 한다.
- 변경이 일어나면, 변경 통지에 대한 처리방법을 구현해야만 한다.
View
View는 화면에 무엇인가를 “보여주기 위한 역할”을 한다.
- 컨트롤러 하위에 종속되어, 모델이나 컨트롤러가 보여주려고 하는 모든 필요한 것들을 보여줄 것이다.
- 최종 사용자에게 “무엇”을 화면(UI)으로 보여줌
뷰의 규칙
- 모델이 가지고 있는 정보를 따로 저장해서는 안된다.
- 모델이나 컨트롤러와 같이 다른 구성요소들을 몰라야 된다.
- 변경이 일어나면 변경통지에 대한 처리방법을 구현해야만 한다.
Controller
Controller는 모델이 “어떻게” 처리할 지를 알려주는 역할을 한다.
- 모바일에서는 화면의 로직처리 부분이다.
- 화면에서 사용자의 요청을 받아서 처리되는 부분을 구현한다.
- 요청 내용을 분석해서 Model과 View에 업데이트 요청한다.
- 사용자로 부터의 입력 을 받고 Model 또는 View중개인 역할
Controller는 Model과 View가 각각 무엇을 해야 할 지를 알고 있고, 통제해야 한다. 비지니스 로직을 처리하는 Model과 완전히 UI에 의존적인 View가 서로 직접 이야기 할 수 없게 한다.
컨트롤러의 규칙
- 모델이나 뷰에 대해서 알고 있어야 한다.
- 모델이나 뷰의 변경을 모니터링 해야 한다.
MVC의 한계점
MVC에서 View는 Controller에 연결되어 화면을 구성하는 단위요소이므로 다수의 View들을 가질 수 있다. 그리고 Model은 Controller를 통해서 View와 연결되어지지만, 이렇게 Controller를 통해서 하나의 View에 연결될 수 있는 Model도 여러개가 될 수 있다.
뷰와 모델이 서로 의존성을 띄게 된다.
- 즉, 화면에 복잡한 화면과 데이터의 구성 필요한 구성이라면, Controller에 다수의 Model과 View가 복잡하게 연결되어 있는 상황이 생길 수 있다.
- MVC가 너무 복잡하고 비대해져서, 새 기능을 추가할때마다 크고 작은 문제점을 가지고 소드 분석이나 테스트도 어렵게 된다.
- Controller는 View와 라이프 사이클과 강하게 연결되어있어서 분리할 수도 없고, 코드 분석/수정과 테스트가 모두 힘들게 된다.
- 복잡하게 엮어있는 모델과 뷰는 여러 Side-Effect를 불러와서 프로그램 운영이 힘들어진다.
따라서 위의 문제점을 보완한 여러 다양한 패턴들이 파생되었다.
MVP, MVVM, Viper, Clean Architecture, Flux, Redux, RxMVVM 등등..