der er meget få, hvis nogen arkitektoniske JavaScript-rammer, der hævder at implementere MVC-eller MVP-mønstre i deres klassiske form, da mange JavaScript-udviklere ikke ser MVC og MVP som gensidigt eksklusive (vi er faktisk mere tilbøjelige til at se MVP strengt implementeret, når man ser på ASP.NET eller GT). Dette skyldes, at det er muligt at have yderligere præsentations – /visningslogik i vores applikation og stadig betragte det som en smag af MVC.Backbone bidragyder af Boston-baserede Bocoup Irene Ros abonnerer på denne måde at tænke på, som når hun adskiller synspunkter ud i deres egne særskilte komponenter, hun har brug for noget til rent faktisk at samle dem for hende. Dette kan enten være en controllerrute (såsom en Backbone.Router, dækket senere i bogen) eller et tilbagekald som svar på data, der hentes.

når det er sagt, føler nogle udviklere den rygrad.js passer bedre til beskrivelsen af MVP end den gør MVC. Deres opfattelse er, at:

et svar på dette kan være, at visningen også bare kan være en visning (som pr MVC), fordi rygraden er fleksibel nok til at lade den bruges til flere formål. V i MVC og P i MVP kan begge opnås ved Backbone.View fordi de er i stand til at opnå to formål: både gengivelse af atomkomponenter og samling af disse komponenter gengivet af andre synspunkter.

Vi har også set, at ansvaret for en controller i Backbone deles med begge Backbone.View og Backbone.Router og i det følgende eksempel kan vi faktisk se, at aspekter af det helt sikkert er sandt.

vores rygrad PhotoView bruger Observatørmønsteret til at” abonnere”på ændringer i en visnings model i linjen this.model.bind("change",...). Det håndterer også templating i render() – metoden, men i modsætning til nogle andre implementeringer håndteres brugerinteraktion også i visningen (se 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(); }});

en anden (helt anden) mening er, at rygraden mere ligner Smalltalk-80 MVC, som vi gik igennem tidligere.

som almindelig Backbone blogger Derick Bailey tidligere har sagt det, er det i sidste ende bedst ikke at tvinge Backbone til at passe til specifikke designmønstre. Designmønstre bør betragtes som fleksible vejledninger til, hvordan applikationer kan struktureres, og i denne henseende passer Backbone hverken MVC eller MVP. I stedet låner det nogle af de bedste koncepter fra flere arkitektoniske mønstre og skaber en fleksibel ramme, der bare fungerer godt.

det er dog værd at forstå, hvor og hvorfor disse begreber stammer fra, så jeg håber, at mine forklaringer på MVC og MVP har været til hjælp. Kald det rygraden, MV*, eller hvad der hjælper med at henvise til dens smag af applikationsarkitektur. De fleste strukturelle JavaScript-rammer vil vedtage deres eget tag på klassiske mønstre, enten med vilje eller ved et uheld, men det vigtige er, at de hjælper os med at udvikle applikationer, der er organiserede, rene og let kan vedligeholdes.