MVC 패턴

개요

---

Model-View-Controller (일반적으로 MVC 라고 함) 는 사용자 인터페이스를 개발하는데 널리 사용하는 소프트웨어 디자인 패턴이며 관련 프로그램 논리를 세 개의 상호 연결된 요소로 나눕니다.

__이것은 정보의 내부 표현과 정보가 사용자에게 제공되고 수용되는 방식을 분리하기 위해 수행합니다.

__이러한 패턴은 페이지의 레이아웃을 디자인 하는 데 사용합니다.

 

전통적으로 데스크탑 그래픽 사용자 인터페이스에 사용하는 이 패턴은 웹 애플리케이션 설계에 널리 사용되었습니다.

__JavaScript, Python, Ruby, PHP, Java, C# 및 Swift 와 같은 널리 사용되는 프로그래밍 언어에는 즉시 웹 또는 모바일 애플리케이션 개발에 사용하는 MVC 프레임워크가 있습니다.

구성 요소

---

Model (모델)

패턴의 중심 구성 요소입니다.

__사용자 인터페이스와는 독립적인 애플리케이션의 동적 데이터 구조입니다.

__애플리케이션의 데이터, 논리 및 규칙을 직접 관리합니다.

View (뷰)

차트, 다이어그램 또는 표와 같은 정보를 표현합니다.

__관리용 막대 차트 및 회계 사용 테이블 형식 보기와 같이 동일한 정보에 대한 여러 뷰가 가능합니다.

Controller (컨트롤러)

입력을 받아 모델 또는 뷰에 대한 명령으로 변환합니다.

 

애플리케이션을 이러한 구성 요소로 나누는 것 외에도 모델-뷰-컨트롤러 설계는 이들 간의 상호 작용을 정의합니다.

 

모델은 애플리케이션의 데이터를 관리합니다.

__컨트롤러로부터 사용자 입력을 받습니다.

 

뷰는 특정 형식으로 모델을 표시하는 것을 의미합니다.

 

컨트롤러는 사용자 입력에 응답하고 데이터 모델 개체에 대한 상호 작용을 수행합니다.

__컨트롤러는 입력을 수신하고 선택적으로 유효성을 검사 한 다음 입력을 모델에 전달합니다.

 

다른 소프트웨어 패턴과 마찬가지로, MVC 는 문제에 대한 "주요 해결책" 을 표현하면서 각 시스템에 적용할 수 있습니다.

__특정 MVC 설계는 여기에 있는 기존 설명과 크게 다를 수 있습니다.

Service (서비스)

컨트롤러와 모델 사이에는 때때로 서비스 라는 계층을 추가합니다.

__서비스는 모델에서 데이터를 가져오고 컨트롤러가 그 데이터를 사용할 수 있도록 합니다.

__이 계층을 통해 데이터 저장소 (모델), 데이터 가져 오기 (서비스) 그리고 데이터 조작 (컨트롤러) 을 더 명확하게 분리 할 수 있습니다.

__이 계층은 원래 MVC 개념의 일부가 아니기 때문에 선택 사항이지만, 경우에 따라 코드 관리 및 재사용 목적에 유용 할 수 있습니다.

역사

---

그래픽 사용자 인터페이스의 초기 개발에서 중요한 통찰 중 하나인, MVC 는 책임 측면에서 소프트웨어 구성을 설명하고 구현하는 첫 번째 접근 방식 중 하나가 되었습니다.

 

Trygve Reenskaug 는 1970 년대 Xerox Palo Alto 연구 센터를 방문하는 동안 Smalltalk-79 에 MVC 를 도입했습니다.

__1980 년대에 Jim Althoff 와 다른 사람들은 Smalltalk-80 클래스 라이브러리 용 MVC 버전을 구현했습니다.

__나중에 1988 년 글인 "The Journel of Object Technology (JOT)" 에서 MVC 를 일반적인 개념으로 표현했습니다.

__MVC 패턴은 진화하고 발전하여 계층적 모델-뷰-컨트롤러 (HMVC), 모델-뷰-어댑터 (MVA), 모델-뷰-프레젠터 (MVP), 모델-뷰-뷰 모델 (MVVM) 등과 같은 많은 변형이 생겨났습니다.

 

1996 년 NeXT 의 WebObjects 가 도입된 이후 웹 애플리케이션에서 MVC 패턴의 사용이 폭발적으로 증가했습니다.

__이것은 원래 Objective-C (Smalltalk 에서 많이 따옴) 로 작성했으며 MVC 원칙을 적용하는 데 도움을 주었습니다.

__나중에 WebObjects 가 Java (자바) 로 포팅 되었을 때 MVC 패턴은 Java 개발자에게 인기를 얻었습니다.

__Spring (스프링, 2002 년 10 월에 출시) 과 같은 자바 용 프레임워크는 자바와 MVC 간의 강력한 유대를 계속 유지 했습니다.

__Django (장고, 2005년 7월, Python 용) 와 Rails (레일스, 2005년 12월, Ruby 용) 프레임워크의 도입은 둘 다 신속한 배포에 중점을 두었으며, MVC 가 오랫동안 인기를 끌었던 전통적인 기업 환경 밖에서 MVC 의 인기를 높였습니다.

__MVC 웹 프레임워크는 이제 비-MVC 웹 툴킷에 비해 큰 시장 점유율을 차지하고 있습니다.

웹 애플리케이션에서 사용

---

원래 데스크탑 컴퓨팅 용으로 개발했지만, MVC 는 주요 프로그래밍 언어에서 World Wide Web 애플리케이션을 설계하는 데 널리 사용했습니다.

__몇 가지 웹 프레임워크는 이 패턴을 따랐습니다.

__이러한 소프트웨어 프레임워크는 다양한 해석이 가능하며 주로 MVC 의 책임이 클라이언트와 서버 간에 나뉘는 방식입니다.

 

일부 웹 MVC 프레임워크는 거의 전체 모델, 뷰 그리고 컨트롤러 논리를 서버에 배치하는 가벼운 클라이언트 방식을 사용합니다.

__이는 장고, 레일스 및 ASP.NET MVC 와 같은 프레임워크에서 보여집니다.

__이 방식에서 클라이언트는 하이퍼링크 요청 또는 양식 제출을 컨트롤러에 보낸 다음 뷰에서 완전하고 최신의 웹 페이지 (또는 기타 문서) 를 수신합니다.

__모델은 전적으로 서버에 존재합니다.

__AngularJS, EmberJS, JavaScriptMVC 그리고 Backbone 등과 같은 다른 프레임워크를 사용하면 MVC 구성 요소를 클라이언트에서 부분적으로 실행할 수 있습니다. (Ajax 참조)

MVC 의 목표

---

동시 개발

MVC 는 애플리케이션의 다양한 구성 요소를 분리하기 때문에, 개발자는 서로 영향을 주거나 차단하지 않고 서로 다른 구성 요소에서 병렬로 작업할 수 있습니다.

__예를 들어, 팀은 개발자를 front-end (프런트-엔드) 와 back-end (백-엔드) 로 나눌 수 있습니다.

__백-엔드 개발자는 사용자 인터페이스를 만들지 않고도 데이터 구조와 사용자가 데이터와 상호 작용하는 방식을 설계 할 수 있습니다.

__반대로, 프런트-엔드 개발자는 데이터 구조를 만들기 전에 애플리케이션의 레이아웃을 설계하고 테스트 할 수 있습니다.

코드 재사용

뷰는 단순히 데이터가 사용자에게 보여지는 방식을 처리하기 때문에, 하나의 애플리케이션에 대한 뷰를 다른 데이터가 있는 다른 애플리케이션에 대해 재사용 할 수 있습니다.

__불행히도 해당 코드가 사용자 입력을 처리하는 데 유용할 때는 해당되지 않습니다.

__예를 들어, DOM 코드 (애플리케이션의 커스텀 추상화 포함) 는 그래픽 표시와 사용자 입력 모두에 유용합니다.

__이름은 Document Object Model (문서 객체 모델) 이지만, DOM 은 사실 MVC 모델이 아닙니다.

__DOM 은 애플리케이션의 인터페이스 입니다.

 

이러한 문제를 해결하기 위해, MVC 는 종종 UI 요소 집합을 제공하는 구성 요소 아키텍처와 결합합니다.

__각 UI 요소는 하나의 상위-수준 구성 요소이며 3개의 필수 MVC 구성 요소를 단일 패키지로 결합합니다.

__이러한 상위-수준 구성 요소를 독립적으로 만드므로, 개발자는 다른 애플리케이션에서 구성 요소를 빠르고 쉽게 재사용 할 수 있습니다.

장점과 단점

---

장점

동시 개발

__여러 개발자가 모델, 컨트롤러 및 뷰를 동시에 작업 할 수 있습니다.

 

높은 응집력

__MVC 를 사용하면 컨트롤러에서 관련된 작업을 논리적으로 그룹화 할 수 있습니다.

특정 모델의 뷰도 함께 그룹화 합니다.

 

느슨한 결합

__MVC 프레임워크의 특성은 모델, 뷰 또는 컨트롤러 간에 결합이 낮다는 것입니다.

 

수정 용이성

__책임 분리로 인해, 향후 개발 또는 수정이 쉽습니다.

 

모델에 대한 여러 뷰

__모델에 여러 뷰가 있을 수 있습니다.

 

테스트 가능성

__관심사를 더 명확하게 분리하면, 개별 부분을 독립적으로 테스트 할 수 있습니다.

__(예 : 뷰를 건드리지 않고도 모델을 개선)

단점

MVC 의 단점은 일반적으로 잘못 적용한 소프트웨어의 간접 비용입니다.

코드 탐색 가능성

__새로운 간접 계층을 도입하고 사용자가 MVC 의 분해 기준에 적응해야 하기 때문에 프레임워크 탐색이 복잡 할 수 있습니다.

 

다중-아티팩트 일관성

__기능을 3개의 아티팩트로 분해하면 산란을 일으킵니다.

__따라서 개발자는 한 번에 여러 표현의 일관성을 유지해야 합니다.

 

불가피한 집중으로 인한 명예 훼손

__애플리케이션은 사용자가 보는 것과 사용자가 사용하는 것 사이에 많은 상호 작용을 하는 경향이 있습니다.

__따라서 각 기능의 계산 및 상태는 3가지 프로그램 파트 중 하나로 집중되는 경향이 있어 MVC 의 장점이 사라집니다.

 

과도한 상용구

__애플리케이션 계산 및 상태가 일반적으로 3개 파트 중 하나로 집중되기 때문에 다른 부분은 MVC 패턴을 만족하기 위해서만 존재하는 상용구나 코드-숨김으로 퇴화합니다.

 

명백한 학습 곡선

__여러 기술에 대한 지식이 필요합니다.

__MVC 를 사용하는 개발자는 여러 기술에 능숙해야 합니다.

 

점진적 혜택 부족

__UI 애플리케이션은 이미 구성 요소에 포함되어 있으며 구성 요소 아키텍처를 통해 코드 재사용 및 독립성을 달성하므로 MVC 에 점진적인 혜택이 없습니다.