MVC(Model-View-Controller) Pattern

MVC(Model-view-Controller) Pattern

• MVC(Model-view-Controller)는 기본적으로 가장 많이 사용하는 패턴이다.
• 개발 할때, 3가지 형태로 역할을 나누어 개발하는 방법론이며 비지니스 처리 로직과 사용자 인터페이스 요소들을 분리시켜 서로 영향없이 개발하기 수월하다는 장점이 있다.

 

Model

• Model은 어플리케이션이 무엇을 할 것 인지 정의 한다. 내부 비지니스 로직을 처리하기 위한 역할을 한다.
• 처리되는 알고리즘, DB와 상호작용(CRUD) 등등(CRUD는 REST글에서 살펴 볼 수 있다. 바로가기)

 

Controller

• Controller는 모델이 어떻게 처리할 지를 알려주는 역할을 할 것이다. 화면의 로직처리 부분이며 화면에서 사용자의 요청을 받아 처리되는 부분을 구현한다. 요청 내용을 분석해서 Model과 View에 업데이트를 요청한다.
• 사용자로 부터 입력을 받고 Model 또는 View의 중개 역할

 

View

• View는 화면에 무엇 인가를 보여주기 위한 역할을 한다. 컨트롤러 하위에 종속되면서 모델이나 컨트롤러가 보여주려고 하는 모든 필요한 것들을 보여줄 것이다.
• 최종으로 사용자에게 무엇을 UI로 보여준다.

 

 

Controller는 Model과 View가 무엇을 해야 할지 알고 있면서 통제하며, 비지니스 로직을 처리하는 Model과 완전히 UI에 의존적인 View는 서로 모르게 한다.

 

MVC의 한계

• MVC에서 View는 Controller에 연결되어 화면을 구성하는 단위요소이므로 다수의 View들을 가질 수 있다. 그리고 Model은 Controller를 통해서 View와 연결되어지지만, Controller를 통해 하나의 View에 연결될 수 있는 Model도 여러개가 될 수 있다. 따라서 View와 Model이 서로 의존성을 띄게된다. 즉 화면에 복잡한 화면과 데이터의 구성이라면, Controller에 다수의 Model과 View가 복잡하게 연결될 수 있는 상황이 생길 수 있다.
• MVC가 너무 복잡하고 비대해지면 새 기능을 추가할때마다 크고 작은 문제점을 가지고 소스 분석이나 테스트도 어려워 지는데, 이러한 형태의 MVC를 Massive ViewController(대규모 MVC 어플리케이션) 이라고 부른다. MVC의 한계를 표현 하였다고 한다.

 

 

대부분의 사람들은 MVC를 구성할때, View와 Model을 중재하는 Controller의 비중이 크지 않을 것이라고 생각하지만 복잡한 화면을 구현하게 되면 대규모 MVC 어플리케이션 형태로 구현하게 된다.

 

Controller는 View와 강하게 연결되어 있어 분리할 수도 없을 뿐더러 코드분석 및 수정과 테스트가 모두 힘들어진다. 복잡하게 엮여있는 모델과 뷰는 여러 이슈를 불러와서 프로그램 운영을 힘들게 한다고 한다.

 

그래서 MVC Pattan의 보완한 여러 다양한 패턴을 파생 시켰는데, MVP, MVVM, Viper, Clean Architecture, Flux, Redux, RxVVM등이 생겨났다.