Es gibt nur sehr wenige, wenn überhaupt architektonische JavaScript-Frameworks, die behaupten, die MVC- oder MVP-Muster in ihrer klassischen Form zu implementieren, da viele JavaScript-Entwickler MVC und MVP nicht als sich gegenseitig ausschließend betrachten (wir sehen MVP tatsächlich eher streng implementiert, wenn wir uns Web-Frameworks wie ASP.NET oder GWT). Dies liegt daran, dass es möglich ist, zusätzliche Presenter / View-Logik in unserer Anwendung zu haben und sie dennoch als eine Variante von MVC zu betrachten.

Irene Ros, Mitwirkende von Bocoup in Boston, verfolgt diese Denkweise, denn wenn sie Ansichten in ihre eigenen Komponenten aufteilt, braucht sie etwas, um sie tatsächlich für sie zusammenzustellen. Dies kann entweder eine Controller-Route sein (z. B. eine Backbone.Router , die später im Buch behandelt wird) oder ein Rückruf als Antwort auf das Abrufen von Daten.

Das heißt, einige Entwickler fühlen sich das Rückgrat.js passt besser zur Beschreibung von MVP als MVC. Ihre Ansicht ist, dass:

Eine Antwort darauf könnte sein, dass die Ansicht auch nur eine Ansicht sein kann (gemäß MVC), da Backbone flexibel genug ist, um sie für mehrere Zwecke verwenden zu können. Das V in MVC und das P in MVP können beide mit Backbone.View erreicht werden, da sie zwei Zwecke erreichen können: sowohl das Rendern atomarer Komponenten als auch das Zusammenstellen dieser Komponenten, die von anderen Ansichten gerendert wurden.

Wir haben auch gesehen, dass in Backbone die Verantwortung eines Controllers sowohl mit Backbone.View als auch mit Backbone.Router geteilt wird Im folgenden Beispiel können wir tatsächlich sehen, dass Aspekte davon sicherlich wahr sind.

Unser Backbone PhotoView verwendet das Beobachtermuster, um Änderungen am Modell einer Ansicht in der Zeile this.model.bind("change",...) zu „abonnieren“. Es behandelt auch Vorlagen in der render() -Methode, aber im Gegensatz zu einigen anderen Implementierungen wird die Benutzerinteraktion auch in der Ansicht behandelt (siehe 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(); }});

Eine andere (ganz andere) Meinung ist, dass Backbone Smalltalk-80 MVC, das wir zuvor durchlaufen haben, eher ähnelt.

Wie der regelmäßige Backbone-Blogger Derick Bailey zuvor gesagt hat, ist es letztendlich am besten, Backbone nicht zu zwingen, bestimmte Entwurfsmuster anzupassen. Entwurfsmuster sollten als flexible Anleitungen für die Strukturierung von Anwendungen angesehen werden, und in dieser Hinsicht passt Backbone weder zu MVC noch zu MVP. Stattdessen leiht es sich einige der besten Konzepte aus mehreren Architekturmustern aus und schafft ein flexibles Framework, das einfach gut funktioniert.

Es lohnt sich jedoch zu verstehen, wo und warum diese Konzepte entstanden sind, daher hoffe ich, dass meine Erklärungen zu MVC und MVP hilfreich waren. Nennen Sie es den Backbone-Weg, MV *, oder was auch immer hilft, seinen Geschmack der Anwendungsarchitektur zu referenzieren. Die meisten strukturellen JavaScript-Frameworks übernehmen ihre eigenen klassischen Muster, entweder absichtlich oder zufällig, aber das Wichtigste ist, dass sie uns helfen, Anwendungen zu entwickeln, die organisiert, sauber und leicht zu warten sind.