MVC(Model View Controller) 패턴
- 소프트웨어 디자인 패턴 중에 하나이다.
- 애플리케이션을 세 개의 구성요소로 분리하고, 각 구성요소에게 각자의 고유한 역할을 부여한다.
- 애플리케이션의 유저 인터페이스, 데이터, 비즈니스 로직을 구현하기 위해 사용하는 소프트웨어 디자인 패턴이다.
- 비즈니스 로직과 화면을 구성하는 코드를 구분하는 것을 중점으로 둔다.
- 유저 인터페이스로부터 비즈니스 로직을 분리하여 애플리케이션의 시각적 요소나 비즈니스 로직이 서로 영향을 주지 않도록 유지보수가 쉬운 애플리케이션을 만들기 위해 사용하는 패턴이다.
MVC 구성요소
MVC의 구성요소에는 모델(Model), 뷰(View), 컨트롤러(Controller)가 있다.
Model
모델은 애플리케이션의 데이터를 정의하고, 데이터와 비즈니스 로직을 직접 관리하는 구성요소다.
- 데이터가 변경되면 뷰가 화면을 변경할 수 있도록 뷰에게 데이터가 변경되었다는 것을 알린다.
- 데이터가 변경되면 뷰를 제어하기 위한 로직을 처리하기 위해 컨트롤러에게 데이터가 변경되었다는 것을 알리기도 한다.
View
뷰는 레이아웃과 화면을 처리하는 구성요소다.
즉, 사용자에게 보여지는 유저 인터페이스를 담당하는 구성요소다.
- 뷰는 애플리케이션의 데이터를 보여주는 방식을 정의한다.
- 뷰는 모델이나 컨트롤러가 화면에 보여주려고 하는 것들을 담당한다.
Controller
컨트롤러는 모델과 뷰를 이어주는 일종의 다리 역할을 한다.
- 컨트롤러는 애플리케이션 사용자의 입력에 대한 응답으로 모델 또는 뷰를 업데이트하는 로직을 포함하고 있다.
- 컨트롤러는 어떤 입력을 받아 모델이나 뷰를 위한 명령으로 바꿔주는 부분이다.
- 컨트롤러는 모델과 뷰에게 명령을 라우팅한다.
MVC의 관계
- 컨트롤러는 모델에 명령을 보내 모델의 상태를 변경한다. 또한 뷰가 유저 인터페이스를 업데이트하도록 뷰에게 명령을 보낸다.
- 모델은 자신의 상태에 변화가 생기면 이것을 컨트롤러와 뷰에게 알린다.
- 모델의 상태 변화를 뷰에게 알리는 이유는 뷰가 모델의 변경 사항을 반영해 유저 인터페이스를 업데이트하도록 하기 위해서다.
- 또한 모델의 상태 변화를 컨트롤러에게 알리는 이유는 컨트롤러가 모델의 변경 사항에 따라 적용 가능한 명령을 추가, 제거, 수정하기 위해서다.
- 뷰는 유저 인터페이스를 생성하고 업데이트하기 위해 모델로부터 정보를 얻는다.
MVC의 장점
- 각 컴포넌트가 고유한 역할을 담당하는 “관심사 분리”를 통해 애플리케이션 유지보수를 편리하게 해준다.
- 각 컴포넌트는 자신의 고유한 역할만 담당하고, 다른 컴포넌트에게 역할 수행의 결과만 전달하면 되기 때문에 시스템적인 결합도를 낮출 수 있다.
- 유지보수를 하더라도 유지보수가 필요한 컴포넌트만 수정하면 된다.
MVC의 한계
- 애플리케이션의 규모가 커질수록 모델과 뷰의 갯수가 많아지게 된다.
- 모델과 뷰는 컨트롤러로 연결되기 때문에 모델과 뷰를 제어하기 위해 컨트롤러가 계속 커지고 복잡해지게 된다.
- 이런 MVC의 한계를 보완하기 위한 다양한 소프트웨어 디자인 패턴이 등장하였다.
- MVP (모델-뷰-프리젠터)
- MVVM (모델-뷰-뷰모델)
- MVW (모델-뷰-왓에버)
참고
캐비지 개발 블로그입니다. :)