모델-뷰-컨트롤러
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
1. 개요
모델-뷰-컨트롤러(MVC)는 소프트웨어 디자인 패턴으로, 1979년 제록스 팰러앨토 연구소의 트리그브 린스카우에 의해 처음 소개되었다. MVC는 애플리케이션을 모델, 뷰, 컨트롤러의 세 가지 구성 요소로 나누어, 데이터 관리, 사용자 인터페이스 표현, 사용자 입력 처리를 분리한다. 이 패턴은 그래픽 사용자 인터페이스 개발에 중요한 통찰력을 제공했으며, 웹 애플리케이션 및 다양한 프로그래밍 환경에서 널리 사용되고 있다. MVC는 프로그램의 가독성을 높이고 사용자 인터페이스 교체를 용이하게 하며, 다양한 파생 패턴과 장점을 가지고 있지만, 구현의 복잡성이라는 단점도 존재한다.
더 읽어볼만한 페이지
- 프로그래밍 패러다임 - 지식 표현
지식 표현은 컴퓨터가 인간의 지식을 이해하고 활용하도록 정보를 구조화하는 기술이며, 표현력과 추론 효율성의 균형, 불확실성 처리 등을 핵심 과제로 다양한 기법과 의미 웹 기술을 활용한다. - 프로그래밍 패러다임 - 의도적 프로그래밍
의도적 프로그래밍은 프로그래머의 의도를 명확히 포착하고 활용하여 소프트웨어 개발 생산성을 향상시키기 위한 프로그래밍 패러다임으로, 트리 기반 저장소를 사용해 코드 의미 구조를 보존하고, WYSIWYG 환경에서 도메인 전문가와 협업하며, 코드 상세 수준 조절 및 자동 문서화를 통해 가독성과 유지보수성을 높이는 데 중점을 둔다. - 소프트웨어 디자인 패턴 - 스케줄링 (컴퓨팅)
스케줄링은 운영 체제가 시스템의 목적과 환경에 맞춰 작업을 관리하는 기법으로, 장기, 중기, 단기 스케줄러를 통해 프로세스를 선택하며, CPU 사용률, 처리량 등을 기준으로 평가하고, FCFS, SJF, RR 등의 알고리즘을 사용한다. - 소프트웨어 디자인 패턴 - 상태 패턴
상태 패턴은 객체의 내부 상태 변화에 따라 행동을 동적으로 변경하여 객체가 클래스를 바꾸는 듯한 효과를 주며, 유한 상태 기계 구현에 유용하지만 상태가 많아지면 코드 관리가 복잡해질 수 있다. - 소프트웨어 구조 - Ajax
Ajax는 웹 페이지 전체를 새로고침하지 않고 비동기적으로 서버와 통신하여 웹 애플리케이션의 일부를 업데이트하는 웹 개발 기술로, XMLHttpRequest 객체의 등장으로 가능해졌으며 HTML, CSS, DOM, JavaScript, JSON 등의 기술을 통합하여 동적인 사용자 인터페이스를 구현한다. - 소프트웨어 구조 - 멀티테넌시
멀티테넌시는 단일 애플리케이션 인스턴스로 여러 고객에게 서비스를 제공하여 SaaS 및 클라우드 환경에서 비용과 관리 효율성을 높이고 데이터 활용 가치를 창출하는 소프트웨어 아키텍처 방식이다.
| 모델-뷰-컨트롤러 | |
|---|---|
| 개요 | |
| 유형 | 소프트웨어 디자인 패턴 |
| 분류 | 아키텍처 패턴 |
| 목적 | 데이터 모델과 사용자 인터페이스 간의 관심사 분리 애플리케이션의 유지보수성 향상 애플리케이션의 테스트 용이성 향상 |
| 솔루션 | 데이터 모델, 사용자 인터페이스, 그리고 컨트롤러로 책임을 분리한다. |
| 참가자 | 모델 뷰 컨트롤러 |
| 관련 패턴 | 계층 아키텍처 프레젠테이션-추상화-제어 (PAC) 모델-뷰-프레젠터 (MVP) 모델-뷰-모델 뷰모델 (MVVM) |
| 설명 | |
| 문제 | 사용자 인터페이스 로직과 비즈니스 로직이 결합되어 애플리케이션의 유지보수성과 테스트 용이성이 저하된다. |
| 해결책 | 모델: 애플리케이션의 데이터를 관리하고 비즈니스 로직을 수행한다. 뷰: 사용자에게 데이터를 표시하고 사용자 입력을 받는다. 컨트롤러: 사용자 입력을 처리하고 모델과 뷰를 업데이트한다. |
| 구조 | 모델, 뷰, 컨트롤러는 서로 독립적으로 존재하며, 컨트롤러를 통해 상호 작용한다. |
| 상호 작용 | 사용자는 뷰를 통해 애플리케이션과 상호 작용한다. 뷰는 사용자 입력을 컨트롤러에게 전달한다. 컨트롤러는 사용자 입력을 처리하고 모델을 업데이트한다. 모델은 데이터 변경을 뷰에게 알린다. 뷰는 모델의 데이터를 기반으로 사용자 인터페이스를 업데이트한다. |
| 장점 | |
| 관심사 분리 | 모델, 뷰, 컨트롤러는 서로 독립적으로 존재하므로, 각 구성 요소의 변경이 다른 구성 요소에 미치는 영향을 최소화할 수 있다. |
| 유지보수성 향상 | 각 구성 요소의 코드가 간결해지고, 변경 사항을 쉽게 적용할 수 있다. |
| 테스트 용이성 향상 | 각 구성 요소를 독립적으로 테스트할 수 있다. |
| 재사용성 향상 | 모델, 뷰, 컨트롤러를 다른 애플리케이션에서 재사용할 수 있다. |
| 병렬 개발 가능 | 모델, 뷰, 컨트롤러를 서로 다른 개발자가 동시에 개발할 수 있다. |
| 단점 | |
| 복잡성 증가 | 애플리케이션의 구조가 복잡해질 수 있다. |
| 학습 곡선 | MVC 패턴을 이해하고 적용하는 데 시간이 걸릴 수 있다. |
| 지나치게 일반화 | 간단한 사용자 인터페이스의 경우 MVC 패턴을 적용하는 것이 불필요할 수 있다. |
| 변형 | |
| 모델-뷰-프레젠터 (MVP) | 뷰가 모델에 직접 접근하지 않고, 프레젠터를 통해 모델과 상호 작용한다. |
| 모델-뷰-모델 뷰모델 (MVVM) | 뷰모델이 뷰의 상태와 동작을 캡슐화하고, 뷰는 뷰모델의 데이터를 바인딩한다. |
| 구현 | |
| 웹 프레임워크 | Ruby on Rails Django Spring MVC ASP.NET MVC |
| 클라이언트 측 프레임워크 | AngularJS React Vue.js |
| 관련 디자인 패턴 | |
| 복합체 패턴 | 복잡한 사용자 인터페이스를 구성하는 데 사용될 수 있다. |
| 전략 패턴 | 컨트롤러에서 사용할 알고리즘을 선택하는 데 사용될 수 있다. |
| 관찰자 패턴 | 모델의 변경 사항을 뷰에게 알리는 데 사용될 수 있다. |
| 역사 | |
| 기원 | 1970년대 스몰토크 |
| 창시자 | 트리그베 린스키오 |
2. 역사
MVC는 그래픽 사용자 인터페이스 초기 개발에서 중요한 통찰력 중 하나였으며, 소프트웨어 구성을 책임 측면에서 설명하고 구현하는 최초의 접근 방식 중 하나가 되었다.[5]
원래 스몰토크에서의 윈도우 프로그램 개발을 위한 설계 지침으로 시작되었지만, 구조가 복잡해지기 쉬운 그래픽 사용자 인터페이스(GUI)를 가진 소프트웨어에서의 유용성 때문에 다른 분야로 확산되었다.
Squeak에서는 Self에서 이식된 GUI 툴킷 Morphic이 주로 사용되었다. Morphic에서는 뷰와 컨트롤러를 분리하지 않았으며, 이후 많은 GUI 툴킷에서도 뷰와 컨트롤러는 완전히 분리되지 않았다.
2. 1. 초기 역사
MVC는 1979년 제록스 팰러앨토 연구소에서 스몰토크 관련 일을 하던 트리그브 린스카우가 최초로 소개했다.[52] 트리그브 린스카우는 1970년대 후반, 제록스 팔로알토 연구소(PARC)에서 객원 과학자로 스몰토크-79 작업을 하면서 MVC를 만들었다.[6][7][8] 그는 사용자가 크고 복잡한 데이터 집합과 상호 작용하는 모든 프로그램을 구조화하는 데 사용할 수 있는 패턴을 원했다. 처음에는 모델, 뷰, 씽, 편집기 네 부분으로 구성되었으나, 다른 스몰토크 소프트웨어 개발자들과 논의 후 모델, 뷰, 컨트롤러로 결정했다.[6]최종 디자인에서 모델은 프로그램의 일부를 순수하고 직관적으로 나타낸다. 뷰는 모델의 시각적 표현으로, 사용자에게 표시할 데이터를 모델에서 가져와 사용자와 모델 간에 요청을 주고받는다. 컨트롤러는 화면에 여러 뷰를 배치하고 조정하며 사용자 입력을 받고 기본 뷰에 적절한 메시지를 보내는 사용자 인터페이스의 조직적인 부분이다. 이 디자인에는 특정 뷰를 수정하는 데 사용되는 특수한 종류의 컨트롤러인 편집기도 포함되어 있으며, 해당 뷰를 통해 생성된다.[6]
관련 구현은 《스몰토크-80에서의 애플리케이션 프로그래밍: 모델-뷰-컨트롤러를 사용하는 방법》[53]에서 깊이 있게 설명되었다. 스몰토크-80은 이 디자인에서 진화한 MVC 버전을 지원한다.[6] 추상 `view` 및
controller 클래스와 다양한 구체적인 하위 클래스를 제공하며, 각 클래스는 다양한 일반 소프트웨어 위젯을 나타낸다. 이 구조에서 `View`는 사용자에게 정보를 표시하는 방식을 나타내고, controller는 사용자가 view와 상호 작용하는 방식을 나타낸다. `view`는 모델 객체에도 연결되지만 해당 객체의 구조는 애플리케이션 프로그래머에게 맡겨진다. 스몰토크-80 환경에는 주어진 모델, 뷰 및 컨트롤러의 구조를 나란히 볼 수 있는 개발 도구인 "MVC 검사기"도 포함되어 있다.[9]1988년 ''객체 기술 저널''(JOT)의 기사에서 MVC는 스몰토크-80 개발자를 위한 일반적인 "프로그래밍 패러다임 및 방법론"으로 제시되었다.[10] 그러나 이 구조는 린스카우 등의 구조 및 스몰토크-80 참고 서적에서 제시된 구조와 달랐다. 뷰는 모든 그래픽 관련 문제, 컨트롤러는 사용자 입력을 받고 하나 이상의 뷰와 단 하나의 모델과 상호 작용하는 더 추상적이고 일반적으로 보이지 않는 객체로 정의되었다.[10]
이후 MVC 패턴은 계층적 모델-뷰-컨트롤러(HMVC), 모델-뷰-어댑터(MVA), 모델-뷰-프레젠터(MVP), 모델-뷰-뷰모델(MVVM) 등 다양한 변형으로 진화했다.[11]
1996년 넥스트의 WebObjects 도입 후 웹 애플리케이션에서 널리 사용되었으며, 이는 원래 Objective-C로 작성되었고(스몰토크에서 크게 차용) MVC 원칙을 강화하는 데 도움이 되었다. 이후 WebObjects가 Java로 이식되면서 자바 개발자들에게 인기를 얻었다. Spring(2002년 10월 출시)과 같은 자바용 후속 프레임워크는 자바와 MVC 간의 강력한 유대 관계를 유지했다.
2002년 11월 W3C는 미래의 웹 애플리케이션에 사용될 X폼즈(XForms) 아키텍처에 MVC 구조를 포함하기로 가결하였다.[54] 이 규격은 XHTML 2.0 규격에 바로 통합될 것이다. 현재 20개가 넘는 업체가 애플리케이션 스택에 MVC가 통합된 X폼즈 프레임워크를 지원하고 있다.
1994년 「Design Patterns: Elements of Reusable Object-Oriented Software」[47] 내에서 다뤄졌다.
2003년, 마틴 파울러는 ''엔터프라이즈 애플리케이션 아키텍처 패턴''을 출판했는데, 이 책에서 MVC를 "입력 컨트롤러"가 요청을 받고, 모델 객체에 적절한 메시지를 보내고, 모델 객체에서 응답을 가져와 표시할 적절한 뷰로 응답을 전달하는 패턴으로 제시했다. 이는 루비 온 레일스 웹 애플리케이션 프레임워크(2004년 8월)에서 취하는 접근 방식과 유사하다.[12] Django 프레임워크(2005년 7월, 파이썬용)는 뷰가 모델에서 데이터를 가져와 표시할 템플릿에 전달하는 유사한 "모델 템플릿 뷰"(MTV) 패턴을 제시했다.[13] Rails와 Django는 모두 빠른 배포에 대한 강력한 강조를 통해 데뷔하여, 오랫동안 인기를 누려온 전통적인 엔터프라이즈 환경 밖에서 MVC의 인기를 높였다.
MVC는 그래픽 사용자 인터페이스 초기 개발에서 중요한 통찰력 중 하나였으며, 소프트웨어 구성을 책임 측면에서 설명하고 구현하는 최초의 접근 방식 중 하나가 되었다.[5]
원래 스몰토크에서의 윈도우 프로그램 개발을 위한 설계 지침으로 시작되었지만, 구조가 복잡해지기 쉬운 그래픽 사용자 인터페이스(GUI)를 가진 소프트웨어에서의 유용성 때문에 다른 분야로 확산되었다.
2. 2. 발전과 대중화
1979년 제록스 팰러앨토 연구소에서 스몰토크 관련 일을 하던 트리그브 린스카우가 MVC를 최초로 소개했다.[52] 1988년에는 전 PARC 직원 2명이 작성한 ''객체 기술 저널''(JOT)의 기사에서 MVC를 스몰토크-80 개발자를 위한 일반적인 "프로그래밍 패러다임 및 방법론"으로 제시했다.[10]MVC 패턴은 이후 계층적 모델-뷰-컨트롤러 (HMVC), 모델-뷰-어댑터 (MVA), 모델-뷰-프레젠터 (MVP), 모델-뷰-뷰모델 (MVVM) 등 다양한 변형 패턴을 낳았다.[11] 특히 모델 뷰 프리젠터 패턴은 1990년대 초기부터 등장하여 MVC의 진화된 모습을 목표로 설계되었다.[52]
1996년 넥스트의 WebObjects가 도입된 후 MVC 패턴은 웹 애플리케이션에서 널리 사용되었다. WebObjects는 원래 Objective-C로 작성되었고(스몰토크에서 크게 차용) MVC 원칙을 강화하는 데 도움이 되었다. 이후 WebObjects가 Java로 이식되면서 MVC 패턴은 자바 개발자들에게 인기를 얻었다. Spring (2002년 10월 출시)과 같은 자바용 후속 프레임워크는 자바와 MVC 간의 강력한 유대 관계를 유지했다.
2002년 11월 W3C는 미래의 웹 애플리케이션에 사용될 X폼즈(XForms) 아키텍처에 MVC 구조가 포함되도록 투표하여 가결하였다.[54]
2003년 마틴 파울러는 ''엔터프라이즈 애플리케이션 아키텍처 패턴''을 출판했는데, 이 책에서 MVC를 설명했다. 이는 루비 온 레일스 웹 애플리케이션 프레임워크 (2004년 8월)에서 취하는 접근 방식과 유사하다.[12] Django 프레임워크 (2005년 7월, 파이썬용)는 뷰가 모델에서 데이터를 가져와 표시할 템플릿에 전달하는 "모델 템플릿 뷰" (MTV) 패턴을 제시했다.[13]
다음은 MVC 발전과 대중화와 관련된 주요 사건들을 정리한 표이다.
| 연도 | 사건 |
|---|---|
| 1979년 | 팰러앨토 연구소에서 트리그브 린스카우가 MVC 고안[43][44] |
| 1988년 | MVC에 관한 논문 「A Cookbook for Using the Model-View-Controller User Interface Paradigm in Smalltalk -80」[45] 공개[46] |
| 1994년 | 서적 「Design Patterns: Elements of Reusable Object-Oriented Software」[47]에서 다뤄짐 |
| 1996년 | 넥스트의 WebObjects 도입 |
| 1999년 | MVC의 서버 측 구현으로 JavaServer Pages Model 2 발표[48] |
| 2002년 | Spring 출시, W3C에서 X폼즈(XForms) 아키텍처에 MVC 구조 포함 |
| 2003년 | 마틴 파울러의 엔터프라이즈 애플리케이션 아키텍처 패턴 출판 |
| 2004년 | 루비 온 레일스 웹 애플리케이션 프레임워크 출시 |
| 2005년 | Django 프레임워크 출시 |
2. 3. 한국에서의 MVC
모델-뷰-컨트롤러(MVC)는 1979년 제록스 팰러앨토 연구소에서 스몰토크 관련 연구를 하던 트뤼그베 렌스카우그(Trygve Reenskaug)가 최초로 소개했다.[52] MVC의 구현은 《스몰토크-80에서의 애플리케이션 프로그래밍: 모델-뷰-컨트롤러를 사용하는 방법》이라는 영향력 있는 논문에서 자세히 설명되었다.[53]MVC는 여러 파생 패턴을 가지고 있는데, 그 중 마이크로소프트가 사용하여 가장 널리 알려진 것은 1990년대 초부터 등장한 모델 뷰 프리젠터 패턴이다. 이 패턴은 MVC를 개선하기 위해 설계되었으나, 모델-뷰-컨트롤러 패턴은 여전히 널리 사용되고 있다.
2002년 11월 W3C는 미래 웹 애플리케이션에 사용될 X폼즈(XForms) 아키텍처에 MVC 구조를 포함시키는 것을 투표로 가결했다.[54] 이 규격은 XHTML 2.0 규격에 통합될 예정이다. 현재 20개가 넘는 업체가 애플리케이션 스택에 MVC가 통합된 X폼즈 프레임워크를 지원하고 있다.
3. 구성 요소
모델-뷰-컨트롤러(MVC)는 응용 프로그램을 세 가지 구성 요소로 나누며, 각 구성 요소는 다음과 같은 관계를 가진다.[51]
- 컨트롤러: 모델에 명령을 보내 모델의 상태를 변경하거나(예: 워드 프로세서에서 문서 편집), 관련된 뷰에 명령을 보내 모델의 표시 방법을 변경한다(예: 문서 스크롤).
- 모델: 모델의 상태 변화를 컨트롤러와 뷰에 통보한다. 뷰는 최신 결과를 표시하고, 컨트롤러는 모델 변화에 따라 명령을 수정한다. 일부 MVC 구현에서는 뷰나 컨트롤러가 직접 모델의 상태를 읽어 오기도 한다.
- 뷰: 사용자에게 보여줄 결과물을 생성하기 위해 모델로부터 정보를 얻는다.
UI에서의 입력과 출력은 본질적으로 분리하기 어려워 뷰와 컨트롤러를 항상 분리할 수 있는 것은 아니다. 이러한 모델-뷰-컨트롤러(M-VC) 구조를 Document-View라고 부른다.[49]
3. 1. 모델 (Model)
모델(model)은 모델-뷰-컨트롤러(MVC) 패턴의 핵심 구성 요소로, 사용자 인터페이스와 독립적인 애플리케이션의 동적 자료 구조이다.[14] 모델은 애플리케이션의 데이터, 로직 및 규칙을 직접 관리한다.[14]모델은 어떠한 동작을 수행하는 코드를 말하며, 표시 형식에 의존하지 않는다. 즉, 사용자에게 어떻게 보일지에 대해 신경쓰지 않아도 된다. 모델은 순수하게 public 함수로만 이루어지며, 몇몇 함수들은 사용자의 질의(query)에 대해 상태 정보를 제공하고 나머지 함수들은 상태를 수정한다.
자바 언어에서 모델은 `java.util.Observable`을 상속받아 만들 수 있다. 모델에는 현재의 상태 정보를 변경하거나 다른 클래스에게 알릴 수 있는 함수가 있어야 한다. 모델의 상태를 변경하는 함수(mutator)는 `setChanged()`와 `notifyObservers()`를 호출하여야 한다. `notifyObservers`는 모델에 등록된 모든 뷰에게 업데이트 메시지를 보내게 된다.
뷰는 모델의 상태 변화에 대한 통보를 받거나, 직접 모델의 상태를 읽어 오기도 한다. 모델은 `addObserver`라는 함수를 이용하여 뷰를 자신에게 등록시키고, 자신의 상태가 바뀌면 등록된 모든 뷰에 `notify` 함수를 호출하여 뷰를 업데이트한다. 모델은 여러 개의 뷰를 가질 수 있으며, 뷰 또한 여러 개의 모델에 등록될 수 있다.
모델은 데이터를 체계적으로 유지하고 일관성을 유지하는 데 필수적이다. 이는 애플리케이션의 데이터가 정의된 규칙과 로직에 따라 작동하도록 보장한다. WebObjects, Rails 및 Django에서 모델 유형은 일반적으로 애플리케이션의 객체 관계형 매핑에서 데이터베이스의 테이블을 표현한다.[16][17][18]
MVC에서 모델은 해당 애플리케이션이 다루는 영역의 데이터와 절차(비즈니스 로직)를 나타내는 요소이다. 또한, 데이터의 변경을 뷰에 통지하는 것도 모델의 책임이다(모델의 변경을 통지하는 데 옵저버 패턴이 사용되기도 한다).
3. 2. 뷰 (View)
MVC에서 모델은 여러 개의 뷰를 가질 수 있다. 뷰는 보여줄 값(모델)을 컨트롤러로부터 받아와 사용자에게 보여준다.자바언어에서 모델은 `java.util.Observable`을 상속받아 만들 수 있다. 모델에는 현재의 상태 정보를 변경하거나 다른 클래스에게 알릴 수 있는 함수가 있어야 한다. 모델의 상태를 변경하는 함수(mutator)는 `setChanged()`와 `notifyObservers()`를 호출하여야 한다.[51] `notifyObservers()`는 모델에 등록된 모든 뷰에게 업데이트 메시지를 보내게 된다. 뷰는 `java.util.Observer`를 구현(implement)하여 만들면 update method를 구현할 수 있다. `update()`함수의 두 번째 매개변수는 Object 모델에서 넘어온 추가정보를 받는 데에 사용된다.
```java
interface Observer
{ void update(Observable t, Object o);
}
```
뷰는 반드시 모델에게 질의하여 업데이트하는 부분이 구현되어야 한다. 모델은 `addObserver()`라는 함수를 이용하여 뷰를 자신에게 등록시킨다. 모델은 자신에게 등록된 모든 뷰를 기억하고 있다가 자신의 상태가 바뀌게 되면 등록된 모든 뷰에 notify 함수를 호출하여 뷰를 update시킨다. 모델은 뷰를 여러 개 가질 수 있으며, MVC에서는 이것을 허용하고 있다. 또한 뷰도 여러개의 모델에 등록될 수 있다.[51]
정보를 나타내는 모든 것, 예를 들어 차트, 다이어그램 또는 표 등이 이에 해당한다. 동일한 정보에 대해 여러 개의 뷰가 가능하며, 예를 들어 관리자를 위한 막대 차트와 회계사를 위한 표 형태의 뷰가 있을 수 있다.[51]
Smalltalk-80에서 뷰는 모델의 시각적 표현일 뿐이며 사용자 입력을 처리하지 않는다.[19] WebObjects에서 뷰는 메뉴나 버튼과 같은 완전한 사용자 인터페이스 요소를 나타내며 사용자 입력을 받는다.[20] 그러나 Smalltalk-80과 WebObjects 모두에서 뷰는 범용적이고 조합성을 갖도록 설계되었다.[21][22]
Rails와 Django에서 뷰의 역할은 HTML 템플릿이 수행하므로, 이들의 구조에서 뷰는 사용자 인터페이스 위젯을 직접 나타내기보다는 브라우저 내의 사용자 인터페이스를 지정한다.[23][24] (Django는 이를 고려하여 이 종류의 객체를 "템플릿"이라고 부르기로 했다.[25]) 이러한 접근 방식은 작고 조합 가능한 뷰에 상대적으로 덜 중점을 둔다. 전형적인 Rails 뷰는 컨트롤러 액션과 일대일 관계를 갖는다.[26]
Smalltalk-80 뷰는 모델 및 컨트롤러와 모두 통신하는 반면,[27] WebObjects에서는 뷰가 컨트롤러와만 통신하고, 컨트롤러가 모델과 통신한다.[28] Rails와 Django에서 뷰/템플릿은 클라이언트에 대한 응답을 준비할 때 컨트롤러/뷰에 의해 사용된다.[29][30]
MVC에서 뷰는 모델의 데이터를 가져와 사용자가 보기에 적합한 형태로 표시하는 요소이다. 즉, UI에 출력을 담당한다. 예를 들어, 웹 애플리케이션에서는 HTML 문서를 생성하여 동적으로 데이터를 표시하기 위한 코드 등에 해당한다. GUI에서는 일반적으로 계층 구조를 이룬다.[49]
3. 3. 컨트롤러 (Controller)
컨트롤러는 모델에 명령을 내려 모델의 상태를 변경하거나(예: 워드 프로세서에서 문서 편집), 관련된 뷰에 명령을 내려 모델의 표시 방법을 바꿀 수 있다.(예: 문서 스크롤)[51]사용자 입력을 받아 모델 또는 뷰에 대한 명령으로 변환한다.[31]
Smalltalk-80 컨트롤러는 버튼 누름 또는 마우스 움직임 같은 사용자 입력 이벤트를 처리한다.[32] 각 컨트롤러는 특정 시점에 하나의 연결된 뷰와 모델을 가지지만, 하나의 모델 객체는 여러 다른 컨트롤러로부터 신호를 받을 수 있다. 언제든지 하나의 컨트롤러, 즉 "활성" 컨트롤러만 사용자 입력을 받는다. 전역 윈도우 관리자 객체가 현재 활성 컨트롤러를 설정하는 역할을 한다. 사용자 입력이 모델 변경을 유발하면, 컨트롤러는 모델에 변경을 알리지만, 뷰를 업데이트하도록 지시하는 것은 모델의 책임이다.[33]
WebObjects에서 뷰는 사용자 입력을 처리하고, 컨트롤러는 뷰와 모델 사이를 중재한다. 애플리케이션당 하나의 컨트롤러 또는 창당 하나의 컨트롤러가 있을 수 있다. 애플리케이션별 로직의 상당 부분은 컨트롤러에서 찾을 수 있다.[34]
Rails에서 클라이언트로부터 서버 측 애플리케이션에 도착하는 요청은 특정 컨트롤러의 특정 메서드에 요청을 매핑하는 라우터로 전송된다. 해당 메서드 내에서 컨트롤러는 요청 데이터 및 관련 모델 객체와 상호 작용하고 뷰를 사용하여 응답을 준비한다. 일반적으로 각 뷰에는 연결된 컨트롤러가 있다. 예를 들어, 애플리케이션에 `client` 뷰가 있으면, 보통 `Clients` 컨트롤러도 연결된다. 그러나 개발자는 원하는 경우 다른 종류의 컨트롤러를 자유롭게 만들 수 있다.[35]
Django는 이 역할을 하는 객체를 컨트롤러 대신 "뷰"라고 부른다.[30] Django 뷰는 웹 요청을 받아 웹 응답을 반환하는 함수이다. 템플릿을 사용하여 응답을 생성할 수 있다.[36]
컨트롤러는 사용자로부터의 입력(이벤트로 통지됨)을 모델에 대한 메시지로 변환하여 모델에 전달한다. 즉, UI로부터의 입력을 담당한다. 모델에 변경을 일으키기도 하지만, 직접 그리기를 하거나 모델의 내부 데이터를 직접 조작하지는 않는다.
4. 상호작용
모델-뷰-컨트롤러(MVC)는 응용 프로그램을 세 가지 구성 요소로 나누며, 이들 사이의 상호작용은 다음과 같다.[51]
- 컨트롤러: 모델에 명령을 보내 모델의 상태를 변경하거나(예: 문서 편집), 뷰에 명령을 보내 모델의 표시 방법을 변경한다(예: 문서 스크롤).[51]
- 모델: 상태 변화를 컨트롤러와 뷰에 통보하여 뷰가 최신 결과를 표시하고, 컨트롤러가 명령을 조정하도록 한다. 일부 MVC 구현에서는 뷰나 컨트롤러가 직접 모델 상태를 읽기도 한다.[51]
- 뷰: 모델에서 정보를 가져와 사용자에게 보여줄 결과물을 생성한다.[51]
MVC에서 뷰는 여러 컨트롤러를 가질 수 있다. 사용자는 컨트롤러를 통해 모델의 상태를 변경하며, 모델은 변경 시 등록된 뷰에 알리고 뷰는 사용자에게 모델 상태를 보여준다.
자바에서 모델은 `java.util.Observable`을 상속받아 만들 수 있다. 모델은 상태 변경 함수(`mutator`)에서 `setChanged()`와 `notifyObservers()`를 호출하여 뷰에 업데이트 메시지를 보낸다. 뷰는 `java.util.Observer`를 구현하여 `update` 메서드를 통해 모델의 추가 정보를 받는다.
```java
interface Observer
{ void update(Observable t, Object o);
}
```
뷰는 모델에 질의하여 업데이트하는 부분을 구현해야 한다. 모델은 `addObserver` 함수로 뷰를 등록하고, 상태 변경 시 등록된 모든 뷰에 `notify` 함수를 호출하여 뷰를 업데이트한다. MVC는 여러 뷰와 모델 간의 다중 등록을 허용한다.
MVC 설계 패턴은 애플리케이션을 모델, 뷰, 컨트롤러로 나누고 상호 작용을 정의한다:[37]
- 모델은 데이터 관리 및 컨트롤러의 사용자 입력 수신.
- 뷰는 모델을 특정 형식으로 표현.
- 컨트롤러는 사용자 입력에 응답하고 모델 객체와 상호 작용. 입력 유효성 검사 후 모델에 전달.
MVC 설계는 전통적인 설명과 다를 수 있다.[38][39] 일반적인 제어 흐름은 다음과 같다.
1. 컨트롤러가 입력 장치(마우스, 키보드 등)를 감시한다.
2. 사용자 입력이 발생한다.
3. 컨트롤러가 사용자 액션에 따라 모델 메서드를 호출한다(모델 데이터가 수정될 수 있다).
4. 모델이 변경된 경우, 뷰 등 옵저버에게 통지한다.
5. 뷰는 모델에서 데이터를 취득 후 출력을 갱신한다(화면에 도형 그리기 등).
뷰와 컨트롤러는 실제로는 계층 구조를 이루며, 각 뷰마다 대응하는 컨트롤러가 존재한다. 사용자 입력 처리 컨트롤러 결정 단계는 다음과 같다(Smalltalk-80 기준).
1. 컨트롤러는 뷰에 입력 처리 컨트롤러를 문의한다.
2. 뷰는 컨트롤러에 마우스 커서 위치를 문의한다.
3. 뷰는 마우스 커서를 포함하는 뷰를 검색한다.
4. 해당 뷰의 컨트롤러를 입력 처리 컨트롤러로 지정한다.
5. 웹 애플리케이션에서의 사용
MVC는 원래 데스크톱 컴퓨터를 위한 설계로 개발되었지만, 주요 프로그래밍 언어에서 월드 와이드 웹 응용 프로그램을 위한 설계로 널리 채택되었다. 이 패턴을 적용하는 여러 개의 웹 프레임워크가 만들어졌다. 이러한 소프트웨어 프레임워크는 MVC의 책임을 클라이언트-서버 모델의 클라이언트와 서버 사이에서 분담하는 방식에 따라 해석이 다르다.[42] 초기의 MVC 프레임워크는 거의 모든 모델, 뷰 및 컨트롤러 로직을 서버에 두는 씬 클라이언트 접근 방식을 채택했다. 이 방식에서 클라이언트는 컨트롤러에 하이퍼링크 요청 또는 폼 (웹) 제출을 보내고 뷰에서 완성되고 업데이트된 웹 페이지 (또는 다른 문서)를 받는다. 모델은 완전히 서버에 존재한다.[42] 이후의 프레임워크는 Ajax (프로그래밍)를 사용하여 데이터를 동기화하면서 MVC 구성 요소가 부분적으로 클라이언트에서 실행되도록 허용했다.
2002년 11월 W3C는 미래의 웹 애플리케이션에 사용될 X폼즈(XForms) 아키텍처에 MVC 구조가 포함되도록 투표하여 가결하였다.[54] 이 규격은 XHTML 2.0 규격에 바로 통합될 것이다. 현재 20개가 넘는 업체가 애플리케이션 스택에 MVC가 통합된 X폼즈 프레임워크를 지원하고 있다.
6. 파생 패턴
MVC는 여러 파생 패턴을 가지고 있다. 그 중 마이크로소프트가 사용했기 때문에 가장 널리 알려진 것은 1990년대 초기부터 등장하기 시작한 모델 뷰 프리젠터 패턴이다.[52] 이 패턴은 MVC의 진화된 모습을 목표로 설계되었다. 그러나 모델-뷰-컨트롤러는 여전히 매우 널리 사용되고 있다.
2002년 11월 W3C는 미래의 웹 애플리케이션에 사용될 X폼즈(XForms) 아키텍처에 MVC 구조가 포함되도록 투표하여 가결하였다.[54] 이 규격은 XHTML 2.0 규격에 바로 통합될 것이다. 현재 20개가 넘는 업체가 애플리케이션 스택에 MVC가 통합된 X폼즈 프레임워크를 지원하고 있다.
7. 장점 및 단점
MVC는 디자인 패턴의 일종으로 취급되기도 하지만, 옵저버 패턴, 커맨드 패턴, 팩토리 메서드 패턴, 퍼사드 패턴 등 다른 작은 디자인 패턴을 이용하여 구현되는 경우가 많아 디자인 패턴보다는 더 큰 단위인 일종의 소프트웨어 아키텍처라고 하는 편이 적절하다.[49][50]
각 모듈이 비교적 명확하게 나뉘어 프로그램의 가독성이 좋아지고, 사용자 인터페이스(UI) 부분을 다른 모듈로 교체하는 것이 용이하며, 자동 프로그래밍 등에도 적합하다.
7. 1. 장점
MVC는 디자인 패턴의 일종으로 취급되는 경우도 있지만, MVC 자체가 옵저버 패턴, 커맨드 패턴, 팩토리 메서드 패턴, 퍼사드 패턴 등 다른 작은 디자인 패턴을 이용하여 구현되는 경우가 많다는 점에서 디자인 패턴이라기보다는, 더 큰 단위의 일종의 소프트웨어 아키텍처라고 하는 편이 적절할 것이다.[49][50]각 모듈이 비교적 명확하게 나뉘어 프로그램의 가독성이 좋아지고, 사용자 인터페이스 (UI) 부분을 다른 모듈로 교체하는 것이 용이하다는 장점이 있다. 자동 프로그래밍 등에도 적합하다.
7. 2. 단점
모델, 뷰, 컨트롤러로 명확하게 역할이 분리되어 프로그램의 가독성이 좋아지고, 사용자 인터페이스(UI) 부분을 다른 모듈로 교체하기 쉽다는 장점이 있지만, MVC 자체가 여러 디자인 패턴(옵저버 패턴, 커맨드 패턴, 팩토리 메서드 패턴, 퍼사드 패턴 등)을 이용해 구현되기 때문에 디자인 패턴보다는 일종의 소프트웨어 아키텍처로 보는 것이 더 적절하다.[49][50]참조
[1]
웹사이트
The Principles of Clean Architecture by Uncle Bob Martin
https://www.youtube.[...]
2015-12-15
[2]
웹사이트
The DCI Architecture: A New Vision of Object-Oriented Programming
https://www.artima.c[...]
2009-03-20
[3]
문서
""
[4]
뉴스
What Are The Benefits of MVC?
http://blog.iandavis[...]
2016-11-29
[5]
웹사이트
Model–View–Controller History
http://c2.com/cgi/wi[...]
2013-12-09
[6]
웹사이트
Notes and Historical documents
http://heim.ifi.uio.[...]
[7]
문서
A note on DynaBook requirements
https://wayback.arch[...]
1979-03-22
[8]
서적
Patterns of Enterprise Application Architecture
Pearson Education, Inc.
2003
[9]
서적
Smalltalk-80: The Interactive Programming Environment
Addison-Wesley
1984
[10]
간행물
A cookbook for using the model–view controller user interface paradigm in Smalltalk-80
http://dl.acm.org/ci[...]
SIGS Publications
1988-08-09
[11]
웹사이트
The evolution of MVC and other UI architectures
http://martinfowler.[...]
[12]
웹사이트
Ruby on Rails Guides
https://guides.rubyo[...]
2022-03-19
[13]
웹사이트
Django FAQ: Django appears to be a MVC framework, but you call the Controller the "view", and the View the "template". How come you don't use the standard names?
https://docs.djangop[...]
2022-03-19
[14]
웹사이트
Applications Programming in Smalltalk-80:How to use Model–View–Controller (MVC)
https://web.archive.[...]
1992
[15]
서적
Inside Smalltalk
https://books.google[...]
Prentice-Hall Inc.
1991
[16]
서적
WebObjects System Overview
https://developer.ap[...]
Apple Computer, Inc.
2001-05
[17]
웹사이트
Active Record Basics
https://guides.rubyo[...]
2022-10-27
[18]
웹사이트
Models
https://docs.djangop[...]
2022-10-27
[19]
서적
Inside Smalltalk
https://books.google[...]
Prentice-Hall Inc.
1991
[20]
서적
WebObjects System Overview
https://developer.ap[...]
Apple Computer, Inc.
2001-05
[21]
서적
Inside Smalltalk
https://books.google[...]
Prentice-Hall Inc.
1991
[22]
서적
WebObjects System Overview
https://developer.ap[...]
Apple Computer, Inc.
2001-05
[23]
웹사이트
Action View Overview
https://guides.rubyo[...]
2022-10-27
[24]
웹사이트
Templates
https://docs.djangop[...]
2022-10-27
[25]
웹사이트
Django FAQ: Django appears to be a MVC framework, but you call the Controller the "view", and the View the "template". How come you don't use the standard names?
https://docs.djangop[...]
2022-10-27
[26]
웹사이트
Action View Overview
https://guides.rubyo[...]
2022-10-27
[27]
서적
Inside Smalltalk
https://books.google[...]
Prentice-Hall Inc.
1991
[28]
서적
WebObjects System Overview
https://developer.ap[...]
Apple Computer, Inc.
2001-05
[29]
웹사이트
Action View Overview
https://guides.rubyo[...]
2022-10-27
[30]
웹사이트
Django FAQ: Django appears to be a MVC framework, but you call the Controller the "view", and the View the "template". How come you don't use the standard names?
https://docs.djangop[...]
2022-10-27
[31]
웹사이트
Simple Example of MVC (Model–View–Controller) Architectural Pattern for Abstraction
http://www.codeproje[...]
[32]
서적
Inside Smalltalk
https://books.google[...]
Prentice-Hall Inc.
1991
[33]
서적
Inside Smalltalk
https://books.google[...]
Prentice-Hall Inc.
1991
[34]
서적
WebObjects System Overview
https://developer.ap[...]
Apple Computer, Inc.
2001-05
[35]
웹사이트
Action View Overview
https://guides.rubyo[...]
2022-10-27
[36]
웹사이트
Writing views
https://docs.djangop[...]
2022-10-27
[37]
서적
Pattern-Oriented Software Architecture
1996
[38]
서적
Design Patterns
1994
[39]
서적
Professional Rich Internet Applications: Ajax and Beyond
2007
[40]
웹사이트
is squeak really object oriented ?
http://lists.squeakf[...]
2003-05-23
[41]
서적
Inside Smalltalk
https://books.google[...]
Prentice-Hall Inc.
1991
[42]
학회발표
Web-Application Development Using the Model/View/Controller Design Pattern
2001-09
[43]
웹사이트
MVC XEROX PARC 1978-79
http://heim.ifi.uio.[...]
[44]
웹사이트
The Model-View-Controller (MVC) Its Past and Present
http://heim.ifi.uio.[...]
[45]
웹사이트
A Cookbook for Using the Model-View-Controller User Interface Paradigm in Smalltalk -80
http://www.ics.uci.e[...]
[46]
웹사이트
Model View Controller History
http://c2.com/cgi/wi[...]
[47]
서적
Design Patterns: Elements of Reusable Object-Oriented Software
Addison-Wesley
1994
[48]
웹사이트
Understanding JavaServer Pages Model 2 architecture
http://www.javaworld[...]
[49]
서적
Pattern-Oriented Software Architecture
John Wiley and Sons
1996
[50]
웹사이트
Model View Controller As An Aggregate Design Pattern
http://c2.com/cgi/wi[...]
[51]
서적
Pattern-Oriented Software Architecture
1996
[52]
웹사이트
Trygve M. H. Reenskaug/MVC
http://heim.ifi.uio.[...]
1978-1979
[53]
웹인용
Applications Programming in Smalltalk-80: How to use Model–View–Controller
http://st-www.cs.uiu[...]
2011-06-12
[54]
웹사이트
Forms 1.0 Basic Profile
http://www.w3.org/TR[...]
본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.
문의하기 : help@durumis.com