Model-View-Controller : 사용자가 View 또는 Controller와 상호 작용합니까? [닫은]

최근 MVC 디자인 패턴에 대해 배웠습니다. Head First Design Pattern 책에서 배우고 있습니다.

이 책에 따르면 (정확하게 이해한다면) :

모델 은 대부분의 응용 프로그램 논리 및 데이터입니다.

보기 는 기본적으로 사용자에게 시각적으로 모델을 나타내는 GUI입니다.

컨트롤러 는 '중개'를 담당하고 뷰와 모델 사이의 '중간자'역할을합니다. View는 사용자가 조치를 취했음을 Controller에보고하고 Controller는이를 Model의 메소드 호출로 변환합니다.

그러나 웹상의 많은 부분이 그 책에서 이해 한 내용과 모순됩니다. 그들은 일반적으로 사용자가 뷰가 아닌 컨트롤러와 상호 작용한다고 주장합니다.

어느 것이 사실이거나 더 일반적인가요? 사용자가 Controller와 직접 또는 View와 직접 상호 작용합니까? 두 가지 방법 모두 허용됩니까? 어느 것이 더 흔합니까?

사용자는 View 와 상호 작용 하지만 View 는 작업을 Controller와 통신해야합니다 . 컨트롤러 업데이트 할 수 있습니다 모델 있지만 모든 / 변경에 필요하지 않습니다.

내가 제공하는 설명은 MVC의 .NET 구현에 대한 개인적인 경험을 바탕으로합니다. 구현 방법이 다를 수 있습니다.

컨트롤러 행동, 기본적으로 비즈니스 계층을 처리하는 곳입니다. 간단한 컨트롤러는 모델에서 데이터를 뷰로 가져 오는 것 이상을 수행하지 않습니다. 복잡한 컨트롤러는 보안 관리, 인증, 권한 부여, 등록 및 기타 여러 가지 작업에 이르기까지 모든 종류의 작업을 수행합니다.

보기 만 사용자가 이해할 수있는 방식으로 정보를 표시하는 책임을 져야한다. 단일 페이지 애플리케이션 (SPA)과 같은 것들이 사용자에 대한 데이터 유효성 검증 피드백을 가지므로 제어기와 모델 모두에 약간의 교차점이있을 수 있습니다. 다른 크로스 오버는 크게 찌그러집니다.

모델은 데이터를 다루고있다. 여기에는 데이터 유효성 검사가 포함됩니다 (해당되는 경우). 이 계층에서는 데이터 저장 및 검색도 처리됩니다.

최신 정보

누가 언제 무엇을하는지 주변에 혼란이있는 것 같습니다. MVC 아키텍처는 유사하지만 동일하지 않기 때문에 두 가지 다른 개요를 포함 시켰습니다. 어느 쪽이든 해석의 여지가 있습니다. 아마도 더 많은 것입니다. 위의 설명은이 방법론을 사용하여 응용 프로그램을 구축 한 경험을 포함하여 여러 소스에서 MVC를 해석 한 것입니다. 이 업데이트가 이러한 혼란을 해결하는 데 도움이되기를 바랍니다.

MVC는 소프트웨어 개발을위한 Separation of Concerns 디자인 패턴 을 구축하려는 시도 입니다. 그것은 주로 웹 기반 응용 프로그램에서 구현되었습니다 (내 지식으로).

보기는 사용자 상호 작용을 모두 처리합니다. 사용자가 버튼을 클릭하면보기는 클릭이 사용자 인터페이스 상호 작용인지 아니면 그 이외의 문제 (컨트롤러 상호 작용)인지 판별합니다. 버튼이 한 필드에서 다른 필드로 값을 복사하는 것과 같은 작업을 수행하는 경우 구현에서 이것이 뷰 문제인지 아니면 컨트롤러 문제인지를 결정합니다. 단일 페이지 응용 프로그램 (SPA)을 처리 할 때 이러한 문제가 발생할 가능성이 높습니다.

컨트롤러는 자신의 행동이 처리되는 곳입니다. 보기에서 사용자가 일부 필드의 값을 변경하기로 결정했음을 알 렸습니다. 컨트롤러는 해당 데이터에 대한 유효성 검사를 수행하거나 모델에서 처리 할 수 ​​있습니다. 다시 이것은 구현에 따라 다릅니다. 컨트롤러에 보안 기능이있는 경우 사용자에게 작업을 수행 할 수있는 권한이 충분하지 않은 것으로 판단 될 수 있습니다. 변경 사항을 거부하고 그에 따라보기를 업데이트합니다. 또한 컨트롤러는 모델에서 검색 할 데이터, 패키지 방법 및 해당 데이터로보기를 업데이트하는 방법을 결정합니다.

모델 방법과 위치 데이터를 저장하도록 결정한다. 또한 데이터를 저장하기 전에 해당 데이터의 유효성 검사를 수행 할 수도 있습니다 (사람이 경우에 따라보기를 무시하기 때문에이를 수행해야 함).

Wikipedia에는 ​​MVC에 대한 기사가 있습니다.

• 모델 상태에 변경이있는 경우는 그 관련 도면 / 뷰와 컨트롤러에 통지한다. 이 알림을 통해보기는 프리젠 테이션을 업데이트하고 컨트롤러는 사용 가능한 명령 세트를 변경할 수 있습니다. 경우에 따라서는 MVC 구현이 "수동적"일 수 있으므로 다른 구성 요소가 통보되지 않고 업데이트를 위해 모델을 폴링해야합니다.
• 뷰는 모든 컨트롤러는 사용자에게 출력 표현을 생성하기 위해 필요한 정보가 이야기된다. 또한 컨트롤러에 사용자 입력을 알리는 일반적인 메커니즘을 제공 할 수 있습니다.
• 컨트롤러 (예를 들어, 문서를 편집) 모델의 상태를 업데이트 할 모델에 명령을 보낼 수 있습니다. 또한 모델의보기 표시를 변경하기 위해 명령을 관련보기로 보낼 수도 있습니다 (예 : 문서를 스크롤하여).

Microsoft의 MVC 개요에서 .

• 모델. 모델 개체는 응용 프로그램의 데이터 도메인에 대한 논리를 구현하는 응용 프로그램의 일부입니다. 종종 모델 객체는 데이터베이스에서 모델 상태를 검색하고 저장합니다. 예를 들어 Product 개체는 데이터베이스에서 정보를 검색하고 조작 한 다음 업데이트 된 정보를 SQL Server 데이터베이스의 Products 테이블에 다시 쓸 수 있습니다.

  소규모 응용 분야에서 모델은 종종 물리적 인 모델이 아닌 개념적 분리입니다. 예를 들어 응용 프로그램에서 데이터 집합 만 읽고 뷰로 보내면 응용 프로그램에는 실제 모델 계층과 관련 클래스가 없습니다. 이 경우 데이터 셋은 모델 객체의 역할을합니다.

• 견해. 뷰는 응용 프로그램의 UI (사용자 인터페이스)를 표시하는 구성 요소입니다. 일반적으로이 UI는 모델 데이터에서 작성됩니다. 예를 들어 Product 개체의 현재 상태에 따라 텍스트 상자, 드롭 다운 목록 및 확인란을 표시하는 Products 테이블의 편집 뷰가 있습니다.

• 컨트롤러. 컨트롤러는 사용자 상호 작용을 처리하고 모델을 다루며 궁극적으로 UI를 표시하는 렌더링 할 뷰를 선택하는 구성 요소입니다. MVC 애플리케이션에서보기에는 정보 만 표시됩니다. 컨트롤러는 사용자 입력 및 상호 작용을 처리하고 응답합니다. 예를 들어, 컨트롤러는 쿼리 문자열 값을 처리하고이 값을 모델로 전달하며,이 값을 사용하여 데이터베이스를 쿼리 할 수 ​​있습니다.

사용자는 Controller 와 상호 작용합니다 . 당신이 상호 작용하지 않는 기술적 인 포인트의보기에서 보기 , 당신은 단지하고 사용 와 상호 작용을 컨트롤러 .

표면적으로는 사용자가 GUI와 상호 작용하고있는 것 같습니다-프로그래머가 아닌 사람에게는 이것이 더 의미가 있지만 기본적으로 보기가 아닌 컨트롤러 와 대화하는 버튼을 클릭하면됩니다 .

또한 모든 응용 프로그램, 심지어 MVC 웹 응용 프로그램에도 GUI가 없습니다. API를 통해 컨트롤러 와 상호 작용할 수 있습니다 ( url-routes예 : 컨트롤러 자체에 배치하는 것만으로 간단 함) .

컨트롤러는 장소가 될해야 수신 및 처리 , 사용자의 요청을. 따라서 어떻게 든 View 에서 직접 모델에 액세스하는 경우 방법에 관계없이 더 이상 MVC 가 아닙니다 .

사용자가 컨트롤러가 아닌 뷰와 직접 상호 작용하는 이유에 대한 구체적인 예를 살펴 보겠습니다.

iPhone의 음악 앱에서 고급 기능은 재생 목록을 재생하는 것입니다. "재생 목록 재생"은 앱의 컨트롤러 기능입니다.

해당 기능을 활성화하는 방법은 여러 가지가 있습니다. 앱 내부의 재생 목록을 클릭하거나 Siri (음성 인터페이스)에 동일한 기능을 수행하도록 요청할 수 있습니다. 그것들은 다양한 관점에서 인식되는 두 가지 다른 제스처 입니다.

각보기의 피드백도 다릅니다. Siri가 요청한 음악을 재생 중임을 알려줍니다. 음악 앱에 재생 목록을 재생하고 있다는 시각적 피드백이 표시됩니다.