[CS] MVC (Model, View, Controller) 디자인 패턴

 

Reference

• https://wooaoe.tistory.com/15
• MVC(Model, View, Controller) Pattern
• https://velog.io/@ljinsk3/MVC-%ED%8C%A8%ED%84%B4

MVC 패턴

MVC(Model, View, Controller) Pattern

[개발자 면접 대비] MVC 패턴 이란? (Model 1, Model 2)

---

MVC(Model, View, Controller) 패턴

wiki
모델-뷰-컨트롤러(Model-View-Controller, MVC)는 소프트웨어 공학에서 사용되는 소프트웨어 디자인패턴이다.

 

MVC 패턴은 애플리케이션을 세 개의 영역으로 분할하고 각 구성 요소에게 공한 역할을 부여하는 개발방식이다. 이를 도입하면 도메인(비즈니스 로직) 영역과 UI영역이 분리되므로 서로 영향을 주지 않고 유지보수가 가능하다.

 

※디자인패턴

건축으로 치면 공법에 해당하는 것으로 소프트웨어의 개발 방법을 공식화 한 것. 소수의 뛰어난 엔지니어가 해결한 문제를 다수의 엔지니어들이 처리 할 수 있도록 한 규칙이면서, 구현자들 간의 커뮤니케이션의 효율성을 높이는 기법이다.

 

MVC 패턴 구조

MVC 패턴 다이어그램 및 웹 어플리케이션에서 사용하는 일반적인 MVC 패턴

 

1. 모델(Model)

DATA, 정보들의 가공을 책임지는 컴포넌트를 말한다.

※컴포넌트(Component)란?

프로그래밍에 있어 재사용이 가능한 각각의 독립된 모듈을 뜻한다.

 

모델(Model)은 데이터베이스, 처음의 정의하는 상수, 초기화 값, 변수 등 어플리케이션의 정보, 데이터를 나타낸다. 백그라운드에서 동작하는 로직 (비즈니스 로직)을 처리한 후 모델의 변경사항을 컨트롤러(Controller)와 뷰(View)에 전달한다.

 

예를 들어 음식점 무인 포스기를 개발한다고 가정해보자. 무인포스기가 정상적으로 목표하는 작업을 수행하기 위해서는 우선 메뉴가 있어야하고, 메뉴를 담을 수 있는 장바구니, 해당 메뉴의 수량, 결제수단, 할인정책 등등이 필요할 것이다.

 

이처럼 프로그램이 목표하는 작업을 원활하게 수행하기 위해 필요한 물리적 개체, 규칙, 작업등의 요소들을 구분되는 역할로써 정의해놓은게 Model이 된다.

 

모델의 규칙

1. 사용자가 편집하길 원하는 모든 데이터를 가지고 있어야한다.
2. 뷰나 컨트롤러에 대해서 어떤 정보도 알면 안된다.
3. 변경이 일어나면, 변경 통지에 대한 처리 방법을 구현해야한다.

 

1. 뷰(View)

사용자에게 보여지는 부분, 즉 유저 인터페이스(User Interface)를 의미한다.

 

뷰(View)는 사용자가 보는 화면에 입출력 과정 및 결과를 보여주는 역할을 한다. 입출력의 순서나 데이터 양식은 컨트롤러에 종속되어 결정되고, 도메인 모델의 상태를 변환하거나 받아서 렌더링하는 역할을 한다.

 

뷰는 객체를 전달받아 상태를 출력하는 역할만을 담당해야하므로 뷰에서는 도메인 객체의 상태를 따로 저장하고 관리하는 클래스변수 혹은 인스턴스 변수가 있을 필요가 없다.

 

뷰의 규칙

1. 모델이 가지고 있는 정보를 따로 저장해서는 안된다.
2. 모델이나 컨트롤러와 마찬가지로 다른 구성요소들을 몰라야한다.
3. 변경이 일어나면, 변경통지에 대한 처리방법을 구현해야한다.

 

1. 컨트롤러(Controller)

모델(Model)과 뷰(View) 사이를 이어주는 브릿지(Bridge) 역할을 의미한다.

 

모델이나 뷰는 서로의 존재를 모르고 있으며, 변경사항을 외부로 알리고 수신 할 수만 있다. 컨트롤러(Controller)는 이를 중재하기 위해 모델과 뷰에 대해 알고 있어야하며, 모델이나 뷰로부터 변경 내용을 통지받으면 이를 각 구성 요소에게 통지해야 한다.

 

다시말해, 컨트롤러는 사용자가 접근한 URL에 따라서 사용자의 요청사항을 파악한 후, 그 요청에 맞는 데이터를 Model에 의뢰하고, 데이터를 View에 반영해서 사용자에게 알려주어야한다.

 

컨트롤러의 규칙

1. 모델이나 뷰에 대해서 알고있어야 한다.
2. 모델이나 뷰의 변경을 모니터링 해야한다.

 

MVC의 한계

복잡한 대규모 프로그램의 경우 다수의 뷰와 모델이 컨트롤러를 통해 연결되기 때문에 컨트롤러가 불필요하게 커지는 현상이 발생한다. 이렇게 되면 결과적으로 뷰와 모델이 서로 의존성을 띄게 된다.

또, 복잡한 화면을 구성하는 경우에도 동일한 현상이 발생하는데 이를 'Massive-View-Controller' 라고 한다.

 

이런 문제점을 보완하기 위해 다양한 패턴이 파생되었다.

• MVP 패턴: 컨트롤러의 뷰 구성기능은 모두 뷰 자체에 맡기고 프리젠터(presenter)가 모델과 뷰 사이의 인터페이스 역할만을 하도록 하는 것
• MVVM 패턴: 데이터 바인딩 기반으로 뷰가 뷰모델과 인터페이스하도록 제한을 두는 것
• Flux
• Redux
• RxMVVM

 

MVC모델 구현

• Model 1 방식

 

비즈니스 로직 영역(Controller)에 프레젠테이션 영역(View)을 같이 구현하는 방식이다.

사용자의 요청을 JSP가 전부 다 처리한다. 웹 브라우저 사용자의 요청을 받은 JSP는 자바빈이나 서비스 클래스를 사용하여 웹 브라우저가 요청한 작업을 처리하고 그 결과를 출력해준다.

 

 

장점

모델 1 방식을 채택하면 빠르고 쉽게 개발할 수 있다.

 

단점

JSP파일 자체가 너무 비대해지고, 컨트롤러와 뷰가 혼재하므로 향후 유지보수에 어려움을 겪을 수 있다.

 

 

• Model 2 방식

 

비즈니스 로직 영역과 프레젠테이션 영역이 분리되어 있는 구현 방식이다.

웹 브라우저 사용자의 요청을 서블릿(Servlet)이 받는다.

서블릿은 요청을 뷰로 보여줄 것인지, 모델로 보내줄 것인지 정하여 전송한다.  여기서 뷰 페이지는 사용자에게 보여주는 역할만 담당하고 실질적인 기능의 부분은 모델에서 담당한다.

 

 

장점

모델2 방식은 뷰와 컨트롤러를 분리하는 방식이다. 따라서 디자이너와 개발자의 분업이 가능하며 유지보수에 유리하다.

 

단점

설계에서 어려움을 겪을 수 있고, 개발 난이도가 높다.

 

 

※ Model 1의 방식으로 웹 서비스를 개발하는 사례는 아예 없다고 봐도 무방하다고 한다.
   백엔드와 프론트엔드 역할 분담이 모호해서 오히려 협업에 걸림돌이 된다고.