MVC와 MVVM의 차이점은 무엇입니까? [닫은]

표준 "Model View Controller"패턴과 Microsoft의 Model / View / ViewModel 패턴간에 차이가 있습니까?

MVC / MVVM은 하나 또는 선택 이 아닙니다 .

두 가지 패턴은 ASP.Net 및 Silverlight / WPF 개발에서 서로 다른 방식으로 잘립니다.

ASP.Net의 경우 MVVM은 뷰 내에서 데이터를 양방향 바인딩 하는 데 사용됩니다 . 일반적으로 클라이언트 측 구현입니다 (예 : Knockout.js 사용). 반면에 MVC 는 서버 측에서 우려 를 분리하는 방법입니다 .

Silverlight 및 WPF의 경우 MVVM 패턴은보다 포괄적이며 MVC (또는 소프트웨어를 구성하는 다른 패턴을 별도의 책임으로 대체)로 대체하는 것처럼 보일 수 있습니다 . 자주 패턴 나온 하나의 가정은, (가)이었다 ViewModel단지에서 컨트롤러를 교체 MVC(방금 대체 할 수있는 것처럼 VM위한 C약자의 모든 용서받을 것입니다) ...

ViewModel이 별도의 컨트롤러에 대한 필요성을 반드시 대체 하지는 않습니다 .

문제는 : 독립적으로 테스트 할 수 있고 * 필요할 때 재사용 할 수 있다는 점에서 뷰 모델은 어떤 뷰가 뷰를 표시하는지 모르지만 더 중요한 것은 데이터가 어디에서 오는지 전혀 모른다는 것입니다 .

* 참고 : 실제로 컨트롤러는 ViewModel에서 단위 테스트가 필요한 대부분의 로직을 제거합니다. 그런 다음 VM은 테스트가 거의 필요없는 바보 같은 컨테이너가됩니다. VM은 디자이너와 코더 사이의 브리지 일 뿐이므로 간단합니다.

MVVM에서도 컨트롤러는 일반적으로 모든 처리 로직을 포함하고 어떤 뷰 모델을 사용하여 어떤 뷰에 어떤 데이터를 표시할지 결정합니다.

XAML 코드 숨김에서 코드를 제거 하여 XAML 편집을보다 독립적 인 작업으로 만드는 ViewModel 패턴의 주요 이점을 살펴 보았습니다 . 우리는 여전히 어플리케이션의 전체 로직을 제어하기 위해 컨트롤러를 생성합니다.

우리가 따르는 기본 MVCVM 지침은 다음과 같습니다.

• 뷰 는 특정 형태의 데이터를 표시합니다 . 그들은 데이터의 출처를 모릅니다.
• ViewModel 은 특정 형태의 데이터 및 명령을 보유하며 데이터 또는 코드의 출처 또는 표시 방법을 모릅니다.
• 모델 은 실제 데이터를 보유합니다 (다양한 컨텍스트, 저장 또는 기타 방법)
• 컨트롤러는 이벤트를 수신하고 게시합니다. 컨트롤러는 표시되는 데이터와 위치를 제어하는 ​​논리를 제공합니다. 컨트롤러는 ViewModel에 실제로 재사용 할 수 있도록 명령 코드를 ViewModel에 제공합니다.

또한 Sculpture 코드 생성 프레임 워크 는 MVVM 및 Prism과 유사한 패턴을 구현하며 모든 사용 사례 로직을 분리하기 위해 컨트롤러를 광범위하게 사용합니다.

컨트롤러가 View 모델에 의해 폐기되었다고 가정하지 마십시오.

나는이 주제에 대해 블로그를 시작했다 . 대부분의 내비게이션 시스템은 뷰와 VM을 사용하기 때문에 MVCVM을 일반 내비게이션 시스템과 결합하는 데 문제가 있지만, 이후 기사에서 다루겠습니다.

MVCVM 모델을 사용 하면 응용 프로그램 수명 동안 메모리에 컨트롤러 개체 만 있으면되며 컨트롤러에는 주로 코드와 적은 상태 데이터 (예 : 작은 메모리 오버 헤드)가 포함됩니다. 따라서 뷰 모델을 유지해야하는 솔루션보다 메모리를 많이 사용하는 앱이 훨씬 줄어들며 특정 유형의 모바일 개발 (예 : Silverlight / Prism / MEF를 사용하는 Windows Mobile)에 이상적입니다. 응답 성을 위해 가끔 캐시 된 VM을 유지해야 할 수도 있으므로 이는 물론 애플리케이션 유형에 따라 다릅니다.

참고 :이 게시물은 여러 번 편집되었으며 좁은 질문을 구체적으로 대상으로하지 않았으므로 이제 첫 번째 부분도 업데이트했습니다. 아래 설명에서 대부분의 논의는 더 넓은 그림이 아니라 ASP.Net에만 관련됩니다. 이 게시물은 Silverlight, WPF 및 ASP.Net에서 MVVM의 광범위한 사용을 다루고 사람들이 컨트롤러를 ViewModels로 교체하지 못하도록하려고합니다.

이 두문자어가 무엇을 의미하는지 이해하는 가장 쉬운 방법은 잠시 잊어 버리는 것입니다. 대신, 그들이 만든 소프트웨어, 각각에 대해 생각하십시오. 초기 웹과 데스크톱의 차이점으로 요약됩니다.

2000 년대 중반에 복잡성이 증가함에 따라 1970 년대에 처음 설명 된 MVC 소프트웨어 디자인 패턴이 웹 애플리케이션에 적용되기 시작했습니다. 데이터베이스, HTML 페이지 및 코드를 생각하십시오. MVC에 도달하기 위해이 부분을 약간 수정 해 보겠습니다.»database«의 경우 데이터베이스와 인터페이스 코드를 가정 해 봅시다. »HTML 페이지«의 경우 HTML 템플릿과 템플릿 처리 코드를 가정합니다. »code inbetween«의 경우, 사용자가 클릭을 행동으로 매핑하는 코드를 가정 해 데이터베이스에 영향을 미쳐 다른 뷰가 표시되게한다고 가정하겠습니다. 그것은 적어도이 비교의 목적을위한 것입니다.

이 웹 컨텐츠의 현재 기능을 그대로 유지하자. 그러나 10 년 전 자바 스크립트가 낮고 비열한 성가심이었던 실제 프로그래머는이를 피하기 위해 잘 해냈다. HTML 페이지는 본질적으로 멍청하고 수동적이다. . 브라우저는 씬 클라이언트이거나 그렇지 않은 경우 불량한 클라이언트입니다. 브라우저에 지능이 없습니다. 전체 페이지 다시로드 규칙 »view«는 매번 새로 생성됩니다.

이 웹 방식은 모든 분노에도 불구하고 데스크톱과 비교할 때 엄청나게 뒤떨어져 있음을 기억하십시오. 데스크톱 앱은 뚱뚱한 클라이언트 또는 리치 클라이언트입니다. (Microsoft Word와 같은 프로그램도 일종의 클라이언트, 문서 용 클라이언트로 생각할 수 있습니다.) 그들은 지능이 풍부하고 데이터에 대한 지식이 풍부한 클라이언트입니다. 상태가 양호합니다. 처리중인 데이터를 메모리에 캐시합니다. 전체 페이지를 새로 고침하는 것과 같은 쓰레기는 없습니다.

이 풍부한 데스크탑 방식은 아마도 두 번째 약어 인 MVVM이 시작된 곳일 것입니다. C의 생략으로 인해 문자에 속지 마십시오. 컨트롤러는 여전히 있습니다. 그들은해야합니다. 아무것도 제거되지 않습니다. 상태 저장 (statefulness), 클라이언트에 캐시 된 데이터 (및 해당 데이터를 처리하는 인텔리전스와 함께) 한 가지만 추가하면됩니다. 이 데이터, 본질적으로 클라이언트의 캐시는 이제»ViewModel«이라고합니다. 풍부한 상호 작용이 가능합니다. 그리고 그게 다야.

• MVC = 모델, 컨트롤러,보기 = 기본적으로 단방향 통신 = 불량한 대화 형 작업
• MVVM = 모델, 컨트롤러, 캐시,보기 = 양방향 통신 = 풍부한 상호 작용

Flash, Silverlight 및 가장 중요한 JavaScript를 통해 웹에 MVVM이 포함되어 있음을 알 수 있습니다. 브라우저는 더 이상 합법적으로 씬 클라이언트라고 할 수 없습니다. 그들의 프로그래밍 가능성을보십시오. 메모리 소비량을보십시오. 최신 웹 페이지에서 모든 Javascript 상호 작용을 살펴보십시오.

개인적으로 저는이 이론과 약어 비즈니스가 구체적인 현실에서 무엇을 의미하는지 이해함으로써 이해하기 쉽다는 것을 알게되었습니다. 추상적 인 개념은 특히 구체적인 문제에 대해 설명 할 때 유용하므로 이해는 완전한 원이 될 수 있습니다.

MVVM Model-View ViewModel 은 MVC, Model-View Controller 와 유사합니다.

컨트롤러 가 ViewModel 로 교체되었습니다 . ViewModel은 UI 레이어 아래에 있습니다. ViewModel은 뷰에 필요한 데이터 및 명령 객체를 노출합니다. 이것을 데이터와 액션을 얻는 컨테이너 객체로 생각할 수 있습니다. ViewModel은 모델에서 데이터를 가져옵니다.

Russel East 는 블로그에서 MVVM이 MVC와 다른 이유 에 대해 자세히 설명합니다.

우선 MVVM은 XAML을 사용하여 디스플레이를 처리하는 MVC 패턴의 진행입니다. 이 기사 에서는 두 가지 측면 중 일부를 간략하게 설명합니다.

Model / View / ViewModel 아키텍처의 주요 추력은 데이터 ( "모델") 위에 데이터 개념을보다 밀접하게 매핑하는 비 시각적 구성 요소 ( "ViewModel")의 또 다른 계층이있는 것 같습니다. 데이터보기의 개념 ( "보기"). 모델이 아닌 뷰가 바인딩되는 ViewModel입니다.

Microsoft는 여기 Windows 환경에서 MVVM 패턴에 대한 설명을 제공 했습니다 .

중요한 섹션은 다음과 같습니다.

Model-View-ViewModel 디자인 패턴에서 앱은 세 가지 일반 구성 요소로 구성됩니다.

• 모델 : 앱이 사용하는 데이터 모델을 나타냅니다. 예를 들어 사진 공유 앱에서이 계층은 장치에서 사용 가능한 사진 세트와 사진 라이브러리를 읽고 쓰는 데 사용되는 API를 나타낼 수 있습니다.

• 보기 : 일반적으로 앱은 여러 페이지의 UI로 구성됩니다. 사용자에게 표시되는 각 페이지는 MVVM 용어로보기입니다. 뷰는 사용자가 보는 것을 정의하고 스타일을 지정하는 데 사용되는 XAML 코드입니다. 모델의 데이터는 사용자에게 표시되며 앱의 현재 상태를 기반으로 UI에이 데이터를 제공하는 것이 ViewModel의 작업입니다. 예를 들어 사진 공유 앱에서보기는 사용자에게 장치의 앨범 목록을 보여주는 UI, 앨범의 사진 및 사용자에게 특정 사진을 보여주는 다른 UI가됩니다.

• ViewModel : ViewModel은 데이터 모델 또는 단순히 모델을 앱의 UI 또는 뷰에 연결합니다. 여기에는 모델의 데이터를 관리하는 논리가 포함되어 있으며 XAML UI 또는 뷰가 바인딩 할 수있는 속성 집합으로 데이터를 노출합니다. 예를 들어 사진 공유 앱에서 ViewModel은 앨범 목록을 표시하고 각 앨범마다 사진 목록을 표시합니다. UI는 사진의 출처와 검색 방법에 관계없이 사용할 수 있습니다. ViewModel에 의해 노출 된 일련의 그림을 알고 사용자에게 보여줍니다.

주된 차이점 중 하나는 MVC에서 V가 M을 직접 읽고 C를 통해 데이터를 조작하는 반면 MVVM에서는 VM이 ​​M 프록시 역할을하며 사용 가능한 기능을 제공한다는 점입니다. V.

내가 쓰레기로 가득 차 있지 않다면, 아무도 하이브리드를 만들지 않은 것에 놀랐습니다. 여기서 VM은 단지 M 프록시이며 C는 모든 기능을 제공합니다.

MVC는 통제 된 환경이고 MVVM은 반응적인 환경입니다.

통제 된 환경에서는 코드가 적고 일반적인 논리 소스가 있어야합니다. 항상 컨트롤러 내에 있어야합니다. 하나; 웹 세계에서 MVC는 뷰 생성 로직과 뷰 동적 로직으로 쉽게 구분됩니다. 생성은 서버에서 이루어지고 동적 수명은 클라이언트에서 이루어집니다. AngularJS와 결합 된 ASP.NET MVC의 경우이 점을 많이 볼 수 있지만 서버는 모델을 작성하고 모델에 전달하여 클라이언트로 보냅니다. 그러면 클라이언트는 View와 상호 작용하며이 경우 AngularJS는 로컬 컨트롤러로 들어갑니다. 제출 된 모델 또는 새 모델은 서버 컨트롤러로 다시 전달되어 처리됩니다. (사이클이 계속되고 소켓이나 AJAX 등으로 작업 할 때이 처리에 대한 다른 많은 번역이 있지만 모든 아키텍처에서 동일합니다.)

MVVM은 일반적으로 일부 이벤트를 기반으로 활성화되는 코드 (예 : 트리거)를 작성하는 사후 환경입니다. MVVM이 번성하는 XAML에서는 내장 된 데이터 바인딩 프레임 워크를 사용하여이 작업을 쉽게 수행 할 수 있지만 BUT은 프로그래밍 언어가있는 모든 뷰에서 모든 시스템에서 작동합니다. MS 특정이 아닙니다. ViewModel (일반적으로 속성 변경 이벤트)이 실행되고 View는 생성 한 트리거에 따라 반응합니다. 이것은 기술적으로 얻을 수 있지만 결론은 View가 Stateless이며 논리가 없다는 것입니다. 단순히 값을 기준으로 상태를 변경합니다. 또한 ViewModel은 로직이 거의없는 상태 비 저장이며 모델은 상태 만 유지해야하므로 기본적으로 로직이 0 인 상태입니다. 나는 이것을 응용 프로그램 상태 (모델), 상태 번역기 (ViewModel), 그리고 시각적 상태 / 상호 작용 (보기)으로 설명합니다.

MVC 데스크톱 또는 클라이언트 측 응용 프로그램에는 모델이 있어야하며 컨트롤러에서 모델을 사용해야합니다. 모델을 기반으로 컨트롤러가보기를 수정합니다. 보기는 일반적으로 인터페이스가있는 컨트롤러에 연결되므로 컨트롤러가 다양한보기로 작업 할 수 있습니다. ASP.NET에서 MVC의 로직은 컨트롤러가 모델을 관리하고 모델을 선택된 뷰로 전달함에 따라 서버에서 약간 뒤로 향합니다. 그런 다음 View는 모델을 기반으로하는 데이터로 채워지며 자체 로직 (일반적으로 AngularJS와 같은 다른 MVC 세트)을 갖습니다. 사람들은 이것을 논쟁하고 응용 프로그램 MVC와 혼동하여 프로젝트 유지 관리가 결국 재앙이 될 시점에서 두 가지를 모두 시도합니다. MVC를 사용할 때는 항상 논리와 제어를 한 위치에 두십시오. 컨트롤러 또는 모델 데이터를 수용하기 위해 View의 코드 뒤에 (또는 웹을 위해 JS를 통한 View에서) View 로직을 작성하지 마십시오. 컨트롤러가보기를 변경하도록합니다. View에 있어야하는 유일한 논리는 사용중인 인터페이스를 통해 작성하고 실행하는 데 필요한 모든 것입니다. 이에 대한 예는 사용자 이름과 비밀번호를 제출하는 것입니다. 데스크톱 또는 웹 페이지 (클라이언트의) 여부에 상관없이 Controller는 View가 제출 조치를 실행할 때마다 제출 프로세스를 처리해야합니다. 올바르게 수행하면 항상 MVC 웹 또는 로컬 앱을 쉽게 찾을 수 있습니다. 데스크톱 또는 웹 페이지 (클라이언트의) 여부에 상관없이 Controller는 View가 제출 조치를 실행할 때마다 제출 프로세스를 처리해야합니다. 올바르게 수행하면 항상 MVC 웹 또는 로컬 앱을 쉽게 찾을 수 있습니다. 데스크톱 또는 웹 페이지 (클라이언트의) 여부에 상관없이 Controller는 View가 제출 조치를 실행할 때마다 제출 프로세스를 처리해야합니다. 올바르게 수행하면 항상 MVC 웹 또는 로컬 앱을 쉽게 찾을 수 있습니다.

MVVM은 완전히 반응하므로 개인적으로 가장 좋아합니다. 모델이 상태를 변경하면 ViewModel이 해당 상태를 수신하고 변환합니다. 그런 다음 View는 상태 변경을 위해 ViewModel을 수신하고 ViewModel의 변환에 따라 업데이트됩니다. 어떤 사람들은 그것을 순수한 MVVM이라고 부르지 만 실제로는 하나 뿐이며 어떻게 주장하는지 상관하지 않으며 항상 View에 논리가없는 순수한 MVVM입니다.

다음은 약간의 예입니다. 버튼을 누를 때 메뉴 슬라이드가 표시되도록하겠습니다. MVC에서는 인터페이스에 MenuPressed 액션이 있습니다. 컨트롤러는 메뉴 버튼을 클릭 한 후 SlideMenuIn과 같은 다른 인터페이스 방법에 따라 메뉴에서 슬라이드를 보도록 지시합니다. 어떤 이유로 왕복 여행? 컨트롤러가 당신이 할 수 없거나 다른 것을하고 싶을 경우를 대비하십시오. 컨트롤러는 별도의 지시가없는 한 뷰가없는 상태에서 뷰를 담당해야합니다. 하나; MVVM에서 애니메이션의 슬라이드 메뉴는 내장되어 있고 일반적이어야하며, 슬라이드 인하라는 메시지 대신 어떤 값을 기준으로합니다. 따라서 ViewModel을 수신하고 ViewModel에 IsMenuActive = true (또는 그에 대한) 애니메이션이 표시됩니다. 지금, 그것으로 나는 또 다른 요점을 정말로 명확하게하고 싶다고 말하면서주의를 기울여야한다. IsMenuActive는 아마도 BAD MVVM 또는 ViewModel 디자인 일 것입니다. ViewModel을 설계 할 때 View에 기능이 전혀 없다고 가정하고 변환 된 모델 상태 만 전달하면 안됩니다. 그렇게하면 메뉴를 제거하기 위해보기를 변경하고 데이터 / 옵션을 다른 방법으로 표시하기로하면 ViewModel은 신경 쓰지 않습니다. 메뉴를 어떻게 관리하겠습니까? 데이터가 의미가있을 때 그렇게됩니다. 따라서이를 수행하는 한 가지 방법은 메뉴에 옵션 목록 (아마도 내부 ViewModel 배열)을 제공하는 것입니다. 해당 목록에 데이터가있는 경우 메뉴는 트리거를 통해 열리는 것을 알고 그렇지 않은 경우 트리거를 통해 숨기는 것을 알고 있습니다. 메뉴에 대한 데이터가 있거나 ViewModel에 없습니다. ViewModel에서 해당 데이터를 표시 / 숨기기로 결정하지 마십시오. 단순히 모델의 상태를 번역하십시오. 이러한 방식으로 View는 완전히 반응적이고 일반적이며 다양한 상황에서 사용할 수 있습니다.

각각의 아키텍처에 대해 조금이라도 익숙하지 않고 인터넷에서 많은 BAD 정보를 찾을 때 매우 혼란 스러울 수 있다는 것을 배우면이 모든 것이 아마도 의미가 없습니다.

그러니 .. 이걸 얻기 위해 명심해야 할 것들. 애플리케이션 설계 방법과 STICK TO IT를 먼저 결정하십시오.

훌륭한 MVC를 수행하는 경우 Controller가 관리 가능하고 View를 완전히 제어 할 수 있는지 확인하십시오. 큰보기가있는 경우 다른 컨트롤러가있는보기에 컨트롤을 추가하는 것이 좋습니다. 다만 해당 컨트롤러를 다른 컨트롤러에 캐스케이드 연결하지 마십시오. 유지하기가 매우 실망합니다. 별도의 구성 요소로 작동하는 방식으로 잠시 시간을내어 물건을 개별적으로 설계하십시오. 그리고 항상 컨트롤러가 모델에 스토리지를 커밋하거나 유지하도록 지시하십시오. MVC에 대한 이상적인 종속성 설정은 View ← Controller → Model 또는 ASP.NET을 사용하는 것입니다 (시작하지 마십시오) Model ← View ↔ Controller → Model (여기서 Model은 컨트롤러마다 다르거 나 완전히 다른 모델 일 수 있습니다)...이 시점에서 View의 Controller에 대해 알아야 할 유일한 점은 주로 엔드 포인트 참조가 모델을 다시 전달할 위치를 아는 것입니다.

당신이 MVVM을한다면, 나는 당신의 친절한 영혼을 축복하지만, 그것을 올바르게하기 위해 시간이 걸립니다! 인터페이스를 사용하지 마십시오. View가 값을 기반으로 표시되는 방식을 결정하도록합니다. Mock 데이터가있는 View로 재생하십시오. 당시에 원하지 않더라도 메뉴를 보여주는보기가 표시되면 (예 : GOOD). 당신은보기가 정상적으로 작동하고 값을 기준으로 반응하고 있습니다. ViewModel이 특정 변환 상태에 있거나이 상태를 비우도록 ViewModel에 명령 할 때 발생하지 않도록 트리거에 몇 가지 요구 사항을 추가하십시오. ViewModel에서 View가 볼지 여부를 결정하는 것처럼 내부 논리로 이것을 제거하지 마십시오. ViewModel에 메뉴가 있거나 없다고 가정 할 수는 없습니다. 그리고 마지막으로, 모델을 사용하면 상점 상태를 변경하고 가능하게 할 수 있습니다. 여기에서 유효성 검사와 모든 작업이 수행됩니다. 예를 들어, 모델이 상태를 수정할 수없는 경우 단순히 더럽거나 무언가로 플래그가 지정됩니다. ViewModel이 이것을 인식하면 더러워진 것을 번역하고 View는 이것을 인식하고 다른 트리거를 통해 정보를 보여줍니다. View의 모든 데이터는 ViewModel에 바인딩 될 수 있으므로 모든 것이 동적 일 수 있으며 ViewModel은 View가 바인딩에 어떻게 반응하는지 전혀 모릅니다. 사실 Model은 ViewModel에 대해 전혀 모릅니다. 의존성을 설정할 때 그렇게 가리켜 야합니다. t 상태를 수정하면 단순히 더럽거나 무언가로 표시됩니다. ViewModel이 이것을 인식하면 더러워진 것을 번역하고 View는 이것을 인식하고 다른 트리거를 통해 정보를 보여줍니다. View의 모든 데이터는 ViewModel에 바인딩 될 수 있으므로 모든 것이 동적 일 수 있으며 ViewModel은 View가 바인딩에 어떻게 반응하는지 전혀 모릅니다. 사실 Model은 ViewModel에 대해 전혀 모릅니다. 의존성을 설정할 때 그렇게 가리켜 야합니다. t 상태를 수정하면 단순히 더럽거나 무언가로 표시됩니다. ViewModel이 이것을 인식하면 더러워진 것을 번역하고 View는 이것을 인식하고 다른 트리거를 통해 정보를 보여줍니다. View의 모든 데이터는 ViewModel에 바인딩 될 수 있으므로 모든 것이 동적 일 수 있으며 ViewModel은 View가 바인딩에 어떻게 반응하는지 전혀 모릅니다. 사실 Model은 ViewModel에 대해 전혀 모릅니다. 의존성을 설정할 때 그렇게 가리켜 야합니다. View의 모든 데이터는 ViewModel에 바인딩 될 수 있으므로 모든 것이 동적 일 수 있으며 ViewModel은 View가 바인딩에 어떻게 반응하는지 전혀 모릅니다. 사실 Model은 ViewModel에 대해 전혀 모릅니다. 의존성을 설정할 때 그렇게 가리켜 야합니다. View의 모든 데이터는 ViewModel에 바인딩 될 수 있으므로 모든 것이 동적 일 수 있으며 ViewModel은 View가 바인딩에 어떻게 반응하는지 전혀 모릅니다. 사실 Model은 ViewModel에 대해 전혀 모릅니다. 의존성을 설정할 때 그렇게 가리켜 야합니다.View → ViewModel → Model (여기서 참고 사항 ... 이것은 아마도 논쟁의 여지가 있지만 아마도 신경 쓰지 않습니다 ... MODEL을 변경할 수없는 경우가 아니라면 VIEW에 모델을 전달하지 마십시오. 적절한 ViewModel. View에는 모델 기간이 표시되지 않아야합니다. 쥐가 당신이 본 데모 나 수행 방식을 깨뜨 렸습니다.

마지막 팁은 다음과 같습니다. 잘 디자인되었지만 매우 간단한 MVC 응용 프로그램을 살펴보고 MVVM 응용 프로그램에 대해서도 동일하게 수행하십시오. 하나는 유연성이 0으로 제한되어 있고, 다른 하나는 제어가없고 무제한의 유연성이 있습니다.

제어 된 환경은 일련의 컨트롤러 또는 (단일 소스)에서 전체 애플리케이션을 관리하는 데 유용하지만, 반응성 환경은 나머지 애플리케이션이 무엇을하는지 전혀 몰라도 별도의 리포지토리로 나눌 수 있습니다. 마이크로 관리 대 무료 관리.

내가 당신을 충분히 혼동하지 않았다면 저에게 연락을 시도하십시오 ... 나는 그림과 예를 가지고 이것을 자세히 자세히 설명하지 않습니다.

하루가 끝나면 우리는 모든 프로그래머이며 코딩 할 때 그 무정부 상태가 우리 안에 살고 있습니다. 그래서 규칙이 깨지고 이론이 바뀌고이 모든 것이 호그 워시로 끝날 것입니다. 프로젝트와 대규모 팀에서 실제로 디자인 패턴에 동의하고이를 시행하는 데 도움이됩니다. 언젠가는 처음에 취해진 작은 추가 단계가 나중에 도약과 저축의 경계가 될 것입니다.

간단한 차이점 : (Yaakov의 Coursera AngularJS 과정에서 영감을 얻음)

MVC (모델 뷰 컨트롤러)

1. 모델 : 모델에는 데이터 정보가 포함됩니다. 컨트롤러 및보기를 호출하거나 사용하지 않습니다. 비즈니스 로직과 데이터를 나타내는 방법을 포함합니다. 이 데이터 중 일부는 일부 형식으로보기에 표시 될 수 있습니다. 일부 소스에서 데이터를 검색하는 논리도 포함 할 수 있습니다.
2. 컨트롤러 : 보기와 모델 간의 연결 역할을합니다. 통화보기 컨트롤러 및 컨트롤러가 모델을 호출합니다. 기본적으로 모델 및 / 또는보기에 적절하게 변경하도록 알립니다.
3. 보기 : UI 부분을 다룹니다. 사용자와 상호 작용합니다.

MVVM (모델 뷰 뷰 모델)

뷰 모델 :

1. 뷰 상태를 나타냅니다.
2. 뷰에 표시되는 데이터를 보유합니다.
3. 이벤트 표시 (일명 프레젠테이션 논리)에 응답합니다.
4. 비즈니스 로직 처리를위한 다른 기능을 호출합니다.
5. 뷰에 아무것도 표시하도록 직접 요청하지 마십시오.

MVVM은 프레젠테이션 모델 패턴을 개선 한 것입니다. WPF가 데이터 바인딩 및 명령 처리 기능을 제공하는 방법에 차이가 있기 때문에 논쟁의 여지가 있습니다.

뷰 모델은 사용자 인터페이스 요소에 대한 "추상적 인"모델입니다. 명령과 뷰에서 시각적으로 보이지 않는 방식으로 작업을 수행 할 수 있어야합니다 (예 : 테스트).

MVC로 작업 한 경우 뷰 상태를 반영하는 모델 객체를 작성하는 데 유용 할 수 있습니다 (예 : 일부 편집 대화 상자 표시 및 숨기기 등).이 경우 뷰 모델을 사용하고 있습니다.

MVVM 패턴은 모든 UI 요소에 대한 연습을 일반화 한 것입니다.

그리고 이것은 Microsoft 패턴이 아니며 WPF / Silverlight 데이터 바인딩이이 패턴과 함께 작동하기에 특히 적합하다는 것입니다. 그러나 예를 들어 Java 서버 얼굴과 함께 사용하는 것은 아무것도 없습니다.

다른 답변은 건축 패턴의 주제에 익숙하지 않은 사람에게는 이해하기 쉽지 않을 수 있습니다. 앱 아키텍처를 처음 사용하는 사람은 앱 선택이 실제로 앱에 어떤 영향을 줄 수 있으며 커뮤니티의 모든 소란이 무엇인지 알고 싶어 할 수 있습니다.

위의 내용을 밝히기 위해 MVVM, MVP 및 MVC와 관련된 시나리오를 구성했습니다. 이야기는 사용자가 영화 검색 앱에서 '찾기'버튼을 클릭함으로써 시작됩니다…

사용자 : 클릭…

보기 : 누구입니까? [ MVVM | MVP | MVC ]

사용자 : 방금 검색 버튼을 클릭했습니다…

보기 : 좋아, 잠깐만… [ MVVM | MVP | MVC ]

( 보기 호출 뷰 모델을 | 발표자 | 컨트롤러 ...) [ MVVM | MVP | MVC ]

보기 : Hey ViewModel | 발표자 | Controller 사용자가 방금 검색 버튼을 클릭했습니다. 어떻게해야합니까? [ MVVM | MVP | MVC ]

ViewModel | 발표자 | Controller : Hey View , 해당 페이지에 검색어가 있습니까? [ MVVM | MVP | MVC ]

보기 : 예, 여기 있습니다… "피아노"[ MVVM | MVP | MVC ]

-이 사이의 가장 중요한 차이점이다 MVVM 과 MVP는 | MVC ———

발표자 : 감사합니다. 보기 … 모델 에서 검색어를 찾는 중 진행률 표시 줄을 보여주십시오 [ MVP | MVC ]

( 발표자 | 컨트롤러 가 모델을 부릅니다 …) [ MVP | MVC ]

ViewController : 감사합니다. 모델 에서 검색어를 찾겠 지만 직접 업데이트하지는 않습니다. 대신 결과가 있으면 searchResultsListObservable에 이벤트를 트리거합니다. 그래서 당신은 더 잘 관찰했습니다. [ MVVM ]

(searchResultsListObservable의 트리거를 관찰하는 동안 View 는 ViewModel 이 대화하지 않기 때문에 사용자에게 진행률 표시 줄을 표시해야한다고 생각합니다 )

————————————————————————————

ViewModel | 발표자 | 컨트롤러 : Hey Model ,이 검색어와 일치하는 것이 있습니까? : "piano"[ MVVM | MVP | MVC ]

모델 : Hey ViewModel | 발표자 | 컨트롤러 , 점검하겠습니다… [ MVVM | MVP | MVC ]

( 모델 이 영화 데이터베이스에 쿼리하고 있습니다…) [ MVVM | MVP | MVC ]

( 잠시 후 … )

———— 이것은 MVVM , MVP 및 MVC의 차이점입니다. ————

모델 : ViewModel | 발표자 , 여기에 JSON "[{"name ":"Piano Teacher ","year ": 2001}, {"name ":"Piano ","year ": 1993}]"[ MVVM | MVP ]

모델 : 사용 가능한 결과가 있습니다. 컨트롤러. 인스턴스에서 필드 변수를 만들고 결과로 채웠습니다. 이름은 "searchResultsList"입니다. [ MVC ]

( 발표자 | 컨트롤러 감사 모델 및 다시 보기 ) [ MVP | MVC ]

발표자 : View 를 기다려 주셔서 감사합니다. 일치하는 결과 목록을 찾아서 발표 가능한 형식 ([ "Piano Teacher 2001", "Piano 1993"])으로 정리했습니다. 또한 진행률 표시 줄을 숨기십시오 [ MVP ]

Controller : View 를 기다려 주셔서 감사 합니다. 모델에 검색어를 요청했습니다. 일치하는 결과 목록을 찾아 인스턴스 내부의 "searchResultsList"라는 변수에 저장했다고합니다. 거기에서 얻을 수 있습니다. 또한 진행률 표시 줄을 숨기십시오 [ MVC ]

ViewModel : searchResultsListObservable의 모든 관찰자에게 [“Piano Teacher 2001 ″,”Piano 1993”] 형식의 새로운 목록이 있음을 알립니다. [ MVVM ]

보기 : 감사합니다. 발표자 [ MVP ]

보기 : 감사합니다.“ Controller ”[ MVC ] (이제 보기 자체에 의문이 생겼습니다. 모델 에서 얻은 결과 를 사용자에게 어떻게 제시해야합니까? 영화 제작 연도가 가장 먼저 또는 마지막에 있어야합니까…?)

View : 오, searchResultsListObservable에 새로운 트리거가 있습니다 ..., 좋습니다. 프레젠터 블 목록이 있습니다. 이제는 목록에 표시하면됩니다. 결과가 표시되므로 진행률 표시 줄을 숨겨야합니다. [ MVVM ]

당신이 관심이 경우, 나는 일련의 기사를 작성했습니다 여기에 영화는 안드로이드 응용 프로그램을 검색 구현하여 MVVM, MVP 및 MVC를 비교.

MVC를 사용하여 강력한 형식의 ViewModel을 View에 주입

1. 컨트롤러는 ViewModel을 새로 고쳐 View에 주입합니다. (요청 받기)
2. ViewModel은 마지막으로 선택한 항목 등과 같은 DataContext 및 뷰 상태의 컨테이너입니다.
3. 모델에는 DB 엔터티가 포함되어 있으며 쿼리 및 필터링을 수행하는 DB 스키마와 매우 유사합니다. (나는 이것을 위해 EF와 LINQ를 좋아한다)
4. 모델은 또한 리포지토리 및 / 또는 결과를 강력한 유형으로 프로젝션하는 것을 고려해야합니다 (EF에는 훌륭한 방법이 있습니다 ... 느린 인수입니다. EF 는 느리지 않습니다 !
5. ViewModel은 데이터를 가져오고 비즈니스 규칙 및 유효성 검사를 수행합니다.
6. 포스트 백의 컨트롤러 는 ViewModel Post 메소드를 계산하고 결과를 기다립니다.
7. 컨트롤러는 새로 업데이트 된 Viewmodel을 View에 주입합니다. 보기는 강력한 유형 바인딩 만 사용 합니다 .
8. 뷰는 단지 데이터를 렌더링하고 이벤트를 컨트롤러에 다시 게시합니다. (아래 예 참조)
9. MVC는 인바운드 요청을 가로 채고 강력한 데이터 유형의 적절한 컨트롤러로 라우팅합니다.

이 모델에서는 MSFT의 MVC 시스템이이를 숨기기 때문에 요청 또는 응답 객체와 더 이상 HTTP 수준의 접촉 이 없습니다 .

위의 항목 6에 대한 설명에서 (요청에 따라) ...

다음과 같이 ViewModel을 가정하십시오.

public class myViewModel{
     public string SelectedValue {get;set;}
public void Post(){
    //due to MVC model binding the SelectedValue string above will be set by MVC model binding on post back.
    //this allows you to do something with it.
    DoSomeThingWith(SelectedValue);
    SelectedValue = "Thanks for update!";
 }
}

게시물의 컨트롤러 방법은 다음과 같습니다 (아래 참조). mvm 인스턴스는 MVC 바인딩 메커니즘에 의해 자동으로 설정됩니다. 결과적으로 쿼리 문자열 레이어로 드롭 다운 할 필요가 없습니다! 쿼리 문자열을 기반으로 ViewModel을 인스턴스화하는 MVC입니다!

[HTTPPOST]   
public ActionResult MyPostBackMethod (myViewModel mvm){
         if (ModelState.IsValid)
        {
               // Immediately call the only method needed in VM...
               mvm.Post()
        }
      return View(mvm);
}

위의이 작업 방법이 의도 한대로 작동하려면 게시물에 반환되지 않은 항목을 처리하는 null CTOR이 정의되어 있어야합니다. 포스트 백 또한 변경된 사항에 대한 이름 / 값 쌍을 다시 게시해야합니다. 이름 / 값 쌍이 누락 된 경우 MVC 바인딩 엔진은 단순히 아무것도하지 않는 올바른 작업을 수행합니다! 이런 일이 발생하면 "포스트 백에서 데이터를 잃어 가고 있습니다"라는 메시지가 표시 될 수 있습니다.

이 패턴의 장점은 ViewModel이 Model / Buisness 로직과 인터페이스하는 모든 "클러 터"작업을 수행한다는 것입니다. 컨트롤러는 일종의 라우터 일뿐입니다. 실제로 SOC입니다.

MVVM은 뷰 모델을 믹스에 추가합니다. UI 모델을 일반 모델에 넣지 않고도 WPF의 많은 바인딩 접근 방식을 사용할 수 있으므로 중요합니다.

틀렸을 수도 있지만 MVVM이 실제로 컨트롤러를 믹스로 강제 실행하는지 확실하지 않습니다. http://martinfowler.com/eaaDev/PresentationModel.html 과 더 일치하는 개념을 찾았습니다 . 사람들이 MVC와 결합하여 패턴에 내장 된 것이 아니라고 생각합니다.

내가 알 수 있듯이 MVVM은 MVC의 MV에 매핑됩니다. 즉, 전통적인 MVC 패턴에서 V는 M과 직접 통신하지 않습니다. MVC의 두 번째 버전에는 M과 V 사이에 직접 링크가 있습니다. MV 및 V 통신과 관련된 모든 작업을 수행하고이를 결합하여 C에서 분리합니다. 실제로 MVVM에서 완전히 설명되지 않은 더 큰 범위의 응용 프로그램 워크 플로 (또는 사용 시나리오 구현)가 있습니다. 이것이 컨트롤러의 역할입니다. 컨트롤러에서 이러한 낮은 수준의 측면을 제거하면 더 깨끗하고 응용 프로그램의 사용 시나리오 및 비즈니스 논리를 쉽게 수정할 수 있으며 컨트롤러의 재사용 성을 높일 수 있습니다.

이것이 MVVM 의 기원 을 언급하지 않고 투표율이 높은 답변이라는 사실에 놀랍습니다 . MVVM 은 Microsoft 커뮤니티에서 널리 사용되는 용어이며 Martin Fowler의 프레젠테이션 모델 에서 유래 되었습니다 . 따라서 패턴의 동기와 다른 요소와의 차이점을 이해하려면 패턴에 대한 원본 기사를 먼저 읽으십시오.

일반적으로 MVC는 웹 개발에 사용되며 MVVM은 WPF / Silverlight 개발에 가장 많이 사용됩니다. 그러나 때로는 웹 아키텍트에 MVC와 MVVM이 혼합되어있을 수 있습니다.

예를 들어 : knockout.js를 사용할 수 있으며이 경우 클라이언트 측에 MVVM이 있습니다. MVC의 서버 측도 변경 될 수 있습니다. 복잡한 앱에서는 아무도 순수한 모델을 사용하지 않습니다. ViewModel을 MVC의 "모델"로 사용하는 것이 좋을 수 있으며 실제 모델은 기본적으로이 VM의 일부가됩니다. 이것은 추가적인 추상화 레이어를 제공합니다.

MVVMC (또는 아마도 MVC +)는 빠른 응용 프로그램 개발뿐만 아니라 엔터프라이즈에 적합한 방법으로 보입니다. UI를 비즈니스 및 상호 작용 논리와 분리하는 것이 좋지만 '순수한'MVVM 패턴과 대부분의 사용 가능한 예는 단일 뷰에서 가장 잘 작동합니다.

그러나 디자인에 대해서는 잘 모르지만 대부분의 응용 프로그램에는 페이지와 여러 (재사용 가능한) 뷰가 포함되어 있으므로 ViewModel이 어느 정도 상호 작용해야합니다. 컨트롤러로 페이지를 사용하면 MVVM의 목적을 완전히 상실하게되므로 기본 논리에 "VM-C"접근 방식을 사용하지 않으면 애플리케이션이 성숙함에 따라 .. .. 어려운 구성이 생성 될 수 있습니다. VB-6에서도 우리 대부분은 비즈니스 로직을 Button 이벤트로 코딩하는 것을 중단하고 컨트롤러에 '릴레이'명령을 시작했습니다. 나는 최근에 그 주제에 관한 많은 새로운 프레임 워크를 보았습니다. 내가 가장 좋아하는 것은 Magellan (codeplex) 접근법입니다. 행복한 코딩!

http://en.wikipedia.org/wiki/Model_View_ViewModel#References

ViewModel은 Controller와 기능이 완전히 다르기 때문에 MVVM에서 Controller는 ViewModel로 대체되지 않습니다. 컨트롤러가 없으면 컨트롤러가 필요합니다. 모델, ViewModel 및 View가 많은 작업을 수행하지 않기 때문입니다. MVVM에는 컨트롤러도 있습니다. MVVM이라는 이름은 틀린 것입니다.

MVVMC는 겸손한 견해로는 올바른 이름입니다.

보시다시피 ViewModel은 MVC 패턴에 추가 된 것입니다. 컨트롤러에서 ViewModel로 변환 논리 (예 : 객체를 문자열로 변환)를 이동합니다.

나는 이것을 위해 중간 기사를 만들었다.

MVVM

1. 보기 ➡보기 모델 ➡ 모델

   • 뷰에는 ViewModel에 대한 참조가 있지만 그 반대는 아닙니다.
   • ViewModel에는 모델에 대한 참조가 있지만 그 반대는 아닙니다.
   • 뷰는 모델을 참조하지 않으며 그 반대도 마찬가지입니다.

2. 컨트롤러를 사용하는 경우 SwiftUI 에서 설명한 대로 컨트롤러가 항상 필요한 것은 아니지만 컨트롤러는 Views 및 ViewModels에 대한 참조를 가질 수 있습니다 .

3. 데이터 바인딩 : ViewModel 속성에 대한 리스너를 만듭니다.

class CustomView: UIView {
  var viewModel = MyViewModel {
    didSet {
      self.color = viewModel.color
    }
  }

  convenience init(viewModel: MyViewModel) {
    self.viewModel = viewModel
  }
}


struct MyViewModel {
   var viewColor: UIColor {
      didSet {
         colorChanged?() // This is where the binding magic happens.
      }
   }

   var colorChanged: ((UIColor) -> Void)?
}


class MyViewController: UIViewController {

   let myViewModel = MyViewModel(viewColor: .green)
   let customView: CustomView!

   override func viewDidLoad() {
      super.viewDidLoad()

      // This is where the binder is assigned.
      myViewModel.colorChanged = { [weak self] color in 
        print("wow the color changed")
      }
      customView = CustomView(viewModel: myViewModel)
      self.view = customView
   }
}

설정의 차이점

1. 비즈니스 로직은 MVC 용 컨트롤러와 MVVM 용 ViewModel에 있습니다.
2. 이벤트는 MVC의 View에서 ViewModel로 직접 전달되는 반면 MVVM의 경우 View에서 ViewModel로 컨트롤러로 전달됩니다 (있는 경우).

일반적인 특징

1. MVVM과 MVC 모두 View가 메시지를 모델로 직접 보낼 수 없습니다.
2. 둘 다 모델이 있습니다.
3. 둘 다 전망이 있습니다.

MVVM의 장점

1. ViewModel은 비즈니스 로직을 보유하기 때문에 더 작은 콘크리트 객체이므로 단위 테스트가 용이합니다. 반면 MVC에서 비즈니스 로직은 ViewController에 있습니다. 모든 메소드와 리스너를 동시에 테스트하지 않고 뷰 컨트롤러의 단위 테스트가 종합적으로 안전하다는 것을 어떻게 믿을 수 있습니까? 단위 테스트 결과를 전적으로 신뢰할 수는 없습니다.
2. MVVM에서는 비즈니스 로직이 컨트롤러에서 원자 적 ViewModel 단위로 압축되기 때문에 ViewController의 크기가 줄어들어 ViewController 코드를보다 읽기 쉽게 만듭니다.

MVC의 장점

1. 컨트롤러 내에 비즈니스 로직을 제공하면 분기의 필요성이 줄어들어 비즈니스 로직을 ViewModels로 캡슐화하는 것보다 성능이 뛰어난 캐시에서 명령문이 실행될 가능성이 높습니다.
2. 비즈니스 로직을 한 곳에 제공하면 테스트가 필요하지 않은 간단한 응용 프로그램의 개발 프로세스를 가속화 할 수 있습니다. 언제 테스트가 필요하지 않은지 모르겠습니다.
3. ViewController에 비즈니스 로직을 제공하는 것은 새로운 개발자가 생각하기 쉽습니다.

실용적인 관점에서 MVC (Model-View-Controller)는 패턴입니다. 그러나 ASP.net MVC로 사용되는 MVC는 Entity Framework (EF) 및 "전동 도구"와 함께 사용하면 데이터베이스, 테이블 및 열을 웹 페이지로 가져 오는 매우 강력하고 부분적으로 자동화 된 방법입니다. CRUD 조작 또는 R (검색 또는 읽기) 조작 만 해당 적어도 MVVM을 사용하면서 View Models는 비즈니스 객체에 의존하는 모델과 상호 작용했습니다. 비즈니스 모델은 "수제"였으며 많은 노력을 기울인 후 EF가 제공하는 것만 큼 좋은 모델을 얻는 것이 운이 좋았습니다. 상자 " 실용적인 프로그래밍 관점에서 볼 때 MVC는 많은 유틸리티를 기본적으로 제공하기 때문에 좋은 선택으로 보이지만 종소리가 추가 될 가능성이 여전히 있습니다.

주어진 많은 응답을 보완하기 위해 Modern client-side web 또는 Rich Web Application 관점에서 추가 관점을 추가하고 싶었습니다 .

사실 요즘 간단한 웹 사이트와 더 큰 웹 응용 프로그램은 일반적으로 Bootstrap과 같은 많은 인기있는 라이브러리로 구축됩니다. Steve Sanderson이 개발 한 Knockout 은 MVVM 패턴을 지원하여 패턴에서 가장 중요한 동작 중 하나 인 뷰 모델을 통한 데이터 바인딩을 모방합니다. 약간의 JavaScript data-bind를 사용하면 Bootstrap의 많은 기능을 사용하는 것과 유사한 간단한 HTML 속성 으로 페이지 요소에 추가 할 수있는 데이터 및 논리를 구현할 수 있습니다 . 이 두 라이브러리만으로도 대화 형 컨텐츠를 제공합니다. 라우팅과 결합 할 경우이 단일 페이지 응용 프로그램 을 작성하는 간단하면서도 강력한 접근 방식을 얻을 수 있습니다 .

마찬가지로 Angular 와 같은 최신 클라이언트 측 프레임 워크 는 규칙에 따라 MVC 패턴을 따르지만 서비스를 추가합니다. 흥미롭게도 MVW (Model-View-Whatever)로 선전됩니다. ( 스택 오버플로 에서이 게시물을 참조하십시오 .)

또한 Angular 2와 같은 프로그레시브 웹 프레임 워크 가 등장함에 따라 용어 및 구성 요소가보기 또는 템플릿으로 구성되고 서비스와 상호 작용하는 새로운 아키텍처 패턴이 변경되는 것을 볼 수 있습니다. 구성 단위; 일련의 모듈이 응용 프로그램을 구성합니다.

나는 MVC와 MVVM이 동일하다고 생각했었다. 플럭스가 존재하기 때문에 차이점을 알 수 있습니다.

MVC에서는 앱의 각 뷰마다 모델과 컨트롤러가 있으므로 뷰, 뷰 모델, 뷰 컨트롤러라고 부릅니다. 패턴은 한 뷰가 다른 뷰와 통신 할 수있는 방법을 알려주지 않습니다. 따라서 다른 프레임 워크에는 다른 구현이 있습니다. 예를 들어 컨트롤러가 서로 통신하는 구현이 있지만 다른 구현에는 컨트롤러 사이를 중재하는 다른 구성 요소가 있습니다. 뷰 모델이 서로 통신하는 구현도 있습니다. 뷰 모델은 뷰 컨트롤러에서만 액세스해야하기 때문에 MVC 패턴이 중단되었습니다.

MVVM에는 각 구성 요소에 대한 뷰 모델도 있습니다. 이 패턴은 뷰가 뷰 모델에 미치는 영향을 지정하지 않으므로 일반적으로 대부분의 프레임 워크는 뷰 모델에 컨트롤러의 기능 만 포함합니다. 그러나 MVVM은 뷰 모델의 데이터가 특정 뷰에 대해 알지 못하거나 사용자 정의하지 않은 전체 모델 인 모델에서 가져와야한다고 알려줍니다.

차이점을 설명하기 위해 Flux 패턴을 사용하겠습니다. 플럭스 패턴은 앱의 다른 뷰가 어떻게 통신해야하는지 알려줍니다. 각보기는 상점을 청취하고 디스패처를 사용하여 조치를 실행합니다. 디스패처는 모든 상점에 방금 수행 한 조치에 대해 알리고 상점은 자체적으로 갱신합니다. Flux의 상점은 MVVM의 (일반) 모델에 해당합니다. 특정보기에 관습이 아닙니다. 따라서 일반적으로 사람들이 React와 Flux를 사용하는 경우 각 React 구성 요소는 실제로 MVVM 패턴을 구현합니다. 조치가 발생하면 뷰 모델이 디스패처를 호출하고 마지막으로 상점의 변경 사항 (모델)에 따라 업데이트됩니다. MVC에서는 컨트롤러 만보기 모델을 업데이트 할 수 있기 때문에 각 구성 요소가 MVC를 구현한다고 말할 수는 없습니다.

mvc는 서버 측이고 mvvm은 웹 개발에서 클라이언트 측 (브라우저)입니다.

대부분의 경우 javascript는 브라우저에서 mvvm에 사용됩니다. mvc에는 많은 서버 측 기술이 있습니다.

간단히 말해서 MVC에서 Controler는 (제어)보기를 알고 있지만 MVVM에서는 ViewModel이 누가 그것을 소비하는지 알지 못합니다. ViewModel은 관찰 가능한 속성과 작업을 사용하려는 사람에게 노출시킵니다. ViewModel 내에 UI에 대한 참조가 없기 때문에 테스트가 더 쉬워집니다.

Model–View–Controller (보통 MVC 라고 함 )는 관련 프로그램 논리를 3 개의 상호 연결된 요소로 나누는 사용자 인터페이스를 개발하는 데 일반적으로 사용되는 소프트웨어 디자인 패턴입니다. 이것은 정보가 사용자에게 제시되고 수용되는 방식과 정보의 내부 표현을 분리하기 위해 수행됩니다. MVC 아키텍처 패턴에 따라 이러한 주요 구성 요소가 분리되어 코드 재사용 및 병렬 개발이 가능합니다.

일반적으로 데스크탑 그래픽 사용자 인터페이스 (GUI)에 사용되는이 패턴은 웹 응용 프로그램 설계에 널리 사용됩니다. JavaScript, Python, Ruby, PHP, Java 및 C #과 같은 널리 사용되는 프로그래밍 언어에는 웹 응용 프로그램 개발에 즉시 사용되는 MVC 프레임 워크가 있습니다.

모델

패턴의 중심 구성 요소. 사용자 인터페이스와 무관하게 응용 프로그램의 동적 데이터 구조입니다. 응용 프로그램의 데이터, 논리 및 규칙을 직접 관리합니다.

전망

차트, 다이어그램 또는 테이블과 같은 정보 표현 관리를위한 막대 도표 및 회계사를위한 표 형식보기와 같은 동일한 정보의 여러보기가 가능합니다.

제어 장치

입력을 승인하고이를 모델 또는 뷰의 명령으로 변환합니다.

응용 프로그램을 이러한 구성 요소로 나누는 것 외에도 모델 뷰 컨트롤러 디자인은 이들 간의 상호 작용을 정의합니다.

모델은 응용 프로그램의 데이터를 관리합니다. 컨트롤러에서 사용자 입력을받습니다.

보기는 특정 형식의 모델 표시를 의미합니다.

제어기는 사용자 입력에 응답하고 데이터 모델 오브젝트에서 상호 작용을 수행합니다. 컨트롤러는 입력을 수신하고 선택적으로 입력을 확인한 다음 입력을 모델로 전달합니다.

MVVM ( Model–View–ViewModel )은 소프트웨어 아키텍처 패턴입니다.

MVVM을 사용하면 비즈니스 로직 또는 백엔드 로직 (데이터 모델)의 개발에서 그래픽 사용자 인터페이스 (마크 업 언어 또는 GUI 코드를 통해)를 쉽게 분리 할 수 ​​있습니다. MVVM의 뷰 모델은 값 변환기입니다. 즉, 뷰 모델은 객체를 쉽게 관리하고 표시하는 방식으로 모델에서 데이터 객체를 노출 (변환)해야합니다. 이와 관련하여, 뷰 모델은 뷰보다 더 많은 모델이며 모든 뷰의 디스플레이 로직이 아니라면 대부분을 처리합니다. 뷰 모델은 뷰에 의해 지원되는 일련의 사용 사례들에 대한 백엔드 로직에 대한 액세스를 구성하는 중개자 패턴을 구현할 수있다.

MVVM은 Martin Fowler의 프레젠테이션 모델 디자인 패턴의 변형입니다. MVVM은 동일한 방식으로 뷰의 상태와 동작을 추상화하지만 프레젠테이션 모델은 특정 사용자 인터페이스 플랫폼에 의존하지 않는 방식으로 뷰를 추상화합니다 (뷰 모델 생성).

MVVM은 Microsoft 건축가 Ken Cooper와 Ted Peters가 특별히 사용자 중심의 이벤트 중심 프로그래밍을 단순화하기 위해 개발되었습니다. 이 패턴은 WPF (Windows Presentation Foundation) (Microsoft의 .NET 그래픽 시스템) 및 Silverlight (WPF의 인터넷 응용 프로그램 파생)에 통합되었습니다. Microsoft의 WPF 및 Silverlight 설계자 중 하나 인 John Gossman은 2005 년 자신의 블로그에서 MVVM을 발표했습니다.

Model-View–ViewModel은 특히 .NET 플랫폼과 관련이없는 구현에서는 모델-뷰-바인더라고도합니다. ZK (Java로 작성된 웹 응용 프로그램 프레임 워크)와 KnockoutJS (JavaScript 라이브러리)는 model-view-binder를 사용합니다.