실제로 MVC 란 무엇입니까?


202

심각한 프로그래머로서 MVC 란 무엇입니까?

내 생각에 MVC는 일종의 끔찍한 주제입니다. 따라서 청중이 학습자라면 논란의 여지가없는 일반적인 용어로 자유롭게 설명 할 수 있습니다.

그러나 당신이 지식이 풍부한 청중, 특히 면접관에게 말하고 있다면, 나는 "잘 옳지 않다!" 우리는 모두 실제 경험이 다르며 동일한 MVC 구현 패턴을 두 번 충족시키지 못했습니다.

구체적으로, 엄격 성, 구성 요소 정의, 부품 분리 (어떤 부분에 적합한 지) 등에 대한 의견 불일치가있는 것으로 보입니다.

그렇다면 MVC 를 정확하고 간결하며 논쟁의 여지가없는 방식으로 어떻게 설명해야 합니까?


4
참고 : ASP.NET에서 작업하는 경우 MVC는 다음과 같은 의미가 아닙니다. ASP.NET MVC
Brian

MVC 잘 여기에서 설명 된 codespeaker.com/blogs/...
smzapp

답변:


156

MVC는 도메인 / 애플리케이션 / 비즈니스 (원하는대로) 로직을 나머지 사용자 인터페이스와 분리하는 소프트웨어 아키텍처 (시스템 구조)입니다. 응용 프로그램을 모델, 뷰 및 컨트롤러의 세 부분으로 분리하여이를 수행합니다.

이 모델은 응용 프로그램의 기본 동작 및 데이터를 관리합니다. 정보 요청에 응답하고 정보 상태를 변경하기위한 지시에 응답 할 수 있으며 정보가 변경 될 때 이벤트 중심 시스템의 관찰자에게 통지 할 수도 있습니다. 데이터베이스이거나 여러 데이터 구조 또는 스토리지 시스템 일 수 있습니다. 간단히 말해서 응용 프로그램의 데이터 및 데이터 관리입니다.

뷰는 효과적으로 애플리케이션의 사용자 인터페이스 요소를 제공합니다. 모델의 데이터를 사용자 인터페이스에 적합한 형식으로 렌더링합니다.

제어기는 사용자 입력을 수신하고 모델 오브젝트 및보기를 호출하여 적절한 조치를 수행합니다.

대체로이 세 가지 구성 요소가 함께 작동하여 MVC의 세 가지 기본 구성 요소를 만듭니다.


7
+1 MVC를 디자인 패턴보다 3 개 이상의 패턴의 아키텍처로 생각하는 것이 좋습니다. 정식 구현은 없으며 그다지 작지 않으며 모든 구현에는 암시 적 핵심 구성 요소보다 훨씬 더 많은 기능이 있습니다.
yannis

51
이 답변에는 21 개의 공감대가 있지만 "이것은 데이터베이스이거나 여러 데이터 구조 또는 스토리지 시스템 일 수 있습니다. (tl; dr : 응용 프로그램의 데이터 및 데이터 관리입니다.") 모델은 순수한 비즈니스 / 도메인 로직입니다. 그리고 이것은 응용 프로그램의 데이터 관리 그 이상일 수 있습니다. 또한 도메인 논리와 응용 프로그램 논리를 구분합니다. 컨트롤러는 비즈니스 / 도메인 로직을 포함하거나 데이터베이스와 직접 대화해서는 안됩니다.
팔콘

9
mvc가 프레젠테이션 레이어 외부에서 합리적이라고 주장하기 때문에이 답변에 더 이상 동의하지 않습니다. 나머지 답변은 괜찮습니다. MVC는 프레젠테이션 계층에서 시작하고 끝나야하며 비즈니스 로직과 리포지토리가 없어야합니다. 이렇게하면 전체 응용 프로그램을 프레젠테이션 계층에 효과적으로 배치 할 수 있으며 원래 응용 프로그램 용으로 설계되지 않은 비즈니스 논리 또는 순수한 데이터에 직접 액세스 할 수있는 사용 가능한 API가 없습니다. 이것은 확장 성을 위해 열려 있지 않습니다. 뷰 모델이 더 가까워 지지만 여전히 느슨한 커플 링이 누락되었습니다.
Jimmy Hoffa

6
@Jimmy : MVC의 많은 구조에서 모델은 UI에 의존하지 않기 때문에 API에서 재사용 할 수 있습니다. 뷰와 모델의 분리가이를 처리합니다. 그러나 그것은 물론 '모델'을 정의하는 방법에 달려 있습니다. 당신이 MVC에 대한 판단을하려는 경우, 먼저 설명해야 하는 당신이 사용하는 MVC의 해석.
Owen S.

5
@Yannis : 이것은 단지 질문을 제기합니다 : 패턴의 구조는 무엇입니까? 왜 다른 디자인 패턴이라고 부르지 않습니까? GoF (및 Alexander)에서 디자인 패턴의 정의는 패턴이 하나의 표준 구현을 규정하지 않아야한다는 것을 분명히합니다 (두 책의 인기는 약간의 개념을 과소 평가하지만).
Owen S.

136

유추

나는 아빠에게 MVC를 다음과 같이 설명했다.

MVC (Model, View, Controller)는 유지 관리 성을 향상시키기 위해 응용 프로그램에서 코드를 구성하는 패턴입니다.

스튜디오에서 자신의 카메라로 사진 작가를 상상해보십시오. 고객이 상자 사진을 찍도록 요청합니다.

상자는 모델 이고 사진 작가는 컨트롤러 이며 카메라는 보기 입니다.

상자는 카메라 나 사진 작가를 모르기 때문에 완전히 독립적입니다. 이러한 분리를 통해 사진 작가는 상자 주위를 산책하고 원하는 각도로 카메라를 가리킬 수 있습니다.

비 MVC 아키텍처는 서로 밀접하게 통합되는 경향이 있습니다. 만약 박스, 컨트롤러 및 카메라가 동일한 물체라면 우리는 새로운 시야를 원할 때마다 박스 카메라를 분리하고 다시 만들어야합니다. 또한 사진을 찍는 것은 항상 셀카를 찍는 것과 같습니다. 항상 쉬운 것은 아닙니다.


상해

MVC를 이해 한 것 같은 느낌의 다음 메일리스트 질문 / 답변을 읽은 후에야 비로소 견적 : https://mail.python.org/pipermail/python-list/2006-January/394968.html

bwaha는 다음과 같이 썼다.

저자는 MVC 디자인의 예로 wxPython에서 mvctree.py를 참조합니다. 그러나 나는 여전히 너무 녹색이므로 특정 예제가 너무 복잡하다는 것을 알았으며 저자가 권장하는 분리를 이해하지 못합니다.

MVC는 모든 관심사 분리에 관한 것입니다.

모델은 프로그램 데이터 (개인 및 클라이언트 데이터 모두)를 관리합니다. 뷰 / 컨트롤러는 외부 세계에 프로그램의 클라이언트 데이터와 상호 작용할 수있는 수단을 제공합니다.

모델은 프로그램의 다른 부분이 상호 작용할 수 있도록 내부 인터페이스 (API)를 제공합니다. View / Controller는 외부 인터페이스 (GUI / CLI / web form / high-level IPC / etc.)를 제공하여 프로그램 외부의 모든 것이 통신 할 수 있도록합니다.

모델은 프로그램 데이터의 무결성을 유지할 책임이 있습니다. 프로그램 데이터가 손상되면 모든 사람이 게임을 끝내기 때문입니다. 보기 / 컨트롤러는 UI의 무결성을 유지하고 모든 텍스트보기가 최신 값을 표시하고 현재 포커스에 적용되지 않는 메뉴 항목을 비활성화하는 등의 작업을 담당합니다.

모델에는 View / Controller 코드가 없습니다. GUI 위젯 클래스, 대화 상자 레이아웃 또는 사용자 입력 수신을위한 코드가 없습니다. 뷰 / 컨트롤러에는 모델 코드가 없습니다. URL을 검증하거나 SQL 쿼리를 수행하기위한 코드 및 원래 상태도 없음 : 위젯이 보유한 모든 데이터는 단지 표시 용이며 모델에 저장된 실제 데이터를 반영한 ​​것입니다.

이제 진정한 MVC 디자인을 테스트했습니다. View / Controller를 연결하지 않아도 프로그램은 본질적으로 완벽하게 작동해야합니다. 외부 세계는이 형식으로 상호 작용하는 데 어려움이 있지만 적절한 Model API incantation을 알고있는 한 프로그램은 정상적으로 데이터를 보유하고 조작합니다.

왜 이것이 가능합니까? 간단한 대답은 모델과 뷰 / 컨트롤러 레이어 사이의 낮은 커플 링 덕분입니다. 그러나 이것은 전체 이야기가 아닙니다. 무엇 전체 MVC 패턴의 핵심입니다 것은입니다 방향 ALL 지침 흐름 : 그 연결이 진행되는 에서 보기 / 컨트롤러 모델. 모델은 절대로 뷰 / 컨트롤러에게 수행 할 작업을 알려주지 않습니다.

왜? MVC에서는 뷰 / 컨트롤러가 모델 (특히 모델의 API)에 대해 조금 알 수 있지만 모델은 뷰 / 컨트롤러에 대해 아무것도 알 수 없습니다.

왜? MVC는 분명한 관심사 분리를 만들기위한 것입니다.

왜? 프로그램의 복잡성을 통제 불능으로 만들고 개발자를 파 묻지 않도록하기 위해. 프로그램이 클수록 해당 프로그램의 구성 요소 수가 많아집니다. 이러한 구성 요소 사이에 연결이 많을수록 개발자가 개별 구성 요소를 유지 관리 / 확장 / 교체하거나 전체 시스템 작동 방식을 따르는 것이 더 어렵습니다. 프로그램 구조의 다이어그램을 볼 때 나무 또는 고양이 요람을 원하십니까? MVC 패턴은 원형 연결을 금지하여 후자를 피합니다. B는 A에 연결할 수 있지만 A는 B에 연결할 수 없습니다.이 경우 A는 모델이고 B는보기 / 제어기입니다.

BTW, 예리한 경우 방금 설명한 '단방향'제한에 문제가 있음을 알 수 있습니다. 모델이 모델을 허용하지 않을 때 모델이 사용자 데이터의 변경 사항을 뷰 / 컨트롤러에게 알리는 방법 View / Controller가 메시지를 보내지 않아도된다는 것을 알고 있습니까? 그러나 걱정하지 마십시오. 이것에 대한 해결책이 있으며 처음에는 약간 우회 해 보이더라도 깔끔합니다. 우리는 잠시 후에 다시 돌아올 것입니다.

실용적인 관점에서, View / Controller 객체는 모델의 API를 통해 1. 모델에게 작업을 수행하도록 명령하고 (명령 실행) 2. 모델에 작업을 수행하도록 지시합니다 (데이터 반환). View / Controller 레이어 는 명령 을 모델 레이어로 푸시 하고 모델 레이어 에서 정보가져옵니다 .

그리고 첫 번째 MyCoolListControl의 예를 잘못 곳 클래스의 API 정보가 될 것을 요구하기 때문에 즉,의 밀어 그것으로, 그래서 당신은, 층 사이의 양방향 커플 링을 갖는 MVC 규칙을 위반하고에 바로 당신을 덤핑에 돌아온다 당신이 처음에 피하려고했던 고양이의 요람 구조.

대신 MyCoolListControl 클래스는 흐름과 함께 이동하여 필요할 때 아래 레이어에서 필요한 데이터를 가져옵니다. 목록 위젯의 경우 일반적으로 값이 몇 개인 지 묻는 다음 각 항목을 차례로 요청하는 것이 가장 간단하고 느슨한 방법이므로 커플 링이 최소가되도록 유지하기 때문입니다. 예를 들어, 위젯이 그 값을 알파벳 순서로 사용자에게 제시하기를 원한다면 그것은 그 설명입니다. 물론 그 책임.

앞서 언급했듯이 마지막으로 수수께끼가 있습니다 .MVC 기반 시스템에서 UI의 디스플레이를 모델의 상태와 동기화 상태를 유지하는 방법은 무엇입니까?

문제는 다음과 같습니다. 많은 View 개체가 상태 저장되어 있습니다. 예를 들어 확인란을 선택하거나 선택 취소하면 텍스트 필드에 편집 가능한 텍스트가 포함될 수 있습니다. 그러나 MVC는 모든 사용자 데이터가 모델 계층에 저장되도록 지시하므로 표시 목적 (확인란의 상태, 텍스트 필드의 현재 텍스트)을 위해 다른 계층이 보유한 모든 데이터는 해당 기본 모델 데이터의 보조 복사본이어야합니다. 그러나 모델의 상태가 변경되면 해당 상태의 뷰 사본이 더 이상 정확하지 않으므로 새로 고쳐야합니다.

그러나 어떻게? MVC 패턴은 모델이 해당 정보의 새로운 사본을보기 계층으로 푸시하지 못하게합니다. 심지어 모델이 View에게 상태가 변경되었다는 메시지를 보낼 수는 없습니다.

거의. 모델 레이어는 다른 레이어와 직접 대화 할 수 없습니다. 그렇게하려면 해당 레이어에 대해 알아야 할 것이기 때문에 MVC 규칙은이를 방지합니다. 그러나 나무가 숲에 떨어지고 아무도 들리지 않는다면 소리가 나는가?

답은 알림 시스템을 설정하여 모델 계층에 특히 흥미로운 일을 한 사람에게 알리지 않는 장소를 제공하는 것입니다. 그런 다음 다른 계층은 해당 알림 시스템과 함께 리스너를 게시하여 실제로 관심있는 공지 사항을들을 수 있습니다. 모델 계층은 누가 듣고 있는지에 대해 (또는 누군가 듣고있는 경우에도) 알 필요가 없습니다. 단지 공지 사항을 게시 한 다음 잊어 버립니다. 그리고 누군가가 그 발표를 듣고 나중에 새로운 데이터를 모델에 요청하여 화면 디스플레이를 업데이트 할 수있는 것처럼 무언가를하고 싶다고 느끼면 훌륭합니다. 모델은 API 정의의 일부로 전송하는 알림을 나열합니다. 그 지식으로 다른 사람이하는 일은 그들에게 달려 있습니다.

MVC는 보존되어 있으며 모두가 행복합니다. 응용 프로그램 프레임 워크는 기본 제공 알림 시스템을 제공하거나 그렇지 않은 경우 직접 작성할 수 있습니다 ( '관찰자 패턴'참조).

...

어쨌든, 그것이 도움이 되길 바랍니다. 일단 MVC의 동기를 이해하고 나면 일이 이해되기 시작하는 방식으로 일이 이해되는 이유는 언뜻보기에는 필요 이상으로 복잡해 보입니다.

건배,

있다



86

MVC는 주로 유행어입니다.

예전에는 패턴으로 여겨졌지만, 원래의 1979 년 정의는 어리 석고 넘어지고 잘못 해석되어 원래의 맥락에서 벗어났습니다. 그것은 종교를 닮기 시작하는 시점으로 잘못 재정의되었으며, 이것이화물 숭배자들이 그것을 지키는 데 확실히 도움이되지만, 그 이름은 더 이상 확실한 지침 세트와 관련이 없습니다 . 따라서 더 이상 패턴으로 간주 될 수 없습니다.

MVC는 웹 응용 프로그램을 설명하기위한 것이 아닙니다.
최신 운영 체제 나 언어도 없습니다.
(일부는 실제로 1979 정의를 중복으로 만들었습니다)

이루어졌다. 그리고 그것은 효과가 없었습니다.

이제 우리 는 끔찍한 유행어 상태, 나쁜 정의 및 반 일명 프로그래머 를 대상 인구 통계로 사용하는 것이 일반적으로 소프트웨어 패턴에 대한 나쁜 홍보를 하는 외설적 인 웹 -mvc 하이브리드 를 다루고 있습니다.

따라서 MVC 는 그것에 대해 너무 많이 생각하고 싶지 않은 사람들 에 대한 우려분리 되었습니다 .

  • 데이터 모델은 하나 개의 방식으로 처리된다
  • 보기 다른에서,
  • 나머지는 "컨트롤러" 라는 이름으로 독자의 재량에 맡겨져 있습니다.

90 년대의 웹 사이트 / 웹 응용 프로그램은 실제로 분리 문제를 적용하는 데 사용하지 않았습니다.

그들은 섞인 스파게티 코드의 끔찍한 멍청이였습니다.
UI 변경, 재 설계 및 데이터 재 배열은 엄청나게 힘들고, 비싸고, 길고, 우울하고, 불운했습니다.

ASP, JSP 및 PHP와 같은 웹 기술을 사용하면 뷰 문제를 데이터 및 응용 프로그램 문제와 혼합하기가 너무 쉽습니다 . 이 분야에 새로 온 사람들은 대개 옛날과 같이 불가분의 코드 머드 볼을 방출합니다.

따라서 점점 더 많은 사람들이 지원 포럼의 끝없는 루프에서 "use MVC" 를 반복하기 시작했습니다 . 사람들의 수는 관리자와 마케팅 담당자를 포함하여 점으로 확장되었으며 (일부 용어는 이미 gui 프로그래밍의 시대부터 패턴이 의미가 있음), 이제 우리가 직면해야 할 유행어가되었습니다. .

그것이 의미하는 것은 방법론이 아니라 상식 입니다. 그것은 해결책이 아니라 출발점 입니다. 그것은 사람들이 말하는처럼 숨을 쉴 공기를, 또는 철커덕하게 하지 암 치료법을 .


22
그것은 확실히 아니다 주로 화두. MVC가 다른 디자인 패턴보다 널리 보급되고 덜 두드러지는 경향이있는 것이 사실이므로,이를 조직 원칙 또는 패러다임으로 생각할 수 있습니다. 그러나 당신이 무엇을 부르든, 그것은 매우 성공적인 객체 지향 프레임 워크의 기본 개념입니다. 의미없는 단어 인 유행어 인 것처럼 가장하는 것은 OP에 장애를 일으키는 것입니다.
Caleb

23
It's a fancy word for pre-existing concepts that didn't really need one.그리고 어떤 디자인 패턴 / 아키텍처가 그 설명에 맞지 않습니까?
yannis

8
+1 기본 사항 (통합, 결합, 가독성, 직교성 등)을 파악하고 현대 언어의 기능과 결합하면 솔직히 대부분의 것들이 분명합니다.
lorean

12
The data model is handled one way, the view in another, the rest is just named "controller"+1
c69

33
-1. 나는 모든 바보 +1 의견에 대해 -10을 할 수 있기를 바랍니다. 결합과 응집의 기본 원리를 감안할 때이 "분명한"것은 어떻습니까? MVC, MVP, MVVM, Forms 및 Smalltalk 모델을 포함한 UI 아키텍처가 풍부합니다. 또한 일부 회사는 WS-CAF와 같이 복합 애플리케이션 아키텍처를 극도로 추진합니다. "상식"이라고하면 자동으로 MVC가 데카르트의 소위 신의 증거만큼의 물을 보유하게됩니다. 분명히 당신이 아는 것이지만, 당신의 대답은 다른 방법에 대한 무지 나 자신의 지평을 확장 할 수 없다는 것을 보여줍니다.
Aaronaught

39

그것을 정의하는 가장 좋은 방법은 그것을 발명 한 Trygve Reenskaug 의 원래 글로 이동하는 것입니다 : http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html

이 문서는 특히 다음과 같은 정의 텍스트로 간주됩니다. http://heim.ifi.uio.no/~trygver/1979/mvc-2/1979-12-MVC.pdf

모델

모델은 지식을 나타냅니다. 모델은 하나의 객체 (무관심)이거나 객체의 일부 구조 일 수 있습니다.

한편으로는 모델과 그 부분 사이에 일대일 대응 관계가 있어야하며 다른 한편으로는 모델 소유자가 인식 한 대표 세계가 있어야합니다. 따라서 모델의 노드는 문제의 식별 가능한 부분을 나타내야합니다.

모델의 노드는 모두 동일한 문제 수준에 있어야하며 문제 지향 노드 ​​(예 : 일정 약속)와 구현 세부 정보 (예 : 단락)를 혼합하는 것은 혼란스럽고 잘못된 형식으로 간주됩니다.

견해

뷰는 모델의 (시각적) 표현입니다. 일반적으로 모델의 특정 속성을 강조하고 다른 속성을 억제합니다. 따라서 프레 젠 테이션 필터 역할을합니다 .

뷰는 모델 (또는 모델 부분)에 첨부되며 질문을 통해 모델에서 프리젠 테이션에 필요한 데이터를 가져옵니다. 적절한 메시지를 보내서 모델을 업데이트 할 수도 있습니다. 이러한 모든 질문과 메시지는 모델의 용어에 있어야하므로 뷰는 모델이 나타내는 모델의 속성의 의미를 알아야합니다. (예를 들어, 모델의 식별자를 요구하고 Text의 인스턴스를 기대할 수 있습니다. 모델이 Text 클래스라고 가정하지 않을 수도 있습니다.)

컨트롤러

컨트롤러는 사용자와 시스템 간의 연결입니다. 화면의 적절한 위치에 관련보기를 표시하여 사용자에게 입력을 제공합니다. 사용자에게 메뉴 또는 명령 및 데이터를 제공하는 다른 수단을 제공하여 사용자 출력 수단을 제공합니다. 제어기는 그러한 사용자 출력을 수신하여이를 적절한 메시지로 변환하고이 메시지를 하나 이상의보기로 전달합니다.

컨트롤러는 뷰를 보완해서는 안되며, 예를 들어 노드 사이에 화살표를 그려서 노드 뷰를 연결해서는 안됩니다.

반대로, 뷰는 마우스 조작 및 키 입력과 같은 사용자 입력에 대해 절대 알 수 없습니다. 모든 사용자 명령 시퀀스를 정확하게 재현하는 메시지를 뷰로 보내는 컨트롤러에 항상 메소드를 작성할 수 있어야합니다.

편집자

컨트롤러는 모든 뷰에 연결되며 컨트롤러의 일부라고합니다. 일부 뷰는 사용자가 뷰에서 제공하는 정보를 수정할 수있는 특수 컨트롤러 인 editor를 제공합니다 . 이러한 편집기는 컨트롤러와 해당보기 사이의 경로에 연결될 수 있으며 컨트롤러의 확장으로 작동합니다. 편집 프로세스가 완료되면 편집기가 경로에서 제거되고 삭제됩니다.

편집기는 연결된보기의 은유를 통해 사용자와 통신하므로 편집기는보기와 밀접하게 연관되어 있습니다. 컨트롤러는보기를 요청하여 편집기를 보유하게됩니다. 다른 적절한 소스가 없습니다.


11

MVC는 비즈니스 로직을 프리젠 테이션에서 분리하는 데 사용되는 디자인 패턴입니다.

일반적으로 간결하게 구현되지는 않지만 프레임 워크의 기본이라는 점에서 다른 많은 디자인 패턴과 다릅니다.

전략 패턴을 구현하는 응용 프로그램은 그에 대한 작은 세부 사항이지만 웹 응용 프로그램이 MVC 디자인 패턴을 사용한다고 말하는 것은 아키텍처를 매우 정의하고 있습니다 .


2
MVC 패턴을 MVP, MP, MVVM과 다르게 만드는 MVC 패턴을 구현하기 위해서는 매우 구체적인 요구 사항이 있습니다. 또한 다른 프레젠테이션 패턴과는 다른 대상 독자가 있습니다.
Ian

8

MVC는 시스템 또는 서브 시스템의 다음 구성 요소를 분리하는 소프트웨어 설계입니다.

  1. 모델-응용 프로그램 또는 해당 구성 요소의 상태에 대한 데이터입니다. 수정 또는 액세스 루틴이 포함될 수 있습니다.
  2. 보기-데이터 (모델)의 해석입니다. 이는 시각적 표현으로 만 제한되지만 오디오, 파생 정보 (예 : 다른 모델 객체로 파이프 된 통계) 등일 수 있습니다. 또한 단일 모델에는 여러 개의 뷰가있을 수 있습니다.
  3. 제어-모델의 수정을 호출하는 시스템의 외부 입력을 처리합니다. 제어 /보기는 (UI의 경우) 밀접하게 관련 될 수 있습니다. 그러나보기와 완전히 독립적 인 다른 외부 입력 (예 : 네트워크 명령)이 처리 될 수 있습니다.

6

MVC는 개념이나 유사한 패턴의 패밀리라고 말할 것입니다.

이 기사를 읽을 가치가 있다고 생각합니다. Martin Fowler의 GUI 아키텍처


5
Fowler 기사는 훌륭하며 MVC라는 용어를 사용하는 모든 사람들이 읽어야합니다. 특히 흥미로운 점은 GUI에서 MVC라는 용어의 원래 사용은 웹 프레임 워크에서의 사용과 다소 다르며 GUI에서는 뷰와 컨트롤러의 분리가 예상보다 유용하지 않다는 것입니다.
Tom Anderson

3

먼저, 질문의 사람이 누구인지, 그리고 그가 어떤 대답을 찾고 있는지 결정해야합니다. "어떤 의미에서?"와 같은 다른 질문으로이 질문에 응답합니다.

그들이 MVC를 일반적으로 언급하고 있는지, MVC의 특정 구현 (예 : asp.net MVC, 스프링 MVC, 스몰 토크 MVC 등), 기술적으로 무엇이고, 철학적으로 무엇인지 (예, 가지고 있습니다) 철학 등) 등

이것이 시험에 관한 질문이고, 당신이 명확하게 해달라고 요청할 수 없다면, 문맥에 따라 추측해야 할 것입니다.

좋은 대답은 다음과 같습니다.

MVC는보다 유지 관리 가능한 소프트웨어를 용이하게하기 위해 구조적 및 행동 적 관심사를 분리하는 데 사용되는 소프트웨어 사용자 인터페이스 아키텍처입니다.

당신은 또한 말할 수 있습니다 :

모델과 컨트롤러의보기를 분리하여 책임에 따라 구성 요소를 분리 할 수 ​​있습니다. 이론적으로 그리고 실제로는 일반적으로 시스템의 다른 부분이 더 복잡한 시스템을 통합 및 생성하는 것을 방지하여 유지 관리 성을 향상시키는 데 도움이됩니다.

그러나 결국, 당신은 그들이 기대하는 답변을 줄 것인지에 대해 판단 될 것입니다. 이 문제에 대한 유일한 해결책은 그들이 어떤 종류의 대답을 기대하고 있는지 알아내는 것입니다.


2

여기 내가 그것에 대해 말할 것입니다. 가장 친숙하고 모바일 응용 프로그램을 시작하기 전에 완전히 이해하지 못한다고 생각하기 때문에 모바일 응용 프로그램 측면에서 설명하려고합니다.
예를 들어 안드로이드를 보자.
프리젠 테이션 레이어, 즉 사용자 인터페이스는 완전히 XML로 지정할 수 있습니다 (가장 자주 사용되어야 함). 간단히하기 위해 하나의 xml 파일이 응용 프로그램에서 하나의 화면을 설명한다고 가정합니다. XML 파일은 컨트롤, 컨트롤의 레이아웃, 위치, 색상, 크기, 문자열 레이블 등 프레젠테이션과 관련된 모든 것을 지정합니다. 그러나 언제 호출되는지, 언제 화면에 배치되는지에 대해서는 아무것도 모릅니다. 독립형 레이아웃입니까 아니면 더 큰 레이아웃의 일부입니까? 당신은 그것을 가지고 있습니다 : 당신의 완벽한 전망 .

이제 어느 시점에서 화면에 분명히 뷰를 배치해야하므로 어떻게해야합니까? Android에서 활동이라고 하는 CONTROLLER 이름에서 알 수 있듯이 활동은 일부 활동을 수행합니다. 1 단계에서 정의한보기를 표시하는 것이 유일한 목적 일지라도 몇 가지 조치를 수행합니다. 따라서 활동은 뷰를 가져 와서 화면에 표시합니다. 보기는 활동에 대해 아무것도 모르기 때문에 마찬가지로 활동은 실제 프리젠 테이션에 대해 아무것도 모른다. 우리 (프로그래머)는 활동에서 한 줄의 코드조차 변경하지 않고 뷰의 레이아웃을 여러 번 재 배열 할 수 있습니다.

이제 실제로 무언가를하지 않고 멋지고 잘 정의 된 xml 레이아웃을 제시하는 데별로 사용되지 않습니다. 사용자가 입력 한 데이터를 저장한다고 가정 해 봅시다. 활동은 사용자가 데이터를 가져 와서 다른 사람에게 전달하여 처리 (저장, 저장, 삭제)하기 위해이 프로세스를 처리해야합니다. 누구에게 전달됩니까? 글쎄, 모델에 . 나는 모델을 순수한 것으로 생각하고 싶다. 응용 프로그램 컨텍스트에 대해 전혀 모르는 Java 클래스입니다. 실제로는 거의 그렇지 않습니다.

이름, 주소, 나이의 세 가지 속성이있는 Person 클래스가 있다고 가정 해 봅시다. 내 XML 정의 레이아웃에는 사용자 입력을위한 이름, 주소, 연령의 3 가지 필드가 있습니다. 내 활동은 사용자 입력에서 세 가지 값을 가져 와서 새로운 Person 객체를 생성하고 Person 특정 로직을 처리하는 방법을 알고있는 메소드를 호출합니다. 거기 있어요 모델 뷰 컨트롤러.


1

나는 항상 패턴이 새로운 것이 아니며 수년 동안 주변에 있었다고 말함으로써 시작합니다.이 시점에서 그들은 호기심 많은 표정과 BAM을 제공합니다!

그리고 이전 답변과 같은 다양한 요점에 대해 거의 이야기 할 것이지만 JB King이 말한 것처럼 ASP.NET MVC 등은 문맥 상 중요하다고 생각합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.