MVC

MVC는 관심사를 분리하여 향상된 응용 프로그램 구성을 장려하는 아키텍처 디자인 패턴입니다. 이는 전통적으로 로직 및 사용자 입력을 관리하는 세 번째 구성 요소 (컨트롤러)를 사용하여 사용자 인터페이스 (뷰)에서 비즈니스 데이터 (모델)를 격리하도록합니다. 이 패턴은 처음에는 모델 뷰 컨트롤러 편집기 (Model-View-Controller-Editor)라고 불리는 Smalltalk-80 (1979)에서 작업하면서 Trygve Reenskaug가 디자인했습니다. MVC는 1995 년 "디자인 패턴 : 재사용 가능한 객체 지향 소프트웨어의 요소"( "GoF"책)에서 심도있게 설명되었으며, 그 사용법이 대중화되는 역할을 수행했습니다.

Smalltalk-80 MVC

원래의 MVC 패턴이 해결하고자 했던 것이 무엇인지 이해하는 것이 중요합니다. 1970 년대로 거슬러 올라가 보면 그래픽 사용자 인터페이스가 거의 없었으며 분리 된 프리젠테이션으로 알려진 개념이 현실 세계의 개념을 모델링 한 도메인 객체 (예 : 사진, 사람) 간의 명확한 구분을 만들기위한 수단으로 사용되기 시작했으며 이것은 사용자 화면에 표현 된 프리젠테이션 객체를 표시합니다.

MVC의 Smalltalk-80 구현은이 개념을 더욱 발전 시켰으며 사용자 인터페이스에서 애플리케이션 로직을 분리하는 것을 목표로 삼았습니다. 아이디어는 응용 프로그램의 이러한 부분을 분리하면 응용 프로그램의 다른 인터페이스에 대한 모델을 다시 사용할 수 있다는 것입니다. Smalltalk-80의 MVC 아키텍처에 대해 주목할만한 흥미로운 점이 몇 가지 있습니다.

  • 모델은 도메인 특정 데이터를 나타내며 사용자 인터페이스 (보기 및 컨트롤러)를 모르고있었습니다. 모델이 변경되면 옵서버에게 알릴 것입니다.
  • 뷰는 모델의 현재 상태를 나타냅니다. Observer 패턴은 모델이 업데이트되거나 수정 될 때 마다 뷰를 알리는 데 사용되었습니다.
  • 프리젠테이션은 뷰로 처리되었지만 단일 뷰 및 컨트롤러만 있는 것은 아니며 화면에 표시되는 각 섹션이나 요소에 대해 뷰 컨트롤러 쌍이 필요했습니다.
  • 이 쌍의 컨트롤러 역할은 사용자 상호 작용 (키 누름 및 클릭 등의 동작)을 처리하면서 보기에 대한 결정을 내리고있었습니다.

개발자는 수십 년 전 MVC 아키텍처의 일부로 포함 된 Observer 패턴 (요즘 일반적으로 Publish / Subscribe 변형으로 구현 됨)이 배웠을 때 때로는 놀랐습니다. Smalltalk-80의 MVC에서 View는 모델을 관찰합니다. 위의 글 머리 기호에서 언급했듯이 모델이 변경 될 때마다 Views가 반응합니다. 간단한 예제는 주식 시장 데이터로 뒷받침되는 애플리케이션입니다. 애플리케이션을 유용하게 사용하려면 모델의 데이터를 변경하면 View가 즉시 새로 고쳐 져야합니다.

마틴 파울러 (Martin Fowler)는 수년 동안 MVC의 기원에 대해 훌륭한 글을 쓴 적이 있으며 Smalltalk-80의 MVC에 관한 더 많은 역사적인 정보에 관심이 있다면 그의 작품을 읽는 것이 좋습니다.

MVC For JavaScript Developers

우리는 70 년대를 재검토했지만 이제 지금 여기로 돌아오도록 합시다. 현대에서 MVC 패턴은 JavaScript와 관련성이 높은 다양한 프로그래밍 언어 (JavaScript)에 적용되었습니다. JavaScript는 이제 MVC (MVC 패밀리라고도하는 유사 콘텐츠)에 대한 지원을 자랑하는 여러 프레임 워크를 제공하므로 개발자는 큰 노력 없이도 애플리케이션에 구조를 쉽게 추가 할 수 있습니다.

이러한 프레임 워크에는 Backbone, Ember.js 및 AngularJS 등이 포함됩니다. 구조가 없어서 읽거나 유지하기 어려운 코드를 설명하는 "스파게티"코드의 중요성을 감안할 때 현대 JavaScript 개발자는이 패턴이 제공하는 것을 이해하는 것이 중요합니다. 이를 통해 우리는 이러한 프레임 워크를 통해 우리가 다르게 할 수있는 것을 효과적으로 인식 할 수 있습니다.

우리는 MVC가 세 가지 핵심 구성 요소로 구성된다는 것을 알고 있습니다.

Models

모델은 응용 프로그램의 데이터를 관리합니다. 그들은 사용자 인터페이스 나 표현 계층 모두에 관심을 두지 않고 응용 프로그램이 요구할 수있는 고유 한 형태의 데이터를 나타냅니다. 모델이 변경되면 (예 : 업데이트 될 때) 일반적으로 관찰자 (예 : 뷰, 곧 다룰 개념)에 변경 사항이 발생했음을 알리기 때문에 관찰자가 그에 따라 반응 할 수 있습니다.

모델을 더 잘 이해하기 위해 자바 스크립트 포토 갤러리 애플리케이션이 있다고 가정 해 보겠습니다. 사진 갤러리에서 고유 한 종류의 도메인 관련 데이터를 나타내는 사진의 개념은 자체 모델의 장점을 누릴 수 있습니다. 이러한 모델에는 캡션, 이미지 소스 및 추가 메타 데이터와 같은 관련 특성이 포함될 수 있습니다. 특정 사진은 모델 인스턴스에 저장되며 모델은 재사용 가능합니다. 아래에서는 백본을 사용하여 구현 된 매우 단순한 모델의 예를 볼 수 있습니다.

var Photo = Backbone.Model.extend({

    // Default attributes for the photo
    defaults: {
      src: "placeholder.jpg",
      caption: "A default image",
      viewed: false
    },

    // Ensure that each photo created has an `src`.
    initialize: function() {
       this.set( { "src": this.defaults.src} );
    }

});

모델의 기본 제공 기능은 프레임 워크마다 다르지만 속성의 유효성 검증을 지원하는 것이 일반적입니다. 속성은 모델 식별자와 같은 모델의 속성을 나타냅니다. 실제 응용 프로그램에서 모델을 사용할 때 우리는 일반적으로 모델 지속성을 원합니다. 지속성을 통해 모델을 편집하고 업데이트 할 수 있습니다. 가장 최근 상태는 메모리, 사용자의 localStorage 데이터 저장소 또는 데이터베이스와 동기화 된 상태로 저장됩니다.

또한 모델에는 모델을 관측하는 다중 뷰가있을 수 있습니다. 사진 모델에 위치 (위도 및 경도), 사진에있는 친구 (식별자 목록) 및 태그 목록과 같은 메타 데이터가 포함 된 경우 개발자는 표시 할 단일보기를 제공하기로 결정할 수 있습니다 이 세 가지면 각각.

현대 MVC / MV * 프레임 워크가 모델을 그룹화하는 수단을 제공하는 것은 드문 일이 아닙니다 (예 : 백본에서 이러한 그룹을 "콜렉션"이라고 함). 그룹으로 모델을 관리하면 그룹의 모든 모델이 변경되면 그룹의 알림을 기반으로 애플리케이션 로직을 작성할 수 있습니다. 따라서 개별 모델 인스턴스를 수동으로 관찰 할 필요가 없습니다.

모델을 단순화 된 백본 컬렉션으로 그룹화하는 샘플을 아래에서 볼 수 있습니다.

var PhotoGallery = Backbone.Collection.extend({

    // Reference to this collection's model.
    model: Photo,

    // Filter down the list of all photos
    // that have been viewed
    viewed: function() {
        return this.filter(function( photo ){
           return photo.get( "viewed" );
        });
    },

    // Filter down the list to only photos that
    // have not yet been viewed
    unviewed: function() {
      return this.without.apply( this, this.viewed() );
    }
});

MVC의 오래된 텍스트는 응용 프로그램 상태를 관리하는 모델 개념에 대한 참조를 포함 할 수도 있습니다. JavaScript 응용 프로그램 상태는 일반적으로 현재 "상태", 즉 특정 데이터가 포함 된 뷰 또는 하위 뷰를 사용자 화면에 나타내는 다른 의미를 지닙니다. 고정 점. 상태는 상태 개념을 시뮬레이션해야하는 단일 페이지 응용 프로그램을 볼 때 정기적으로 논의되는 항목입니다.

요약하면 모델은 주로 비즈니스 데이터와 관련이 있습니다.

Views

뷰는 현재 상태의 필터링 된 뷰를 표시하는 모델의 시각적 표현입니다. Smalltalk 뷰는 비트 맵을 페인팅하고 유지 보수하는 반면, JavaScript 뷰는 DOM 요소를 작성하고 유지 관리하는 것입니다.

뷰는 일반적으로 모델을 관측하고 모델이 변경 될 때이를 통보하여 뷰가 그에 맞게 업데이트되도록합니다. 디자인 패턴 문헌은 일반적으로 응용 프로그램의 모델 및 컨트롤러에 대한 지식이 제한되어 있으므로 뷰를 "멍청한"것으로 간주합니다.

사용자는 뷰와 상호 작용할 수 있으며, 여기에는 모델을 읽고 편집 (즉, 속성 값을 가져 오거나 설정)하는 기능이 포함됩니다. 뷰는 프리젠 테이션 레이어이므로 일반적으로 사용자 친화적 인 방식으로 편집하고 업데이트 할 수있는 기능을 제공합니다. 예를 들어 이전 포토 갤러리 애플리케이션에서 모델 편집은 특정 사진을 선택한 사용자가 메타 데이터를 편집 할 수있는 "편집"보기를 통해 쉽게 수행 할 수 있습니다.

모델을 업데이트하는 실제 작업은 컨트롤러로 넘어갑니다 (곧 다루 겠습니다).

바닐라 자바 ​​스크립트 샘플 구현을 사용하여보기를 조금 더 살펴 보도록하겠습니다. 아래에서는 모델 인스턴스와 컨트롤러 인스턴스를 모두 소비하는 단일 사진보기를 만드는 함수를 볼 수 있습니다.

뷰 내의 render() 유틸리티는 JavaScript 템플릿 엔진 (Underscore templating)을 사용하여 photoModel의 내용을 렌더링하고 photoEl이 참조하는 뷰의 내용을 업데이트하는 역할을합니다.

그런 다음 photModel은 Observer 패턴을 통해 모델 변경시 뷰를 트리거 할 수 있도록 구독자 중 하나 인 render() 콜백을 추가합니다.

여기서 사용자 상호 작용이 어디에서 작용하는지 궁금해 할 수 있습니다. 사용자가보기에서 요소를 클릭하면 다음에 수행 할 작업을 아는 것은보기의 책임이 아닙니다. 이 결정을 내리기 위해 컨트롤러를 사용합니다. 샘플 구현에서, 이는 필요할 때를 대비해 모델 정보를 전달하면서 click 동작을 컨트롤러로 다시 처리하도록 위임 할 photEl에 이벤트 리스너를 추가하여 구현됩니다.

이 아키텍처의 이점은 각 구성 요소가 필요에 따라 응용 프로그램 기능을 작성하는 데있어 별도의 역할을 수행한다는 것입니다.

var buildPhotoView = function ( photoModel, photoController ) {

  var base = document.createElement( "div" ),
      photoEl = document.createElement( "div" );

  base.appendChild(photoEl);

  var render = function () {
          // We use a templating library such as Underscore
          // templating which generates the HTML for our
          // photo entry
          photoEl.innerHTML = _.template( "#photoTemplate", {
              src: photoModel.getSrc()
          });
      };

  photoModel.addSubscriber( render );

  photoEl.addEventListener( "click", function () {
    photoController.handleEvent( "click", photoModel );
  });

  var show = function () {
    photoEl.style.display = "";
  };

  var hide = function () {
    photoEl.style.display = "none";
  };

  return {
    showView: show,
    hideView: hide
  };

};

Templating

MVC / MV *를 지원하는 JavaScript 프레임 워크와 관련하여, 마지막 섹션에서 간략하게 언급 한대로 JavaScript 템플릿과 뷰와의 관계에 대해 간략하게 논의 할 필요가 있습니다.

문자열 연결을 통해 메모리에 대량의 HTML 마크 업 블록을 수동으로 생성하는 것은 오랫동안 성능이 좋지 않은 것으로 간주되어 왔습니다. 개발자는 데이터를 반복적으로 반복하여 중첩 된 div로 래핑하고 document.write와 같은 오래된 기술을 사용하여 DOM에 "템플릿"을 삽입합니다. 이는 일반적으로 표준 마크 업과 함께 스크립트 된 마크 업을 유지하는 것을 의미하므로, 특히 사소한 크기가 아닌 응용 프로그램을 빌드 할 때 이러한 재난을 빠르게 읽고 더욱 중요하게 유지할 수 있습니다.

자바 스크립트 템플릿 솔루션 (예 : Handlebars.js 및 Mustache)은 템플릿 변수를 포함하는 마크 업 (외부 적으로 저장되거나 사용자 정의 유형이있는 스크립트 태그 내에 - 예 : 텍스트 / 템플릿)으로보기 용 템플릿을 정의하는 데 자주 사용됩니다. 변수는 변수 구문 (예 : )을 사용하여 구분할 수 있으며 프레임 워크는 일반적으로 JSON 형식 (모델 인스턴스를 변환 할 수 있음)의 데이터를 받아 들일만큼 스마트하며 클린 모델 및 깨끗한 템플릿. 인구와 관련있는 대부분의 불만은 프레임 워크 자체에서 처리됩니다. 이것은 특히 템플릿을 외부 적으로 저장하도록 선택하면 큰 응용 프로그램을 빌드 할 때 필요에 따라 동적으로로드되는 템플릿을 제공 할 수 있으므로 많은 이점을 제공합니다.

아래에서 HTML 템플릿의 두 가지 예를 볼 수 있습니다. 인기있는 Handlebars.js 프레임 워크와 Underscore의 템플릿을 사용하여 구현되었습니다.

Handlebars.js:
<li class="photo">
  <h2>{{caption}}</h2>
  <img class="source" src="{{src}}"/>
  <div class="meta-data">
    {{metadata}}
  </div>
</li>
Underscore.js Microtemplates:
<li class="photo">
  <h2><%= caption %></h2>
  <img class="source" src="<%= src %>"/>
  <div class="meta-data">
    <%= metadata %>
  </div>
</li>

템플릿 자체는 뷰가 아닙니다. Struts Model 2 아키텍처에서 오는 개발자는 템플릿과 같은 느낌을 가질 수 있습니다 *보기이지만, 그렇지 않습니다. 뷰는 모델을 관찰하고 시각적 표현을 최신 상태로 유지하는 객체입니다. 템플리트 *는 뷰 객체의 일부 또는 전부를 지정하는 선언적 방법 일 수 있으므로 템플리트 스펙에서 생성 할 수 있습니다.

또한 클래식 웹 개발에서 독립된 뷰 사이를 탐색 할 때 페이지 새로 고침이 필요하다는 점도 유의할 필요가 있습니다. 그러나 단일 페이지 JavaScript 애플리케이션에서 Ajax를 통해 서버에서 데이터를 가져 오면 이러한 페이지를 새로 고치지 않아도 동일한 페이지 내의 새로운 뷰에서 동적으로 렌더링 할 수 있습니다.

따라서 탐색의 역할은 응용 프로그램 상태를 관리하는 데 도움이되는 "라우터"(예 : 사용자가 탐색 한 특정보기를 책갈피에 추가 할 수 있음)로 분류됩니다. 그러나 라우터는 MVC의 일부도 아니며 모든 MVC와 유사한 프레임 워크에 존재하지 않기 때문에이 섹션에서 라우터에 대해 자세히 설명하지 않겠습니다.

요약하면 뷰는 애플리케이션 데이터를 시각적으로 표현한 것입니다.

Controllers

컨트롤러는 사용자가 뷰를 조작 할 때 모델을 업데이트하는 데 고전적인 역할을하는 모델과 뷰 사이의 중개자입니다.

사진 갤러리 응용 프로그램에서 컨트롤러는 사용자가 편집을 마쳤을 때 특정 사진 모델을 업데이트하여 특정 사진에 대한 편집보기에서 사용자가 변경 한 사항을 처리 할 책임이 있습니다.

컨트롤러는 MVC에서 뷰의 전략 패턴을 촉진하는 역할을 수행한다는 것을 기억하십시오. 전략 패턴과 관련하여 뷰는 재량에 따라 컨트롤러에 위임합니다. 즉, 전략 패턴이 작동하는 방식입니다. 보기는 사용자 이벤트를 컨트롤러에 처리하도록 위임 할 수 있습니다. 뷰는 모델 변경 이벤트를 컨트롤러에 처리하도록 위임 할 수 있지만 컨트롤러의 전통적인 역할은 아닙니다.

그러나 대부분의 자바 스크립트 MVC 프레임 워크가 어디에서 "MVC"로 간주되는지에 대해서는 컨트롤러와 관련이 있습니다. 이것에 대한 이유는 다양하지만 솔직히 말해서 프레임 워크 작성자는 처음에는 MVC의 서버 측 해석을보고 클라이언트 측에서 1 : 1로 변환하지 않고 C에서 다시 해석합니다. MVC는 자신이 느끼는 것을 더 의미있게 만듭니다. 그러나이 문제는 주관적이며 고전적인 MVC 패턴을 이해하고 현대 프레임 워크에서 컨트롤러의 역할을 이해하는 데있어 복잡성을 증가시킵니다.

예를 들어 인기있는 아키텍처 프레임 워크 Backbone.js의 아키텍처를 간단히 살펴 보겠습니다. 백본에는 모델과 뷰가 포함되어 있지만 (이전에 살펴본 것과 다소 비슷 함) 실제로는 진정한 컨트롤러가 없습니다. 뷰와 라우터는 컨트롤러와 조금 비슷하게 작동하지만 컨트롤러 자체는 실제로 컨트롤러가 아닙니다.

이 점에서 공식 문서 나 블로그 게시물에 언급 된 것과는 달리 Backbone은 진정한 MVC / MVP 또는 MVVM 프레임 워크가 아닙니다. 실제로 아키텍처를 자체 방식으로 접근하는 MV * 제품군의 구성원이라고 생각하는 것이 좋습니다. 물론 이것에는 아무런 문제가 없습니다. 그러나 고전 MVC와 MV *를 구별하는 것이 중요합니다. MVC와 MV *는 고전 문학의 조언에 의존해야합니다.

Controllers in another library (Spine.js) vs Backbone.js

Spine.js

이제 사용자가 뷰를 업데이트 할 때 모델을 업데이트하는 컨트롤러는 전통적으로 컨트롤러를 담당한다는 것을 알게되었습니다. 글을 쓰는 시점에서 가장 인기있는 JavaScript MVC / MV * 프레임 워크에는 컨트롤러에 대한 명시적인 개념이 없다는 점이 흥미 롭습니다.

따라서 다른 MVC 프레임 워크에서 컨트롤러를 검토하여 구현의 차이점을 이해하고 비 전통적 프레임 워크가 컨트롤러의 역할에 어떻게 접근 하는지를 입증하는 것이 유용 할 수 있습니다. 이를 위해 Spine.js의 샘플 컨트롤러를 살펴 보겠습니다.

이 예제에서는 PhotosController라는 컨트롤러를 사용하여 응용 프로그램의 개별 사진을 담당하게됩니다. 보기가 업데이트 될 때 (예 : 사용자가 사진 메타 데이터를 편집 할 때) 해당 모델도 확인합니다.

참고 : 우리는 Spine.js를 집중적으로 파고 들지는 않겠지 만, 컨트롤러가 할 수있는 일에 대해 10 피트 크기로 볼 것입니다.

// Controllers in Spine are created by inheriting from Spine.Controller

var PhotosController = Spine.Controller.sub({

  init: function () {
    this.item.bind( "update", this.proxy( this.render ));
    this.item.bind( "destroy", this.proxy( this.remove ));
  },

  render: function () {
    // Handle templating
    this.replace( $( "#photoTemplate" ).tmpl( this.item ) );
    return this;
  },

  remove: function () {
    this.el.remove();
    this.release();
  }
});

Spine에서 컨트롤러는 DOM 이벤트를 추가 및 응답하고, 템플릿을 렌더링하고, 뷰와 모델을 동기화 상태로 유지하는 응용 프로그램의 풀로 간주됩니다. 이는 컨트롤러로 알고있는 컨텍스트에서 의미가 있습니다.

위의 예제에서 우리가 수행하는 작업은 render()및 remove()를 사용하여 update 리스너를 설정하고 이벤트를 destroy 하는 것입니다. 사진 항목이 업데이트되면 메타 데이터의 변경 사항을 반영하도록보기를 다시 렌더링합니다. 마찬가지로 사진이 갤러리에서 삭제되면보기에서 사진이 삭제됩니다. render()함수에서 #photoTemplate ID로 자바 스크립트 템플릿을 렌더링하기 위해 Underscore 마이크로 템플릿 (_.template()을 통해)을 사용하고 있습니다. 이것은 단순히 photoEl의 내용을 채우는 데 사용되는 컴파일 된 HTML 문자열을 반환합니다.

이것이 우리에게 제공하는 것은 모델과 뷰 간의 변경을 관리하는 매우 가볍고 간단한 방법입니다.

Backbone.js

이 섹션의 뒷부분에서 Backbone과 기존 MVC의 차이점을 다시 살펴 보 겠지만 지금은 컨트롤러에 중점을 두어 설명하겠습니다.

Backbone에서는 컨트롤러의 책임을 Backbone.View와 Backbone.Router와 공유합니다. 얼마 전 Backbone은 자신의 Backbone.Controller를 사용 했었지만이 구성 요소의 이름이 사용 된 컨텍스트에 맞지 않아 나중에 이름이 라우터로 바뀌 었습니다.

라우터는 모델에 이벤트를 바인딩하고 DOM 이벤트에 응답하고 렌더링하는 것이 가능하기 때문에 컨트롤러 책임을 조금 더 처리합니다. Tim Branyen (다른 Bocoup 기반 Backbone 기여자)도 이전에 지적했듯이, Backbone.Router을 필요로하지 않고 도망 갈 수 있습니다. 라우터 라운드 패러다임을 사용하여 생각하는 방법은 아마도 다음과 같습니다.

var PhotoRouter = Backbone.Router.extend({
  routes: { "photos/:id": "route" },

  route: function( id ) {
    var item = photoCollection.get( id );
    var view = new PhotoView( { model: item } );

    $('.content').html( view.render().el );
  }
});

요약하면,이 섹션에서는 컨트롤러가 애플리케이션의 모델과 뷰 사이의 로직 및 조정을 관리한다는 점을 설명합니다.

What does MVC give us?

이러한 MVC에서의 관심사의 분리는 응용 프로그램의 기능을 보다 간단하게 모듈화하여 다음을 가능하게합니다.

  • 전체 유지 보수가 쉬워졌습니다. 응용 프로그램에 대한 업데이트가 필요할 때 변경 사항이 데이터 중심인지, 모델 및 컨트롤러의 변경을 의미하는지 아니면 단순히 시각적 인 의미인지에 대한 변경 사항이 매우 명확합니다.
  • 모델과 뷰를 분리하면 비즈니스 논리에 대한 단위 테스트를 작성하는 것이 훨씬 간단합니다.
  • 저수준 모델 및 컨트롤러 코드 (즉, 우리가 대신 사용해 왔던 코드)의 복제가 애플리케이션에서 제거됩니다.
  • 응용 프로그램의 크기와 역할 분리에 따라이 모듈화 방식을 사용하면 사용자 인터페이스에서 작업하는 핵심 논리 및 개발자를 담당하는 개발자가 동시에 작업 할 수 있습니다

Smalltalk-80 MVC In JavaScript

대다수의 현대 자바 스크립트 프레임 워크는 웹 애플리케이션 개발의 다양한 요구 사항에 더 잘 부합하도록 MVC 패러다임을 발전 시키려고 시도하지만 스몰 토크 -80에서 발견 된 순수한 형태의 패턴을 고수하려고하는 프레임 워크가 있습니다. Peter Michaux의 Maria.js (https://github.com/petermichaux/maria)는 MVC의 기원에 충실한 구현을 제공합니다. 모델은 모델이고 뷰는 뷰이며 컨트롤러는 컨트롤러입니다. 일부 개발자는 MV * 프레임 워크가 더 많은 문제를 해결해야한다고 생각할 수도 있지만, 이것은 원래 MVC의 JavaScript 구현을 원할 경우를 대비하여 유용하게 참고할 수 있습니다.

Delving deeper

이 책의이 시점에서 우리는 MVC 패턴이 제공하는 것을 기본적으로 이해해야 하지만 주목할 가치가 있는 정보가 있습니다.

GoF는 MVC를 디자인 패턴으로 지칭하는 것이 아니라 사용자 인터페이스를 작성하는 클래스 세트라고 생각합니다. 그들의 견해로는 실제로 Observer, Strategy 및 Composite 패턴의 세 가지 고전적인 디자인 패턴의 변형입니다. MVC가 프레임 워크에서 구현 된 방법에 따라 Factory 및 Template 패턴을 사용할 수도 있습니다. GoF 책은 MVC로 작업 할 때 이러한 패턴을 유용한 추가 기능으로 언급합니다.

앞에서 설명한 것처럼 모델은 응용 프로그램 데이터를 나타내지 만 화면은 사용자가 화면에 표시 한 것입니다. 따라서 MVC는 Observer 패턴을 핵심 커뮤니케이션의 일부로 사용합니다 (MVC 패턴에 대한 많은 기사에서 놀랍게도 다루지 않은 사항). 모델이 변경되면 관찰자 (Views)에게 무언가가 업데이트되었음을 ​​알립니다. 이는 아마도 MVC에서 가장 중요한 관계 일 것입니다. 이 관계의 관측자 특성은 동일한 모델에 여러 뷰가 첨부되는 것을 용이하게합니다.

MVC의 분리 된 특성 (구현에 따라 다름)에 대해 더 알고 싶은 개발자의 경우 패턴의 목표 중 하나는 주제 (데이터 객체)와 관찰자 간의 일대 다 관계를 정의하는 것입니다. 주제가 변경되면 옵서버가 업데이트됩니다. 뷰와 컨트롤러는 약간 다른 관계가 있습니다. 컨트롤러는보기가 다른 사용자 입력에 응답하는 것을 용이하게하며 전략 패턴의 한 예입니다.

Summary

고전적인 MVC 패턴을 검토 한 결과 이제 애플리케이션에서 문제를 명확하게 구분할 수있는 방법을 이해해야합니다. 우리는 또한 MVC 프레임 워크의 해석에서 JavaScript MVC 프레임 워크가 어떻게 다른지 알 수 있습니다. MVC 패턴은 변형이 가능하지만 원래 패턴이 제공해야하는 몇 가지 기본 개념을 여전히 공유합니다.

새로운 JavaScript MVC / MV * 프레임 워크를 검토 할 때, 아키텍처에 접근하는 방법 (모델, 뷰, 컨트롤러 또는 다른 대안의 구현을 지원하는 방법)으로 되돌아가 검토하는 것이 유용 할 수 있습니다. 프레임 워크가 어떻게 사용될 것으로 기대되는지를 기술합니다.

results matching ""

    No results matching ""