Computer Science/디자인 패턴

[디자인 패턴] MVC 패턴(Model-View-Controller Pattern)

하다보면 되겠지 2023. 1. 13. 12:54

개요

정의 및 특징

  • Model + View + Controller 의 약자
  • 3가지 형태로 역할을 나누어 개발하는 방법론
  • 비즈니스 처리 로직과 사용자 인터페이스 요소를 분리시켜 서로 영향 없이 개발하도록 함
  • 사용자가 입력을 담당하는 View를 통해 요청을 보내면 해당 요청을 Controller가 받고, Controller는 Model을 통해 데이터를 가져오고, 해당 데이터를 바탕으로 출력을 담당하는 View를 제어해서 사용자에게 전달
  • MVC에 기반을 둔 디자인 패턴으로 MVVM, MVP, MVW 등이 있음

 

모델

  • 데이터와 애플리케이션이 무엇을 할 것인지를 정의하는 부분
  • 내부 비즈니스 로직을 처리하기 위한 역할
  • 컨트롤러가 호출하면 DB와 연동하여 사용자의 입출력 데이터를 다루는, 데이터와 연관된 비즈니스 로직을 처리함(데이터 추출, 저장, 삭제, 업데이트)
  • 여러 개의 데이터 변경 작업을 하나의 작업으로 묶은 트랜잭션을 다루는 일도 수행함
더보기
  1. 사용자가 편집하기를 원하는 모든 데이터를 가지고 있어야 함
    - 화면 안에 글자가 표현된다면 박스의 위치, 크기, 글자 포맷 정보 등을 가지고 있어야 함
  2. 뷰나 컨트롤러에 대해서 어떤 정보도 알지 말아야 함
    - 데이터 변경이 일어났을 때 모델에서 직접 UI를 수정할 수 있도록 뷰를 참조하는 내부 속성값을 가지면 안됨
  3. 변경이 일어나면, 변경 통지에 대한 처리방법을 구현해야만 함
    - 모델의 정보가 변경된다면 이벤트를 발생시켜 누군가에게 전달해야 함
    - 누군가가 모델을 변경하도록 요청하는 이벤트를 보냈을 때 이를 수신할 수 있는 처리 방법을 구현해야 함
    - 모델은 재사용가능해야 하며 다른 인터페이스에서도 변하지 않아야 함

 

뷰

  • 화면에 무엇인가를 보여주기 위한 역할
  • 사용자에게 보여주는 화면(UI)에 해당하며, 텍스트, 체크박스 항목과 같은 사용자 인터페이스 요소를 나타냄
  • 사용자와 상호작용을 하며 컨트롤러로부터 받은 모델의 결과값을 출력하는 화면을 만듦
더보기
  1. 모델이 가지고 있는 정보를 따로 저장해서는 안됨
    - 화면에 글자를 표시하기 위해 모델이 갖고 있던 정보를 전달받는데, 이 정보를 유지하기 위해 임의의 뷰 내부에 저장하면 안됨
    - 단순히 명령에 따라 정보를 표시하기만 하고, 그 정보들은 저장하지 않아야 함
  2. 모델이나 컨트롤러와 같은 다른 구성 요소들을 몰라야 함
    - 자기 자신을 제외하고는 다른 요소는 참조하거나 어떻게 동작하는지 알아서는 안됨
    - 그냥 데이터를 받으면 화면에 표시해주는 역할만 수행함
  3. 변경이 일어나면 변경 통지에 대한 처리 방법을 구현해야만 함
    - 화면에서 사용자가 내용을 변경하게 되면 이를 모델에게 전달해야 하며, 이 작업을 하기 위해 변경 통지를 구현함
    - 재사용이 가능하게끔 설계를 해야함

 

컨트롤러

  • 모델이 데이터를 어떻게 처리할지를 알려주는 역할
  • 비즈니스 로직을 처리하는 모델과 뷰 사이에 위치하며 둘이 서로 직접적으로 연결되지 않게 함
  • 클라이언트의 요청에 대해 모델과 뷰를 결정하여 전달하는 일종의 조정자 역할
  • 사용자가 데이터를 클릭하고 수정하는 것에 대한 “이벤트”들을 처리(+데이터 전처리)
  • 사용자의 요청 내용을 받아 Model과 View에 업데이트 요청을 보냄
  • 자바의 Spring에서는 DispatcherServlet으로 컨트롤러를 이해해야 함
더보기
  1. 모델이나 뷰에 대해서 알고있어야 함
    - 모델이나 뷰는 서로의 존재를 모르고 변경을 외부로 알리고/수신하는 방법만 갖고 있지만, 컨트롤러가 이를 중재하기 위해서는 모델과 그에 관련된 뷰에 대해서 알고 있어야 함
  2. 모델이나 뷰의 변경을 모니터링해야 함
    - 모델이나 뷰의 변경 통지를 받으면 이를 해석해서 각각의 구성 요소에게 통지해야 함
    - 애플레키에션의 메인 로직을 컨트롤러가 담당하게 됨

 

장점

  • 사용자 인터페이스로부터 비즈니스 로직을 분리하여 애플리케이션의 시각적 요소나 그 이면에서 실행되는 비즈니스 로직을 서로 영향 없이 쉽게 고칠 수 있음
  • 각 구성 요소들을 독립시켜 협업할 때 맡은 부분의 개발에만 집중할 수 있어 효율성을 높여줌
  • 서로 분리되어 각자의 역할에 집중할 수 있도록 개발하여 유지보수성, 애플리케이션의 확장성, 유연성이 증가하고 중복 코드도 줄어듦

 

단점(한계)

Massive ViewController (대규모 MVC 어플리케이션)

  • 모델과 뷰는 서로의 정보를 갖고 있지 않는 독립적인 상태라고 하지만, 모델과 뷰는 컨트롤러를 통해서 소통하기에 의존성이 완전히 분리될 수는 없음
  • 대규모 프로그램의 경우 화면에 복잡한 데이터의 구성이 필요하다면 컨트롤러에 다수의 모델과 뷰가 복잡하게 연결되는 상황이 생길 수 있음
  • 컨트롤러가 불필요하게 커지는 현상이 발생(Massive ViewController)
  • 컨트롤러는 뷰와 라이프 사이클과 강하게 연결되어 있어 분리할 수도 없고, 코드 분석/수정과 테스트가 모두 힘들어짐
  • 복잡하게 엮여있는 모델과 뷰는 여러 Side-Effect를 불러와 프로그램 운영을 힘들게 함

 

MVC 모델의 종류와 방식

MVC 구동 원리

MVC패턴은 Spring프레임워크와 JSP를 사용하는 웹 애플리케이션 개발에 많이 사용되고 있다. 이 때 웹 애플리케이션에서의 MVC의 구동 원리는 다음과 같다.

  1. 웹 브라우저가 웹 서버에 웹 애플리케이션 실행을 요청(MVC 구조가 WAS라고 보면 됨)
  2. 웹 서버는 들어온 요청을 처리할 수 있는 서블릿을 찾아서 요청을 전달(Matching)
  3. 서블릿은 모델 자바 객체의 메서드를 호출
  4. 데이터를 가공하여 값 객체를 생성하거나, JDBC를 사용하여 데이터베이스와의 인터랙션을 통해 값 객체를 생성
  5. 업무 수행을 마친 결과값을 컨트롤러에게 반환
  6. 컨트롤러는 모델로부터 받은 결과값을 View에게 전달
  7. JSP는 전달받은 값을 참조하여 출력할 결과 화면을 만들고 컨트롤러에게 전달
  8. 뷰로부터 받은 화면을 웹 서버에게 전달
  9. 웹 브라우저는 웹 서버로부터 요청한 결과값을 응답받으면 그 값을 화면에 출력

 

모델1

  • JSP에서 출력과 로직을 전부 처리 (컨트롤러와 뷰 영역을 같이 구현하는 방식)
  • 사용자의 요청을 JSP가 전부 처리
  • 빠르고 쉽게 개발할 수 있으나, JSP 파일이 너무 비대해지며 컨트롤러와 뷰가 혼재하므로 향후 유지보수에 어려움

⇒ 백엔드와 프론트엔드의 역할 분담이 모호해져 협업이 쉽지 않기 때문에 실제 서비스에서는 거의 사용하지 않음

 

모델2

  • JSP에서 출력만 처리
  • 사용자의 요청을 서블릿이 받고, 서블릿은 해당 요청으로 뷰로 보여줄지 모델로 보낼지 판단하여 전송
  • HTML 소스와 자바 소스를 분리해 놓았기 때문에 모델1 방식보다 확장시키기 쉽고 유지보수도 쉬움

 

References