istnieje bardzo niewiele, jeśli jakiekolwiek architektoniczne frameworki JavaScript, które twierdzą, że implementują wzorce MVC lub MVP w swojej klasycznej formie, ponieważ wielu programistów JavaScript nie postrzega MVC i MVP jako wzajemnie się wykluczających (jesteśmy bardziej skłonni zobaczyć MVP ściśle zaimplementowane, gdy patrzymy na frameworki internetowe, takie jak ASP.NET lub GWT). Dzieje się tak dlatego, że możliwe jest posiadanie dodatkowej logiki prezentera/widoku w naszej aplikacji i nadal uważa to za smak MVC.

współtwórczyni Bocoup z Bostonu Irene Ros zgadza się na ten sposób myślenia, ponieważ kiedy dzieli poglądy na ich własne, odrębne komponenty, potrzebuje czegoś, aby je właściwie zmontować. Może to być trasa kontrolera (taka jak Backbone.Router, opisana w dalszej części książki) lub wywołanie zwrotne w odpowiedzi na pobieranie danych.

To powiedziawszy, niektórzy deweloperzy czują ten kręgosłup.js lepiej pasuje do opisu MVP niż MVC. Ich zdaniem:

odpowiedzią na to może być to, że Widok może być po prostu widokiem (jak na MVC), ponieważ szkielet jest wystarczająco elastyczny, aby mógł być używany do wielu celów. V W MVC i P W MVP mogą być osiągnięte przez Backbone.View, ponieważ są w stanie osiągnąć dwa cele: zarówno renderowanie komponentów atomowych, jak i łączenie tych komponentów renderowanych przez inne widoki.

widzieliśmy również, że w Backbone odpowiedzialność kontrolera jest dzielona zarówno z Backbone.View, jak i Backbone.Router I w poniższym przykładzie widzimy, że aspekty tego są z pewnością prawdziwe.

nasz szkieletPhotoView wykorzystuje wzorzec obserwatora do „subskrybowania” zmian w modelu widoku w liniithis.model.bind("change",...). Obsługuje również szablony w metodzierender(), ale w przeciwieństwie do innych implementacji, interakcja użytkownika jest również obsługiwana w widoku (patrzevents).

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(); }});

inna (zupełnie inna) opinia jest taka, że Backbone bardziej przypomina Smalltalk-80 MVC, który przerabialiśmy wcześniej.

jak już wcześniej ujął to zwykły bloger Derick Bailey, najlepiej nie zmuszać szkieletu do dopasowywania się do konkretnych wzorców projektowych. Wzorce projektowe powinny być uważane za elastyczne wskazówki dotyczące struktury aplikacji, a pod tym względem szkielet nie pasuje ani do MVC, ani MVP. Zamiast tego pożycza jedne z najlepszych koncepcji z wielu wzorów architektonicznych i tworzy elastyczną strukturę, która po prostu działa dobrze.

warto jednak zrozumieć skąd i dlaczego powstały te pojęcia, więc mam nadzieję, że moje wyjaśnienia MVC i MVP były pomocne. Nazwij to Backbone way, MV* lub cokolwiek innego, co pomaga nawiązać do jego smaku architektury aplikacji. Większość strukturalnych frameworków JavaScript przyjmie swoje własne podejście do klasycznych wzorców, celowo lub przez przypadek, ale ważne jest to, że pomagają nam tworzyć aplikacje, które są zorganizowane, czyste i mogą być łatwo utrzymywane.