Er zijn zeer weinig architectonische JavaScript-frameworks die beweren dat ze de MVC-of MVP-patronen in hun klassieke vorm implementeren, omdat veel JavaScript-ontwikkelaars MVC en MVP niet zien als elkaar uitsluiten (we hebben eigenlijk meer kans om MVP strikt geïmplementeerd te zien als we kijken naar Web frameworks zoals ASP.NET of GWT). Dit komt omdat het mogelijk is om extra presentator/view logica in onze applicatie te hebben en nog steeds beschouwen als een smaak van MVC.

Backbone contributor van Bocoup Irene Ros uit Boston onderschrijft deze manier van denken, omdat ze iets nodig heeft om ze daadwerkelijk samen te stellen. Dit kan een controller route zijn (zoals een Backbone.Router, die later in het boek wordt behandeld), of een callback als reactie op gegevens die worden opgehaald.

Dat gezegd hebbende, sommige ontwikkelaars voelen die Backbone.js past beter bij de beschrijving van MVP dan MVC. Hun weergave is dat:

een antwoord hierop kan zijn dat de weergave ook gewoon een weergave kan zijn (zoals per MVC), omdat Backbone flexibel genoeg is om het voor meerdere doeleinden te kunnen gebruiken. De V in MVC en de P in MVP kunnen beide worden bereikt door Backbone.View omdat ze in staat zijn om twee doelen te bereiken: zowel het renderen van atomaire componenten als het assembleren van die componenten die door andere weergaven worden weergegeven.

we hebben ook gezien dat in Backbone de verantwoordelijkheid van een controller gedeeld wordt met zowel Backbone.View en Backbone.Router en in het volgende voorbeeld kunnen we eigenlijk zien dat aspecten daarvan zeker waar zijn.

onze Backbone PhotoView gebruikt het Waarnemerspatroon om te” abonneren”op Wijzigingen in het model van een weergave in de regel this.model.bind("change",...). Het behandelt ook templating in de render() methode, maar in tegenstelling tot sommige andere implementaties, gebruikersinteractie wordt ook behandeld in de View (Zie 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(); }});

een andere (heel andere) mening is dat Backbone meer lijkt op Smalltalk-80 MVC, waar we eerder doorheen gingen.

zoals de gewone Backbone-blogger Derick Bailey het al eerder zei, is het uiteindelijk het beste om Backbone niet te forceren om te passen bij specifieke ontwerppatronen. Ontwerppatronen moeten worden beschouwd als flexibele handleidingen voor hoe toepassingen kunnen worden gestructureerd, en in dit opzicht past Backbone noch MVC noch MVP. In plaats daarvan leent het een aantal van de beste concepten uit meerdere architectonische patronen en creëert een flexibel kader dat gewoon goed werkt.

Het is echter de moeite waard om te begrijpen waar en waarom deze concepten ontstaan, dus ik hoop dat mijn uitleg van MVC en MVP hebben geholpen. Noem het de Backbone way, MV*, of wat dan ook helpt verwijzen naar de smaak van de applicatie-architectuur. De meeste structurele Javascript frameworks zullen hun eigen kijk op klassieke patronen te nemen, opzettelijk of per ongeluk, maar het belangrijkste is dat ze ons helpen bij het ontwikkelen van applicaties die zijn georganiseerd, schoon, en kan gemakkelijk worden onderhouden.