det er svært få, om noen arkitektoniske JavaScript-rammer som hevder å implementere MVC-eller MVP-mønstrene i sin klassiske form, så mange JavaScript-utviklere ser IKKE MVC og MVP som gjensidig utelukkende (vi er faktisk mer sannsynlig å se MVP strengt implementert når vi ser på webrammer som ASP.NET ELLER GWT). Dette er fordi det er mulig å ha ekstra presenter / view logikk i vår søknad og fortsatt anser det som en smak AV MVC.Backbone bidragsyter Av Boston-baserte Bocoup Irene Ros abonnerer på denne tankegangen, som når hun skiller synspunkter ut i sine egne distinkte komponenter, trenger hun noe å faktisk montere dem for henne. Dette kan enten være en kontrollerrute (for eksempel en Backbone.Router, dekket senere i boken), eller en tilbakeringing som svar på data som hentes.

Når det er sagt, føler noen utviklere At Ryggraden.js passer bedre til beskrivelsen AV MVP enn DEN GJØR MVC. Deres syn er at:

et svar på dette kan være at visningen også bare kan Være En Visning (som PER MVC), fordi Ryggraden er fleksibel nok til å la den brukes til flere formål. V i MVC og P I MVP kan begge oppnås ved Backbone.View fordi de er i stand til å oppnå to formål: både gjengivelse av atomkomponenter og montering av disse komponentene gjengitt av andre visninger.

Vi har også sett At I Backbone er ansvaret for en kontroller delt med både Backbone.View og Backbone.Router og i det følgende eksemplet kan vi faktisk se at aspekter av det er sikkert sant.

Vår RyggradPhotoView bruker Observatørmønsteret til å «abonnere»på endringer I En Visningsmodell i linjen this.model.bind("change",...). Den håndterer også templering irender() – metoden, men i motsetning til enkelte andre implementeringer håndteres brukerinteraksjon også I Visningen (seevents).

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 annen (ganske annen) oppfatning er At Ryggraden mer ligner Smalltalk-80 MVC, som vi gikk gjennom tidligere.som vanlig Backbone blogger Derick Bailey tidligere har sagt det, er det til slutt best å ikke tvinge Backbone til å passe til noen spesifikke designmønstre. Designmønstre bør betraktes som fleksible guider til hvordan applikasjoner kan struktureres, og I denne forbindelse passer Ryggraden verken MVC eller MVP. I stedet låner den noen av de beste konseptene fra flere arkitektoniske mønstre og skaper et fleksibelt rammeverk som bare fungerer bra.Det er imidlertid verdt å forstå hvor og hvorfor disse konseptene oppsto, så jeg håper at mine forklaringer PÅ MVC og MVP har vært til hjelp. Kall Det Backbone way, MV*, eller hva som hjelper med å referere til smaken av applikasjonsarkitektur. De fleste Strukturelle JavaScript-rammer vil vedta sin egen ta på klassiske mønstre, enten med vilje eller ved et uhell, men det viktigste er at de hjelper oss med å utvikle applikasjoner som er organisert, rene og lett vedlikeholdt.