MVP

모델 - 뷰 - 프리젠터 (MVP)는 프리젠 테이션 로직을 향상시키는 데 중점을 둔 MVC 디자인 패턴의 파생물입니다. 1990 년 초 Taligent라는 회사에서 시작하여 C ++ CommonPoint 환경의 모델을 연구했습니다. MVC와 MVP 둘 다 여러 구성 요소에 대한 관심사의 분리를 목표로하지만 그 사이에 근본적인 차이점이 있습니다.

이 요약에서는 웹 기반 아키텍처에 가장 적합한 MVP 버전에 중점을 둘 것입니다.

Models, Views & Presenters

MVP의 P는 발표자의 약자입니다. 뷰에 대한 사용자 인터페이스 비즈니스 로직을 포함하는 구성 요소입니다. MVC와는 달리 뷰의 호출은 표현 자에게 위임되며 뷰에서 분리되어 대신 인터페이스를 통해 호출됩니다. 이것은 유닛 테스트에서 모의 ​​뷰를 할 수있는 것과 같은 모든 유용한 것들을 허용합니다.

MVP의 가장 보편적 인 구현은 수동적 뷰 (모든 의도와 목적에 대한 뷰인 "벙어리 (dumb)")를 사용하는 것으로, 로직을 거의 또는 전혀 포함하지 않습니다. MVC와 MVP가 다르면 C와 P가 다른 일을하기 때문입니다. MVP에서 P는 모델을 관찰하고 모델이 변경되면 뷰를 업데이트합니다. P는 모델을 뷰에 효율적으로 바인딩합니다. 이전에 MVC의 컨트롤러가 가지고 있던 책임입니다.

보기로 요청하면 발표자는 사용자 요청과 관련된 작업을 수행하고 데이터를 다시 사용자에게 전달합니다. 이러한 관점에서 데이터를 검색하고 조작 한 다음 데이터를 뷰에 표시하는 방법을 결정합니다. 일부 구현 예에서, 표현자는 또한 서비스 계층과 상호 작용하여 데이터 (모델)를 지속시킨다. 모델은 이벤트를 트리거 할 수 있지만 뷰를 업데이트 할 수 있도록 이벤트를 구독하는 것은 발표자 역할입니다. 이 패시브 아키텍처에서는 직접 데이터 바인딩 개념이 없습니다. 뷰는 발표자가 데이터를 설정하는 데 사용할 수있는 설정자를 노출합니다.

이 MVC 변경의 이점은 응용 프로그램의 테스트 가능성을 높이고보기와 모델을 보다 명확하게 구분할 수 있다는 것입니다. 그러나 패턴에서 데이터 바인딩 지원이 부족하여 종종이 작업을 별도로 처리해야 한다는 것을 의미 할 수 있기 때문에 비용이 들지는 않습니다.

Passive view의 일반적인 구현은 보기가 인터페이스를 구현하는 것이지만, 발표자와 보기를 조금 더 분리 할 수있는 이벤트 사용을 포함하여 다양한 인터페이스가 구현되어 있습니다. 자바 스크립트에서 인터페이스 구조가 없으므로 여기서 명시적인 인터페이스보다 더 많은 프로토콜을 사용하고 있습니다. 그것은 기술적으로 여전히 API이며, 우리는 그것을 그 관점에서 인터페이스로 언급하는 것이 타당 할 것입니다.

MVP의 Supervising Controller 변형도 있습니다.이 모델은 MVC 및 MVVM 패턴에 더 가깝습니다. 뷰에서 직접 모델에서 데이터 바인딩을 제공하기 때문입니다. Deriv Bailey의 Backbone.ModelBinding 플러그인과 같은 KVO (Key-Value Observing) 플러그인은 백본을 패시브 뷰에서 벗어나 감독 컨트롤러 또는 MVVM 변형으로 가져 오는 경향이 있습니다.

MVP or MVC?

MVP는 일반적으로 가능한 한 많은 프리젠 테이션 로직을 재사용해야하는 엔터프라이즈 급 어플리케이션에서 가장 자주 사용됩니다. 매우 복잡한보기와 많은 사용자 상호 작용을하는 응용 프로그램은 MVC가이 문제를 해결할 때 여러 가지 컨트롤러에 크게 의존 할 수 있으므로 여기에 잘 맞지 않는다는 것을 알 수 있습니다. MVP에서이 모든 복잡한 논리를 표현 자로 캡슐화하여 유지 관리를 크게 단순화 할 수 있습니다.

MVP 뷰는 인터페이스를 통해 정의되며 인터페이스는 기술적으로 시스템과 뷰 (발표자 제외) 사이의 유일한 접촉점이기 때문에 개발자는 디자이너가 레이아웃을 생성 할 때까지 기다릴 필요없이 프리젠 테이션 로직을 작성할 수 있습니다. 응용 프로그램 용 그래픽

구현에 따라 MVP는 MVC보다 자동으로 단위 테스트가 쉬울 수 있습니다. 그 이유는 발표자가 사용자 인터페이스의 완전한 모의 객체로 사용될 수 있으므로 다른 구성 요소와 독립적으로 단위 테스트를 수행 할 수 있기 때문입니다. 내 경험에 의하면 이것은 MVP를 구현하는 언어에 따라 다릅니다 (ASP.net과 비교하여 JavaScript 프로젝트 MVP를 선택하는 것과는 상당한 차이가 있습니다).

결국 MVC에 대한 근본적인 우려는 MVP의 차이점이 주로 의미 론적이라는 점을 감안할 때 MVP에 적용될 가능성이 높습니다. 관심사를 모델, 뷰 및 컨트롤러 (또는 발표자)로 깔끔하게 구분하는 한 우리는 우리가 선택한 변형에 관계없이 동일한 이점 대부분을 달성해야합니다.

MVC, MVP and Backbone.js

MVC 또는 MVP 패턴을 구현하는 것을 주장하는 아키텍처 JavaScript 프레임 워크가 많은 경우, 많은 자바 스크립트 개발자가 MVC와 MVP를 상호 배타적 인 것으로 보지 않습니다 (MVC가 실제로는 엄격하게 구현되는 것을 볼 가능성이 더 큽니다. ASP.net 또는 GWT와 같은 웹 프레임 워크를 살펴볼 때). 이는 애플리케이션에 추가 표현 자 / 뷰 로직을 포함 할 수 있지만 여전히 MVC의 맛이라고 생각하기 때문입니다.

백본 기고가 Irene Ros (Boston-based Bocoup의)는 자신의 고유 한 구성 요소로 뷰를 분리 할 때 실제로 그녀를 위해 어셈블 할 무언가가 필요하기 때문에 이러한 사고 방식을 구독합니다. 이것은 컨트롤러 루트 (예 : Backbone.Router, 나중에 책에서 다룰 수 있음)이거나 가져 오는 데이터에 대한 콜백 일 수 있습니다.

그렇지만 일부 개발자는 Backbone.js가 MVC보다 MVP에 더 잘 맞다고 생각합니다. 그들의 견해는 다음과 같다.

• MVP의 발표자는 컨트롤러가 수행하는 것보다 Backbone.View (보기 템플릿과 그에 바인딩 된 데이터 사이의 레이어)를보다 잘 설명합니다.
• 이 모델은 Backbone.Model에 맞습니다 (MVC의 모델과 크게 다르지 않습니다)
• 보기는 템플릿을 가장 잘 나타냅니다 (예 : 핸들 / 콧수염 마크 업 템플릿)

이것에 대한 응답은 백본이 여러 목적으로 사용될 수있을 정도로 융통성이 있기 때문에보기가 MVC에 따라보기 일 수도 있다는 것입니다. MVC의 V와 MVP의 P는 Backbone.View에서 수행 할 수 있습니다. 두 가지 목적을 달성 할 수 있기 때문입니다. 기본 구성 요소를 렌더링하고 다른 뷰에서 렌더링 된 구성 요소를 어셈블하는 두 가지 목적을 모두 달성 할 수 있기 때문입니다.

또한 Backbone에서 컨트롤러의 책임은 Backbone.View와 Backbone.Router와 공유되며 다음 예제에서 실제로 그 측면이 사실임을 알 수 있습니다.

우리 백본 PhotoView는 Observer 패턴을 사용하여 this.model.bind("change", ...) 행에서 View의 모델 변경 사항을 "구독"합니다. 또한 render() 메소드에서 템플릿을 처리하지만 다른 구현과 달리 사용자 상호 작용은보기 (events 참조)에서도 처리됩니다.

var PhotoView = Backbone.View.extend({

    //... is a list tag.
    tagName: "li",

    // Pass the contents of the photo template through a templating
    // function, cache it for a single photo
    template: _.template( $("#photo-template").html() ),

    // The DOM events specific to an item.
    events: {
      "click img": "toggleViewed"
    },

    // The PhotoView listens for changes to
    // its model, re-rendering. Since there's
    // a one-to-one correspondence between a
    // **Photo** and a **PhotoView** in this
    // app, we set a direct reference on the model for convenience.

    initialize: function() {
      this.model.on( "change", this.render, this );
      this.model.on( "destroy", this.remove, this );
    },

    // Re-render the photo entry
    render: function() {
      $( this.el ).html( this.template(this.model.toJSON() ));
      return this;
    },

    // Toggle the `"viewed"` state of the model.
    toggleViewed: function() {
      this.model.viewed();
    }

});

또 다른 (전혀 다른) 의견은 Backbone이 Smalltalk-80 MVC와 더 유사하다는 점입니다.

일반 Backbone 블로거 Derick Bailey가 이전에 말했던 것처럼 Backbone이 특정 디자인 패턴에 맞도록 강요하지 않는 것이 가장 좋습니다. 디자인 패턴은 애플리케이션 구성 방법에 대한 유연한 가이드로 간주되어야하며, 이러한 관점에서 백본은 MVC 나 MVP를 모두 충족하지 못합니다. 대신 여러 아키텍처 패턴에서 최상의 개념 중 일부를 차용하고 잘 작동하는 유연한 프레임 워크를 만듭니다.

그러나 이러한 개념이 어디에서 왜 발생했는지 이해할 가치가 있으므로 MVC 및 MVP에 대한 내 설명이 도움이되기를 바랍니다. 백본 (Backbone) 방식, MV * 또는 무엇이든 응용 프로그램 아키텍처의 특징을 참조하는 데 도움이됩니다. 대부분의 구조적 JavaScript 프레임 워크는 고의적으로 또는 실수로 고전적인 패턴을 취할 것입니다. 그러나 중요한 것은 조직화되고 깨끗하며 쉽게 유지 관리 할 수있는 응용 프로그램을 개발하는 데 도움이된다는 것입니다.