[model-view-controller] MVC와 MVVM의 차이점은 무엇입니까?


9 Answers

이 약자들이 의미하는 바를 이해하는 가장 쉬운 방법은 잠시 그들을 잊어 버리는 것입니다. 대신, 그들과 함께 시작된 소프트웨어에 대해 생각해보십시오. 그것은 초기 웹과 데스크톱의 차이점으로 귀결됩니다.

MVC라는 첫 번째 약어는 웹에서 유래했습니다. (네, 예전에는 웹에 있었을 지 모르지만 웹은 웹 개발자들에게 대중화 된 방법입니다.) 데이터베이스, HTML 페이지 및 코드를 생각해보십시오. MVC에 도착하기 위해 조금 더 세분화 해 봅시다.»데이터베이스«에 대해 데이터베이스와 인터페이스 코드를 가정 해 봅시다. »HTML 페이지«의 경우, HTML 템플릿과 템플릿 처리 코드를 가정 해 봅시다. 코드»in«에 대해 사용자 클릭을 작업에 매핑하는 코드를 가정 해 봅시다. 데이터베이스에 영향을 미쳐 다른보기가 분명히 표시되도록 할 수 있습니다. 최소한이 비교의 목적을 위해서입니다.

이 웹 사이트의 기능 중 하나는 오늘 그대로가 아니라 10 년 전에 Javascript가 저속하고 비열한 성가심이었을 때와 같이 실제 프로그래머가 잘 수행 한 HTML 페이지는 본질적으로 멍청하고 수동적입니다. . 브라우저는 씬 클라이언트이거나 가난한 클라이언트입니다. 브라우저에는 지능이 없습니다. 전체 페이지가 규칙을 다시로드합니다. »보기«는 매번 새로 생성됩니다.

이 웹 방식이 모든 분노에도 불구하고 데스크톱과 비교할 때 끔찍하게 뒤로 돌아간 것을 기억합시다. 원한다면 데스크톱 앱은 팻 클라이언트 또는 리치 클라이언트입니다. (마이크로 소프트 워드와 같은 프로그램이라 할지라도 클라이언트의 종류는 문서의 클라이언트라고 생각할 수 있습니다.) 이들은 정보에 대한 지식이 풍부하고 고객의 데이터에 대한 지식이 풍부합니다. 그들은 스테이트 풀어. 그들은 메모리에서 처리중인 데이터를 캐시합니다. 전체 페이지를 다시로드하는 것과 같은 쓰레기는 없습니다.

이 풍부한 데스크톱 방식은 아마 두 번째 약어가 시작된 MVVM입니다. 편지에 속지 마라. C.의 생략에 의해. 그들은 있어야합니다. 아무것도 제거되지 않습니다. 우리는 하나의 것을 추가합니다 : 상태 유지, 클라이언트에 캐시 된 데이터 (그리고 그 데이터를 처리하기위한 지능과 함께). 클라이언트의 캐시는 본질적으로»ViewModel이라고 불립니다. 풍부한 대화 형 기능을 제공합니다. 그리고 그게 다야.

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

플래시, 실버 라이트, 그리고 가장 중요한 것은 자바 스크립트인데, 웹은 MVVM을 채택했습니다. 브라우저는 더 이상 합법적으로 씬 클라이언트로 불릴 수 없습니다. 그들의 프로그램 가능성을보십시오. 메모리 소비량을 살펴보십시오. 현대 웹 페이지의 모든 자바 스크립트 상호 작용을 살펴보십시오.

개인적으로, 나는이 이론과 두문자어 사업이 구체적 현실에서 언급하고있는 것을 보아서 더 쉽게 이해할 수 있다고 본다. 추상적 인 개념은 특히 구체적인 문제에 대해 시연 할 때 유용합니다. 따라서 이해는 완전한 원으로 나타날 수 있습니다.

Question

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




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

MVC (모델 뷰 컨트롤러)

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

MVVM (모델 뷰 뷰 모델)

ViewModel :

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



It surprises me that this is a highly voted answers without mentioning the origin of MVVM. MVVM is a popular term used in Microsoft community and it is originated from Martin Fowler's Presentation Model . So to understand the motive of the pattern and the differences with others, the original article about the pattern is the first thing to read.




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

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

MVVM은 반응적인 환경으로 어떤 이벤트를 기반으로 활성화되는 코드 (예 : 트리거)를 작성하는 것을 의미합니다. MVVM이 번창하는 XAML에서는 내장 된 데이터 바인딩 프레임 워크를 사용하여 모든 작업을 쉽게 처리 할 수 ​​있지만 프로그래밍 언어가있는 모든 뷰에서 모든 시스템에서 작동합니다. MS 특유의 것이 아닙니다. ViewModel이 실행되면 (일반적으로 속성이 변경된 이벤트) 뷰는 사용자가 만든 트리거에 따라 반응합니다. 이것은 기술적으로 얻을 수 있지만 최종선은 무국적이며 논리가없는 것입니다. 단순히 값을 기반으로 상태를 변경합니다. 또한, ViewModel은 매우 적은 로직으로 상태 비 저장되며 모델은 상태를 유지해야하기 때문에 본질적으로 제로 로직을 가진 상태입니다. 필자는이를 응용 프로그램 상태 (모델), 상태 변환기 (ViewModel), 시각적 상태 / 상호 작용 (보기)으로 설명합니다.

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

MVVM은 완전히 반응 적이기 때문에 개인적으로 가장 좋아합니다. 모델이 상태를 변경하면 ViewModel은 해당 상태를 수신하고 변환합니다. 그러면 View는 상태 변경을 위해 ViewModel을 청취하며 ViewModel의 변환을 기반으로 업데이트합니다. 어떤 사람들은 MVVM을 순수 MVVM이라고 부르지 만 실제로는 오직 하나뿐입니다. 논쟁하는 방식에 상관 없으며 View가 절대적으로 논리가없는 순수한 MVVM입니다.

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

이 모든 것들은 아마도 각각의 아키텍처에 익숙하지 않고 넷에 대한 나쁜 정보를 찾을 때 혼란 스러울 수 있습니다.

그래서 ...이 권리를 얻기 위해 명심해야 할 것들. 응용 프로그램을 디자인하고 IT에 손을 대는 방법을 정면으로 결정하십시오.

위대한 MVC를한다면 Controller가 관리 가능하고 View를 완전히 제어 할 수 있는지 확인하십시오. 보기가 큰 경우 다른 컨트롤러가있는보기에보기를 추가하는 것을 고려하십시오. 해당 컨트롤러를 다른 컨트롤러로 케스케이드하지 마십시오. 유지하기가 매우 힘듭니다. 잠시 시간을내어 별도의 구성 요소로 작동하는 방식으로 개별적으로 설계하십시오. 그리고 항상 컨트롤러가 모델에 모델을 저장 또는 유지하도록 지시하십시오. MVC에 대한 이상적인 의존성 설정은 View ← Controller → Model 또는 ASP.NET (시작하지 마세요)입니다 Model ← View ↔ Controller → Model (Model은 Controller와 View간에 동일하거나 완전히 다른 모델 일 수 있습니다) ... 물론이 시점에서 View의 Controller에 대해 알아야 할 필요가있는 점은 주로 모델을 통과 할 지점을 알기위한 엔드 포인트 참조입니다.

MVVM을 할 경우, 나는 당신의 친절한 영혼을 축복하지만, 그럴 권리가 있습니다! 인터페이스를 사용하지 마십시오. 보기를 통해 가치에 따라 어떻게 보이는지 결정하십시오. View with Mock 데이터로보기. 당신이 그때 그때 그것을 원하지 않았더라도 당신에게 메뉴를 보여주고있는 View를 갖게된다면 (예제에 따라) GOOD. 당신은해야하는대로 가치가 있다고 생각하는대로 행동하고 있습니다. 트리거에 몇 가지 요구 사항을 추가하여 ViewModel이 특정 번역 된 상태에 있거나 ViewModel에이 상태를 비우라고 명령 할 때 발생하지 않도록하십시오. ViewModel에서 내부 논리를 사용하여보기를 볼 것인지 여부를 결정하는 것처럼 이것을 제거하지 마십시오. ViewModel에 메뉴가 있는지 여부는 추측 할 수 없습니다. 마지막으로, 모델은 단지 사용자가 변경하고 대부분의 상점 상태를 유지하도록 허용해야합니다. 이것이 유효성 확인과 모두가 일어날 곳입니다. 예를 들어, 모델이 상태를 수정할 수 없다면 단순히 더티 (dirty) 또는 무언가로 표시됩니다. ViewModel이 이것을 깨달을 때 더러운 것을 번역 할 것이고 View는이를 인식하고 다른 트리거를 통해 정보를 보여줄 것입니다. View의 모든 데이터는 ViewModel에 바인딩 될 수 있으므로 모든 것이 동적 일 수 있습니다. Model과 ViewModel은 View가 바인딩에 어떻게 반응하는지 전혀 알지 못합니다. 사실 Model은 ViewModel에 대해서 전혀 모른다. 의존성을 설정할 때 그들은 그렇게 가리켜 야하고 View → ViewModel → Model (그리고 여기에 사이드 노트가있다.) 그리고 이것은 아마도 논쟁을 불러 일으킬 것이다. 그러나 나는 상관하지 않는다. 모델에 패스하지 마라. VIEW 뷰는 모델 기간을 보지 않아야합니다. 나는 쥐가 당신이 본 데모 또는 당신이 그것을 한 방법에 해를 끼치 지요. 그건 잘못된 것입니다.)

마지막 팁은 다음과 같습니다. 잘 설계되었지만 매우 단순한 MVC 애플리케이션을 살펴보고 MVVM 애플리케이션에서도 동일한 작업을 수행하십시오. 하나는 유연성이 제한되고 다른 하나는 제어력과 무한한 유연성을 갖기 때문에 더 많은 제어가 가능합니다.

제어 환경은 일련의 컨트롤러 또는 단일 소스에서 전체 애플리케이션을 관리하는 데 적합하며, 반응 환경은 ​​애플리케이션의 나머지 부분이 무엇인지 전혀 알지 못하는 별도의 리포지토리로 분리 될 수 있습니다. 마이크로 관리 대 무료 관리.

내가 너를 혼란스럽게하지 않았다면 나에게 연락을 ... 나는 그림과 예제들로 전체를 상세히 살펴볼 필요가 없다.

결국 우리는 모두 프로그래머이고 코딩 할 때 무정부 상태가 우리 안에 있습니다. 그래서 규칙이 깨지고 이론이 바뀌며 이것 모두가 돼지 씻기를 끝내게 될 것입니다. 그러나 커다란 작업을 할 때 프로젝트 및 대규모 팀의 경우 디자인 패턴에 동의하고이를 시행하는 데 실제로 도움이됩니다. 언젠가는 초기 단계에서 취해진 작은 추가 조치가 나중에 도약의 도약과 경계가 될 것입니다.




MVVMC, or perhaps MVC+, seems to be a viable approach for enterprise as well as rapid application development. While it is nice to separate the UI from business and interaction logic, the 'pure' MVVM pattern and most available examples work best on singular views.

Not sure about your designs, but most of my applications, however, contain pages and several (reusable) views and thus the ViewModels do need to interact to some degree. Using the page as controller would defeat the purpose of the MVVM altogether, so not using a "VM-C" approach for the underlying logic might result in .. well .. challenging constructs as the application matures. Even in VB-6 most of us probably stopped coding business logic into the Button event and started 'relaying' commands to a controller, right? I recently looked at many emerging framworks on that topic; my favorite clearly is the Magellan (at codeplex) approach. Happy coding!

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




Complementary to many of the responses given, I wanted to add some additional perspective from the Modern client-side web - or Rich Web Application point of view.

Indeed these days simple web sites and larger web applications are commonly built with many popular libraries such as Bootstrap. Built by Steve Sanderson, Knockout provides support for the MVVM pattern which mimics one of the most important behaviors in the pattern: data-binding through the View Model. With a little JavaScript, data and logic can be implemented that can then be added to page elements with simple data-bind HTML attributes, similar to using many of the features of Bootstrap . Together, these two libraries alone offer interactive content; and when combined with routing this approach can result in a simple-yet-powerful approach to building the Single Page Application .

Similarly, a Modern client-side framework such as Angular follows the MVC pattern by convention, but also adds a Service. Interestingly, it is touted as Model-View-Whatever (MVW). (See this post on .)

Additionally, with the rise of Progressive web frameworks such as Angular 2, we're seeing a change in terminology and perhaps a new architectural pattern where Components comprise of a View or Template and interact with a Service - all of which can be contained in a Module; and a series of Modules makes up the application.




가장 큰 차이점 중 하나는 MVC에서 V가 M을 직접 읽고 C를 통해 데이터를 조작하는 반면 MVVM에서는 VM이 ​​M 프록시로 작동 함과 동시에 사용 가능한 기능을 제공한다는 것입니다. V.

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




From what I can tell, the MVVM maps to the MV of MVC - meaning that in a traditional MVC pattern the V does not communicate directly with the M. In the second version of MVC, there is a direct link between M and V. MVVM appears to take all tasks related to M and V communication, and couple it to decouple it from the C. In effect, there's still the larger scope application workflow (or implementation of the use scenarios) that are not fully accounted for in MVVM. This is the role of the controller. By removing these lower level aspects from the controllers, they are cleaner and makes it easier to modify the application's use scenario and business logic, also making controllers more reusable.




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

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




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

대부분의 시간 자바 스크립트는 브라우저에서 mvvm에 사용됩니다. mvc에는 많은 서버 측 기술이 있습니다.




Related