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

질문자 :Bjorn Reppen

폐쇄 . 이 질문은 더 집중할 필요가 있습니다. 현재 답변을 받고 있지 않습니다.

---

이 질문을 개선하고 싶으십니까? 이 게시물 을 편집 하여 하나 의 문제 에만 초점 을 맞추도록 질문 을 업데이트 하십시오 .

폐쇄 1 년 전 .

이 질문 개선

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

지금까지 본 ViewModel 패턴의 주요 이점은 XAML 코드 숨김에서 코드를 제거 하여 XAML 편집을 보다 독립적인 작업으로 만드는 것 입니다. 우리는 여전히 필요할 때 애플리케이션의 전체 로직을 제어하기 위해 컨트롤러를 생성합니다.

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

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

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

컨트롤러가 뷰 모델에 의해 더 이상 사용되지 않는다고 가정하지 마십시오.

이 주제에 대한 블로그를 시작했습니다. 이 블로그는 가능한 한 추가할 예정입니다(호스팅이 손실된 경우에만 보관) . 대부분의 탐색 시스템은 보기와 VM만 사용하기 때문에 MVCVM을 일반 탐색 시스템과 결합하는 데 문제가 있지만 이후 기사에서 이에 대해 설명하겠습니다.

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

참고: 이 게시물은 여러 번 편집되었으며 특별히 제한된 질문을 대상으로 하지 않았으므로 이제 첫 번째 부분을 업데이트하여 이 부분도 포함하도록 했습니다. 아래 주석에서 논의의 대부분은 ASP.Net에만 관련되며 더 넓은 그림은 아닙니다. 이 게시물은 Silverlight, WPF 및 ASP.Net에서 MVVM의 광범위한 사용을 다루고 사람들이 컨트롤러를 ViewModel로 교체하지 않도록 하기 위한 것입니다.

Gone Coding

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

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

이 웹 항목의 한 가지 기능을 오늘날과 같이 유지합니다. JavaScript가 천박하고 비열한 성가심이었던 10년 전과 마찬가지로 실제 프로그래머는 이를 피하는 것이 좋습니다. HTML 페이지는 본질적으로 멍청하고 수동적입니다. . 브라우저는 씬 클라이언트이거나 원하는 경우 열악한 클라이언트입니다. 브라우저에는 인텔리전스가 없습니다. 전체 페이지 새로고침 규칙. »view«는 매번 새로 생성됩니다.

이 웹 방식은 모든 분노에도 불구하고 데스크탑에 비해 끔찍하게 후진적이라는 것을 기억합시다. 데스크톱 앱은 원하는 경우 팻 클라이언트 또는 리치 클라이언트입니다. (Microsoft Word와 같은 프로그램도 일종의 클라이언트, 문서용 클라이언트로 생각할 수 있습니다.) 그들은 인텔리전스와 데이터에 대한 지식으로 가득한 클라이언트입니다. 그들은 상태를 유지합니다. 처리 중인 데이터를 메모리에서 캐시합니다. 전체 페이지를 새로고침하는 것과 같은 쓰레기는 없습니다.

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

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

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

개인적으로 저는 이 이론과 약어 비즈니스가 구체적인 현실에서 무엇을 말하는지 보면 이해하기 더 쉽다고 생각합니다. 추상적인 개념은 특히 구체적인 문제에 대해 설명할 때 유용하므로 완전히 이해할 수 있습니다.

Lumi

MVVM Model-View ViewModel 은 MVC, Model-View 컨트롤러 와 유사합니다.

컨트롤러 는 ViewModel 로 대체됩니다. ViewModel은 UI 레이어 아래에 있습니다. ViewModel은 뷰에 필요한 데이터 및 명령 개체를 노출합니다. 뷰가 데이터와 작업을 가져오기 위해 이동하는 컨테이너 개체로 생각할 수 있습니다. ViewModel은 모델에서 데이터를 가져옵니다.

Russel East 는 MVVM이 MVC와 다른 이유 에 대해 자세히 논의하는 블로그를 운영합니다.

TStamper

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

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

Chris Ballance

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

다음은 중요한 섹션입니다.

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

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

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

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

Mat

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

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

George R

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

통제된 환경에서는 코드가 적고 논리의 공통 소스가 있어야 합니다. 항상 컨트롤러 내에 있어야 합니다. 하지만; 웹 세계에서 MVC는 보기 생성 논리와 보기 동적 논리로 쉽게 나뉩니다. 생성은 서버에 있고 동적은 클라이언트에 있습니다. AngularJS와 결합된 ASP.NET MVC에서 이것을 많이 볼 수 있지만 서버는 보기를 만들고 모델을 전달하고 클라이언트로 보냅니다. 그런 다음 클라이언트는 View와 상호 작용하며 이 경우 AngularJS가 로컬 컨트롤러로 참여합니다. 제출된 모델 또는 새 모델은 서버 컨트롤러로 다시 전달되어 처리됩니다. (따라서 주기가 계속되고 소켓이나 AJAX 등으로 작업할 때 이 처리에 대한 많은 다른 번역이 있지만 전체 아키텍처는 동일합니다.)

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

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

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

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

이 모든 것은 아마도 각각의 아키텍처에 대해 적어도 약간 익숙하지 않고 그물에서 많은 나쁜 정보를 찾을 수 있으므로 매우 혼란스러울 수 있다는 것을 배우는 경우 전혀 의미가 없습니다.

그래서... 이것을 올바르게 하기 위해 염두에 두어야 할 사항. 애플리케이션을 어떻게 디자인할지 미리 결정하고 이를 고수하십시오.

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

당신이 MVVM을 한다면, 나는 당신의 친절한 영혼을 축복하지만 시간을 들여 올바르게 하십시오! 하나의 인터페이스를 사용하지 마십시오. View가 값에 따라 어떻게 보일지 결정하게 하십시오. View with Mock 데이터로 플레이하세요. 그 당시에 원하지 않았음에도 불구하고 메뉴를 표시하는 보기(예제에 따름)를 갖게 되면 GOOD입니다. 당신의 견해는 제대로 작동하고 있어야 할 가치에 따라 반응하고 있습니다. ViewModel이 특정 번역 상태에 있을 때 이러한 일이 발생하지 않도록 트리거에 몇 가지 요구 사항을 더 추가하거나 ViewModel에 이 상태를 비우라고 명령하세요. ViewModel에서 View에서 볼 것인지 여부를 결정하는 것처럼 내부 논리로 이것을 제거하지 마십시오. ViewModel에 메뉴가 있다고 가정할 수 없음을 기억하십시오. 마지막으로 Model은 상태를 변경하고 저장할 수 있도록 허용해야 합니다. 여기에서 유효성 검사와 모든 작업이 수행됩니다. 예를 들어, 모델이 상태를 수정할 수 없으면 단순히 자신을 더럽거나 다른 것으로 플래그 지정합니다. ViewModel이 이것을 인식하면 더러운 것을 번역하고 View는 이것을 인식하고 다른 트리거를 통해 일부 정보를 표시합니다. View의 모든 데이터는 ViewModel에 바인딩될 수 있으므로 모든 것이 Model만 동적으로 될 수 있으며 ViewModel은 View가 바인딩에 어떻게 반응할지 전혀 모릅니다. 사실 Model은 ViewModel에 대한 개념이 없습니다. 종속성을 설정할 때 View → ViewModel → Model 과 같이 가리켜야 합니다. (여기에 참고 사항도 있습니다. 이 또한 논쟁이 될 것입니다. 하지만 저는 상관하지 않습니다... 모델을 다음으로 전달하지 마십시오. 그 MODEL이 불변하지 않는 한 VIEW; 그렇지 않으면 적절한 ViewModel로 포장하십시오. View는 모델 기간을 볼 수 없습니다. 나는 쥐에게 당신이 본 데모 또는 수행한 방법을 알려줍니다. 그것은 잘못된 것입니다.)

여기 내 마지막 팁이 있습니다. 잘 설계되었지만 매우 간단한 MVC 응용 프로그램을 살펴보고 MVVM 응용 프로그램에 대해서도 동일한 작업을 수행하십시오. 하나는 유연성이 0으로 제한되어 더 많은 제어 권한을 갖는 반면 다른 하나는 제어 권한이 없고 무한한 유연성을 갖습니다.

제어된 환경은 컨트롤러 세트 또는 (단일 소스)에서 전체 애플리케이션을 관리하는 데 적합하지만 반응 환경은 나머지 애플리케이션이 수행하는 작업을 전혀 모르는 상태에서 별도의 리포지토리로 분할될 수 있습니다. 마이크로 관리 vs 무료 관리.

내가 당신을 충분히 혼란스럽게 하지 않았다면 저에게 연락해 보십시오... 나는 삽화와 예를 통해 이것을 자세히 살펴보는 것을 꺼려하지 않습니다.

하루가 끝나면 우리는 모두 프로그래머이고 코딩할 때 그 무정부 상태가 우리 안에 살고 있습니다... 따라서 규칙이 깨지고 이론이 바뀌고 이 모든 것이 결국 헛수고로 끝날 것입니다... 하지만 대규모 작업을 할 때 프로젝트 및 대규모 팀에서 디자인 패턴에 동의하고 적용하는 것이 정말 도움이 됩니다. 언젠가는 처음에 취한 작은 추가 조치가 나중에 저축의 도약과 한계가 될 것입니다.

Michael Puckett II

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

MVC (모델 뷰 컨트롤러)

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

MVVM (모델 보기 보기 모델)

뷰 모델 :

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

Pritam Banerjee

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

위의 내용을 조금 더 설명하기 위해 MVVM, MVP 및 MVC를 포함하는 이 시나리오를 만들었습니다. 이야기는 사용자가 영화 검색 앱에서 '찾기' 버튼을 클릭하는 것으로 시작됩니다…

사용자: 클릭 …

보기 : 누구세요? [ MVVM|MVP|MVC ]

사용자: 방금 검색 버튼을 눌렀습니다...

보기 : 알겠습니다. 잠시만요. . . . [ MVVM|MVP|MVC ]

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

보기 : 안녕하세요 ViewModel | 발표자 | 컨트롤러 , 사용자가 방금 검색 버튼을 클릭했습니다. 어떻게 해야 합니까? [ MVVM|MVP|MVC ]

뷰모델 | 발표자 | 컨트롤러 : Hey View , 그 페이지에 검색어가 있습니까? [ MVVM|MVP|MVC ]

보기 : 네… 여기 있습니다… “피아노” [ MVVM|MVP|MVC ]

—— 이것은 MVVM 과 MVP 의 가장 중요한 차이점입니다 | MVC ———

발표자 | Controller : Thank You View ,… 그동안 모델 에서 검색어를 찾는 중입니다. 진행률 표시줄을 보여주세요. [ MVP | MVC ]

( 발표자 | 컨트롤러 가 모델을 호출하고 있습니다 ... ) [ MVP | MVC ]

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

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

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

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

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

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

( 잠시 후 … )

———— 이것은 MVVM , MVP 및 MVC 사이의 분기점입니다 ————–

Model : 당신을 위한 목록을 찾았습니다, 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 를 기다려 주셔서 감사합니다. Model에게 귀하의 검색어에 대해 문의했습니다. 일치하는 결과 목록을 찾아 인스턴스 내부의 "searchResultsList"라는 변수에 저장했다고 말합니다. 거기에서 얻을 수 있습니다. 또한 지금 진행률 표시줄을 숨기십시오 [ MVC ]

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

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

View : 감사합니다 " Controller " [ MVC ] (이제 View 는 스스로에게 질문을 하고 있습니다. Model 에서 얻은 결과를 사용자에게 어떻게 제시해야 할까요? 영화의 제작 연도가 처음이 되어야 할까요 아니면 마지막이 되어야 할까요...?)

보기 : 오, searchResultsListObservable에 새로운 트리거가 있습니다 … 결과를 얻었으니 진행률 표시줄도 숨겨야 합니다. [ MVVM ]

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

Ali Nem

MVVM은 프레젠테이션 모델 패턴의 개선(논쟁의 여지가 있음)입니다. WPF가 데이터 바인딩 및 명령 처리를 수행하는 기능을 제공하는 방법에 유일한 차이점이 있기 때문에 논쟁의 여지가 있다고 말합니다.

wekempf

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

MVC로 작업한 적이 있다면, 예를 들어 일부 편집 대화 상자를 표시하거나 숨기기 위해 뷰의 상태를 반영하는 모델 객체를 생성하는 것이 유용하다는 것을 알게 되었을 것입니다. 이 경우 뷰 모델을 사용하고 있습니다.

MVVM 패턴은 단순히 모든 UI 요소에 대한 관행을 일반화한 것입니다.

그리고 이것은 Microsoft 패턴이 아니며 WPF/Silverlight 데이터 바인딩이 이 패턴과 함께 작동하는 데 특히 적합하다는 점을 추가합니다. 그러나 예를 들어 자바 서버 페이스와 함께 사용하는 것을 막는 것은 없습니다.

DaniCE

이것이 MVVM 의 기원 을 언급하지 않고 투표율이 높은 답변이라는 사실에 놀랐습니다. MVVM 은 Microsoft 커뮤니티에서 널리 사용되는 용어로 Martin Fowler의 Presentation Model 에서 유래 되었습니다. 따라서 패턴의 동기와 다른 것들과의 차이점을 이해하기 위해서는 패턴에 대한 원본 기사를 가장 먼저 읽어야 합니다.

Cheng

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

1. 컨트롤러는 ViewModel을 새로 만들고 이를 View에 주입하는 역할을 합니다. (요청을 받기 위해)
2. ViewModel은 마지막으로 선택한 항목 등과 같은 DataContext 및 보기 상태에 대한 컨테이너입니다.
3. 모델은 DB 엔터티를 포함하며 쿼리 및 필터링을 수행하는 DB 스키마에 매우 가깝습니다. (나는 이것을 위해 EF와 LINQ를 좋아한다)
4. 모델은 또한 리포지토리 및/또는 결과를 강력한 유형으로 프로젝션하는 것을 고려해야 합니다(EF에는 훌륭한 방법이 있습니다... EF.Database.Select(querystring, parms) 쿼리를 삽입하고 강력한 유형을 되돌리기 위한 직접적인 ADO 액세스를 위해 이것은 EF를 해결합니다. 는 느린 인수입니다. EF 는 느리지 않습니다!
5. ViewModel은 데이터를 가져오고 비즈니스 규칙 및 유효성 검사를 수행합니다.
6. 포스트백의 컨트롤러는 ViewModel Post 메서드를 호출하고 결과를 기다립니다.
7. 컨트롤러는 새로 업데이트된 Viewmodel을 View에 주입합니다. 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); }

위의 이 actionmethod가 의도한 대로 작동하려면 게시물에 반환되지 않은 항목을 초기화하는 null CTOR가 정의되어 있어야 합니다. 포스트백은 변경된 항목에 대한 이름/값 쌍도 다시 게시해야 합니다. 누락된 이름/값 쌍이 있는 경우 MVC 바인딩 엔진은 단순히 아무것도 아닌 적절한 작업을 수행합니다! 이런 일이 발생하면 "포스트백에서 데이터가 손실됩니다"라고 말할 수 있습니다...

이 패턴의 장점은 ViewModel이 모델/비즈니스 로직과 인터페이스하는 모든 "클러터" 작업을 수행하고 컨트롤러는 일종의 라우터일 뿐이라는 것입니다. 작동 중인 SOC입니다.

JWP

MVVM은 보기 모델을 믹스에 추가합니다. 이는 일반 모델에 UI 특정 부분을 모두 넣지 않고도 WPF의 많은 바인딩 접근 방식을 사용할 수 있게 해주기 때문에 중요합니다.

내가 틀릴 수도 있지만 MVVM이 실제로 컨트롤러를 믹스에 강제로 적용하는지 확신할 수 없습니다. 나는 개념이 http://martinfowler.com/eaaDev/PresentationModel.html 과 더 일치한다는 것을 알았습니다. 사람들은 MVC가 패턴에 내장되어 있는 것이 아니라 MVC와 결합하기를 선택한다고 생각합니다.

eglasius

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

se_thoughts

MVVM

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

• 보기에는 ViewModel에 대한 참조가 있지만 그 반대의 경우는 없습니다.
• ViewModel에는 모델에 대한 참조가 있지만 그 반대는 없습니다.
• 보기에는 모델에 대한 참조가 없으며 그 반대의 경우도 마찬가지입니다.

2. 컨트롤러를 사용하는 경우 Views 및 ViewModels 에 대한 참조를 가질 수 있지만 SwiftUI 에서 설명한 것처럼 컨트롤러가 항상 필요한 것은 아닙니다.
3. 데이터 바인딩 : ViewModel 속성에 대한 리스너를 생성하여 데이터가 뷰 모델을 통해 뷰에서 모델로 흐를 수 있도록 합니다. 참조는 View ➡ ViewModel ➡ Model과 같은 한 방향으로 가는 반면 데이터는 View ↔ ViewModel ↔ Model로 이동해야 합니다. 뷰가 자체 속성을 읽어 모델에서 데이터를 가져오는 방법이 명확합니다. 데이터 바인딩은 뷰 내에서 이벤트를 감지하고 모델에 다시 피드백하는 방법입니다.

 class CustomView: UIView { var viewModel = MyViewModel { didSet { self.color = viewModel.viewColor } } 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용 ViewModels에 보관됩니다.
2. 이벤트는 MVC의 View에서 컨트롤러로 직접 전달되는 반면 이벤트는 View에서 ViewModel로 MVVM용 컨트롤러(있는 경우)로 전달됩니다.

일반적인 특징

1. MVVM과 MVC 모두 View가 모델에 직접 메시지를 보내는 것을 허용하지 않습니다.
2. 둘 다 모델이 있습니다.
3. 둘 다 전망이 있습니다.

MVVM의 장점

1. ViewModel은 비즈니스 로직을 보유하고 있기 때문에 더 작은 구체적인 개체를 사용하여 단위 테스트를 쉽게 수행할 수 있습니다. 반면 MVC에서 비즈니스 로직은 ViewController에 있습니다. 모든 메소드와 리스너를 동시에 테스트하지 않고 뷰 컨트롤러의 단위 테스트가 포괄적으로 안전하다고 어떻게 믿을 수 있습니까? 단위 테스트 결과를 완전히 신뢰할 수는 없습니다.
2. MVVM에서는 비즈니스 로직이 컨트롤러에서 원자적 ViewModel 단위로 빠져나가기 때문에 ViewController의 크기가 줄어들고 ViewController 코드를 더 읽기 쉽게 만듭니다.

MVC의 장점

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

ScottyBlades

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

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

Rinat Galyautdinov

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

MVVMC는 내 겸손한 생각에 정확한 이름입니다.

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

Ini

MVVMC 또는 아마도 MVC+는 엔터프라이즈 및 신속한 애플리케이션 개발을 위한 실행 가능한 접근 방식인 것 같습니다. UI를 비즈니스 및 상호 작용 논리에서 분리하는 것이 좋지만 '순수한' MVVM 패턴과 대부분의 사용 가능한 예제는 단일 보기에서 가장 잘 작동합니다.

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

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

der Martin

간단히 말해서 MVC에서 컨트롤러는 (제어) 보기를 알고 있는 반면 MVVM에서 ViewModel은 누가 그것을 소비하는지 알지 못합니다. ViewModel은 관찰 가능한 속성과 작업을 사용에 관심이 있는 사람에게 공개합니다. 그 사실은 ViewModel 내에서 UI에 대한 참조가 없기 때문에 테스트를 더 쉽게 만듭니다.

daneejela

실용적인 관점에서 MVC(Model-View-Controller)는 패턴입니다. 그러나 ASP.net MVC로 사용될 때 MVC는 Entity Framework(EF) 및 "파워 도구"와 결합될 때 데이터베이스, 테이블 및 열을 웹 페이지로 가져오기 위한 매우 강력하고 부분적으로 자동화된 접근 방식입니다. CRUD 작업 또는 R(검색 또는 읽기) 작업만 해당됩니다. 적어도 내가 MVVM을 사용할 때 View Models는 비즈니스 개체에 의존하는 모델과 상호 작용했으며, 이 모델은 차례로 "수제"였으며 많은 노력 끝에 운이 좋게도 EF가 제공한 것만큼 좋은 모델을 얻을 수 있었습니다. -of-box". 실용적인 프로그래밍 관점에서 MVC는 기본적으로 많은 유틸리티를 제공하기 때문에 좋은 선택처럼 보이지만 여전히 추가될 가능성이 있습니다.

JosephDoggie

주어진 많은 응답을 보완하기 위해 모던 클라이언트 측 웹 또는 리치 웹 애플리케이션 관점에서 몇 가지 추가 관점을 추가하고 싶었습니다.

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

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

또한 Angular 2와 같은 프로그레시브 웹 프레임워크의 등장으로 용어가 변경되고 구성 요소가 보기 또는 템플릿으로 구성되고 서비스와 상호 작용하는 새로운 아키텍처 패턴이 나타날 수 있습니다. 기준 치수; 일련의 모듈이 애플리케이션을 구성합니다.

Richard Nalezynski

나는 MVC와 MVVM이 같은 것이라고 생각하곤 했다. 이제 Flux가 있기 때문에 차이점을 알 수 있습니다.

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

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

차이점을 보여주기 위해 Flux 패턴을 살펴보겠습니다. Flux 패턴은 앱의 다양한 뷰가 통신해야 하는 방식을 알려줍니다. 각 보기는 상점을 수신하고 디스패처를 사용하여 작업을 실행합니다. 디스패처는 차례로 모든 상점에 방금 수행한 작업에 대해 알리고 상점은 스스로 업데이트합니다. Flux의 저장소는 MVVM의 (일반) 모델에 해당합니다. 특정 보기에 대한 사용자 정의가 아닙니다. 따라서 일반적으로 사람들이 React와 Flux를 사용할 때 각 React 구성 요소는 실제로 MVVM 패턴을 구현합니다. 액션이 발생하면 뷰 모델이 디스패처를 호출하고 마지막으로 모델인 스토어의 변경 사항에 따라 업데이트됩니다. MVC에서는 컨트롤러만 뷰 모델을 업데이트할 수 있기 때문에 각 구성 요소가 MVC를 구현한다고 말할 수 없습니다. 따라서 MVVM은 Flux와 함께 작동할 수 있지만(MVVM은 보기와 보기 모델 간의 통신을 처리하고 Flux는 서로 다른 보기 간의 통신을 처리합니다) MVC는 핵심 원칙을 위반하지 않고는 Flux와 함께 작동할 수 없습니다.

Alon

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

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

Maulik

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 플랫폼을 포함하지 않는 구현에서 model-view-binder라고도 합니다. ZK(Java로 작성된 웹 애플리케이션 프레임워크) 및 KnockoutJS(JavaScript 라이브러리)는 model-view-binder를 사용합니다.

Rahul

출처 : http:www.stackoverflow.com/questions/667781/what-is-the-difference-between-mvc-and-mvvm