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




패턴 구현 (19)

MVVM은 뷰 모델을 믹스에 추가합니다. WPF의 바인딩 방식을 많이 사용할 수 있으므로 모든 UI 관련 부분을 일반 모델에 넣지 않아도되므로 중요합니다.

내가 틀릴 수도 있지만 MVVM이 실제로 컨트롤러를 혼합하도록 확신하지 못합니다. 나는 그 개념이 http://martinfowler.com/eaaDev/PresentationModel.html 과 더 잘 어울리는 것을 발견했다. 나는 사람들이 그것을 MVC와 결합하도록 선택했다고 생각한다.

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


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

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

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


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


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

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

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


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


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

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

Russel East 는 블로그에 대해 자세히 논의하고 있습니다. MVVM이 MVC와 다른 이유는 무엇입니까?


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

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


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

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

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

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

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

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

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

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


나는 MVC와 MVVM이 같다고 생각했다. 이제는 Flux의 존재로 인해 차이점을 알 수 있습니다.

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

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

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


Windows 환경에서 MVVM 패턴에 대한 설명 수 있습니다.

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

  • 모델 : 앱에서 사용하는 데이터 모델을 나타냅니다. 예를 들어 그림 공유 응용 프로그램에서이 계층은 장치에서 사용할 수있는 그림 집합과 그림 라이브러리를 읽고 쓰는 데 사용되는 API를 나타낼 수 있습니다.

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

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


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

MVC (모델 뷰 컨트롤러)

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

MVVM (모델 뷰 뷰 모델)

ViewModel :

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

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

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


MVC / MVVM은 선택 사항이 아닙니다.

ASP.Net과 Silverlight / WPF 개발에서 두 가지 패턴이 다른 방식으로 나타납니다.

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

Silverlight 및 WPF의 경우 MVVM 패턴이보다 포괄적이며 MVC (또는 조직 구성 소프트웨어의 다른 패턴을 별도의 책임으로 대체)로 대신 할 수 있습니다. 한 예로,이 패턴에서 자주 나오는 한 가지 가정은 ViewModel 단순히 MVC 의 컨트롤러를 대체 한 것입니다 (약어로 C 대신 VM 을 대체 할 수 있고 모두 용서받을 수있는 것처럼) ...

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

문제는 독립적으로 테스트 할 수 있어야하고, 필요할 때 재사용이 가능해야한다는 뷰 모델은 뷰가 어떤 뷰를 표시하고 있는지 알지 못하지만 더 중요한 것은 데이터가 어디서 오는지 알지 못한다는 것입니다 .

* 참고 : 실제로 컨트롤러는 ViewModel에서 단위 테스트가 필요한 대부분의 로직을 제거합니다. 그런 다음 VM은 테스트가 거의 필요없는 멍청한 컨테이너가됩니다. VM은 설계자와 코더 사이의 다리에 불과하므로 단순하게 유지해야합니다.

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

지금까지 XAML 코드 숨김에서 코드를 제거 하여 XAML 편집을보다 독립적 인 작업으로 만들기 위해 ViewModel 패턴의 주요 이점을 보았습니다. 필요에 따라 컨트롤러를 만들어서 응용 프로그램의 전반적인 논리를 제어합니다.

우리가 따라야 할 기본 MVCVM 지침은 다음과 같습니다.

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

또한 Sculpture code-gen 프레임 워크 는 MVVM과 Prism과 유사한 패턴을 구현했으며 모든 유스 케이스 로직을 분리하기 위해 컨트롤러를 광범위하게 사용합니다.

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

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

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

참고 사항 :이 게시물은 여러 번 편집되었으며 특별히 좁은 질문을 대상으로하지 않았으므로 첫 번째 부분도 업데이트했습니다. 아래의 주석에서 토론의 대부분은 ASP.Net에만 관련되며 전체적인 그림과 관련이 없습니다. 이 게시물은 Silverlight, WPF 및 ASP.Net에서 MVVM의 광범위한 사용을 다루고 컨트롤러를 ViewModels로 교체하는 사람들을 피하려고했습니다.


viewmodel은 사용자 인터페이스 요소의 "추상"모델입니다. 비 시각적 인 방법으로 (예 : 테스트하기 위해)보기에서 명령과 조치를 실행할 수 있어야합니다.

MVC로 작업 한 적이 있다면, 예를 들어 일부 편집 대화 상자를 표시하거나 숨기는 등 뷰의 상태를 반영하여 모델 객체를 만드는 것이 유용 할 때가있을 것입니다.이 경우 뷰 모델을 사용하고 있습니다.

MVVM 패턴은 모든 UI 요소에 대한 관행의 일반화입니다.

그리고 그것은 Microsoft 패턴이 아니며 WPF / Silverlight 데이터 바인딩이이 패턴을 사용하는 데 특히 적합하다는 점을 추가했습니다. 하지만 자바 서버와 같이 사용하는 것을 막을 방법은 없다.


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 애플리케이션에서도 동일한 작업을 수행하십시오. 하나는 유연성이 제한되고 다른 하나는 제어력과 무한한 유연성을 갖기 때문에 더 많은 제어가 가능합니다.

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

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

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


강력하게 형식화 된 ViewModel을 MVC를 사용하여 뷰에 주입

  1. 컨트롤러는 ViewModel을 새로 만들고 View에 주입하는 역할을 담당합니다. (요청을 받기 위해)
  2. ViewModel은 마지막으로 선택한 항목 등의 DataContext 및 뷰 상태에 대한 컨테이너입니다.
  3. 모델에는 DB 엔터티가 포함되어 있으며 쿼리와 필터링을 수행하는 DB 스키마와 매우 유사합니다. (나는 EF와 LINQ를 좋아한다.)
  4. 또한 모델은 결과를 리포지토리 및 / 또는 강력한 형식으로 투영하는 것을 고려해야합니다. EF는 쿼리를 삽입하고 강력한 형식을 가져 오기위한 직접 ADO 액세스를위한 EF.Database.Select (querystring, parms)입니다. EF 가 느리지 않습니다 !
  5. ViewModel은 데이터를 가져오고 비즈니스 규칙 및 유효성 검사를 수행합니다.
  6. 포스트 백 컨트롤러 는 ViewModel 포스트 메소드를 계산하고 결과를 기다립니다.
  7. 컨트롤러는 새로 업데이트 된 Viewmodel을 뷰에 삽입합니다. 보기는 강력한 형식 바인딩 만 사용 합니다 .
  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이 Model / Buisness 로직과 인터페이싱하는 모든 "클러 터"작업을 수행한다는 것입니다. 컨트롤러는 단순히 일종의 라우터 일뿐입니다. 실제로 SOC입니다.


실용적인 관점에서 MVC (Model-View-Controller)는 하나의 패턴입니다. 그러나 Entity Framework (EF) 및 "전동 도구"와 결합 된 ASP.net MVC로 사용되는 MVC는 데이터베이스, 테이블 및 열을 웹 페이지로 가져 오기위한 매우 강력하고 부분적으로 자동화 된 접근 방법입니다. CRUD 조작 또는 R (검 v 또는 읽기) 조작 만 가능합니다. 적어도 MVVM을 사용함에 따라 뷰 모델은 비즈니스 객체를 기반으로하는 모델과 상호 작용했습니다. 비즈니스 모델은 차례대로 "수작업"이었고 많은 노력을 기울여야 EF에서 제공하는 것만 큼 좋은 모델을 얻을 수있었습니다. -of-the-box "라고 부른다. 실용적인 프로그래밍 관점에서 볼 때, MVC는 많은 유틸리티를 기본적으로 제공하기 때문에 좋은 선택 인 것처럼 보이지만 종소리에 추가 할 가능성은 여전히 ​​있습니다.


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

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

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

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


복잡한 구조는 생성 될 객체가 추상화에 의해 표현되는 다른 다른 객체로 구성되는 경우입니다.

맥도날드의 메뉴를 고려해보십시오. 메뉴에는 주류, 주류 및 음료가 들어 있습니다. 개별 추상화의 어떤 자손이 함께 구성되는지에 따라 작성된 메뉴에는 다른 표현이 있습니다.

  1. 예 : 콜라, 빅맥, 프렌치 프라이
  2. 예 : 스프라이트, 너겟, 곱슬 튀김

거기에서 우리는 다른 표현을 가진 메뉴의 2 개의 인스턴스를 얻었다. 차례대로 건설 과정은 동일하게 유지됩니다. 음료, 메인 및 측면이있는 메뉴를 만듭니다.

빌더 패턴을 사용하여 복합 오브젝트를 작성하는 데 사용 된 여러 구성 요소에서 복잡한 오브젝트 작성 알고리즘을 분리합니다.

빌더 패턴과 관련하여 알고리즘은 디렉터에 캡슐화되지만 빌더는 필수 파트를 작성하는 데 사용됩니다. 디렉터의 알고리즘에서 사용 된 빌더를 변경하면 다른 부분이 메뉴로 구성되므로 다른 표현이됩니다. 메뉴가 생성되는 방식은 동일합니다.