model-view-controller 패턴 구현 - MVC와 MVVM의 차이점은 무엇입니까?





11 Answers

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

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

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

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

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

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

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

개인적으로, 나는이 이론과 두문자어 사업이 구체적 현실에서 무엇을 언급 하는지를 봄으로써 이해하기 쉽다고 생각한다. 추상적 인 개념은 특히 구체적인 문제에 대해 시연 할 때 유용합니다. 따라서 이해는 완전한 동그라미가 될 수 있습니다.

윈폼 코틀린 android

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




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

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




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

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




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

MVC (모델 뷰 컨트롤러)

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

MVVM (모델 뷰 뷰 모델)

ViewModel :

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



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간에 동일하거나 전혀 다른 Model 임) ... 물론이 시점에서 View의 Controller에 대해 알아야 할 필요가있는 점은 대부분 모델을 통과 할 지점을 알기위한 엔드 포인트 참조입니다.

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

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

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

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

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




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




MVVM 의 출처 를 언급하지 않고도 투표율이 높습니다 . MVVM 은 Microsoft 커뮤니티에서 널리 사용되는 용어이며 Martin Fowler의 Presentation Model 에서 유래 했습니다 . 따라서 패턴의 동기와 다른 사람들과의 차이점을 이해하려면 패턴에 대한 최초의 기사가 가장 먼저 읽어야합니다.




MVVMC 또는 아마도 MVC +는 빠른 응용 프로그램 개발뿐 아니라 엔터프라이즈에 대한 실행 가능한 접근 방식 인 것으로 보입니다. 비즈니스와 상호 작용 로직과 UI를 분리하는 것이 좋지만 '순수한'MVVM 패턴과 가장 유용한 예제는 단일 뷰에서 가장 잘 작동합니다.

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

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




많은 응답을 보완하기 위해 현대 클라이언트 측 웹 또는 Rich Web Application 관점에서 몇 가지 추가적인 관점을 추가하고자했습니다 .

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

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

또한 Angular 2와 같은 Progressive 웹 프레임 워크 의 등장으로 용어의 변화와 구성 요소가 뷰 또는 템플릿으로 구성되고 서비스와 상호 작용하는 새로운 아키텍처 패턴을 볼 수 있습니다. 기준 치수; 일련의 모듈이 응용 프로그램을 구성합니다.




건축 패턴의 주제에 익숙하지 않은 사람들에게는 다른 대답은 이해하기 쉽지 않을 수도 있습니다. 앱 아키텍처에 익숙하지 않은 사람은 선택이 실제로 앱에서 어떻게 영향을 미치는지, 모든 소란은 커뮤니티에서 어떤 영향을 미치는지 알고 싶어합니다.

위의 내용을 밝히기 위해 MVVM, MVP 및 MVC와 관련된이 시나리오를 만들었습니다. 이야기는 사용자가 영화 검색 앱에서 '찾기'버튼을 클릭하면 시작됩니다.

사용자 : 클릭 ...

보기 : 누구 시죠?[ MVVM | MVP | MVC ]

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

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

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

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

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

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

-이 사이의 가장 중요한 차이점이다 MVVMMVP는 | MVC ---

발표자 : 감사의 말, ... 한편 모델 에 대한 검색어를 찾고 있는데, 진행률 표시 줄 [ MVP | MVC ]

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

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

(searchResultsListObservable의 모든 트리거에 관찰하는 동안, 보기 이후는, 사용자에게 일부 진행률 표시 줄을 표시해야합니다 생각 의 ViewModel이 그에 얘기하지 것이다)

------------------------------

ViewModel | 발표자 | 컨트롤러 : Hey Model ,이 검색어에 해당하는 단어가 있나요? : "piano"[ MVVM | MVP | MVC ]

모델 : 안녕 ViewModel | 발표자 | 컨트롤러 , 내가 확인하자 ... [ MVVM | MVP | MVC ]

( 모델 이 무비 데이터베이스에 질의를하는 중 ...) [ MVVM | MVP | MVC ]

( 잠시 후 … )

---- 이것은 MVVM , MVPMVC 사이의 분기 지점입니다 -----

모델 : 당신을위한리스트를 찾았습니다, ViewModel | Presenter , JSON "[{"name ":"Piano Teacher ","year ": 2001}, {"name ":"year ": 1993}" "[ MVVM | MVP ]

모델 : 컨트롤러를 사용할 수있는 몇 가지 결과가 있습니다. 내 인스턴스에 필드 변수를 만들고 결과로 채 웠습니다.그것의 이름은 "searchResultsList"입니다 [ MVC ]

( Presenter | Controller 감사 모델 , 다시 보기로 돌아 감) [ MVP | MVC ]

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

컨트롤러 : 기다려 주셔서 감사합니다. View , Model에 검색어를 물어 보았습니다. 일치하는 결과 목록을 발견하고 그 인스턴스 내에 "searchResultsList"라는 변수에 저장했다고합니다. 거기에서 얻을 수 있습니다. 또한 진행률 표시 줄을 숨기십시오. [ MVC ]

ViewModel : searchResultsListObservable의 모든 관찰자는 [ "Piano Teacher 2001", "Piano 1993"]. [ MVVM ]

보기 : 대단히 감사합니다 [ MVP ]

보기 : " 컨트롤러 "[ MVC ] (이제 자체에 의문점을 던집니다. 모델 에서 얻은 결과 를 사용자에게 어떻게 표시해야합니까? 영화 제작 년도가 처음 또는 마지막일까요?)

보기 : 오, searchResultsListObservable에 새로운 트리거가 있습니다. 좋습니다. 현재 목록이 있습니다. 이제 목록에 표시하면됩니다. 나는 결과를 얻었으므로 진행률 막대도 숨겨야합니다. [ MVVM ]

혹시 관심이 있으신 가요? here 에 동영상 검색 안드로이드 앱을 구현하여 MVVM, MVP 및 MVC를 비교 하는 기사 시리즈를 작성했습니다 .




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

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




Related