det finns väldigt få, om några arkitektoniska JavaScript-ramar som hävdar att de implementerar MVC-eller MVP-mönstren i sin klassiska form, så många JavaScript-utvecklare ser inte MVC och MVP som ömsesidigt exklusiva (vi är faktiskt mer benägna att se MVP strikt implementerad när vi tittar på webbramar som ASP.NET eller GWT). Detta beror på att det är möjligt att ha ytterligare presentatör/visa logik i vår ansökan och fortfarande anser att det är en smak av MVC.

Backbone bidragsgivare av Boston-baserade Bocoup Irene Ros prenumererar på detta sätt att tänka, som när hon skiljer åsikter ut i sina egna distinkta komponenter, behöver hon något för att faktiskt montera dem för henne. Detta kan antingen vara en kontrollerväg (till exempel ett Backbone.Router, täckt senare i boken) eller en återuppringning som svar på data som hämtas.

som sagt, vissa utvecklare känner den ryggraden.js passar bättre beskrivningen av MVP än den gör MVC. Deras uppfattning är att:

ett svar på detta kan vara att vyn också bara kan vara en vy (enligt MVC), eftersom ryggraden är tillräckligt flexibel för att låta den användas för flera ändamål. V i MVC och P I MVP kan båda åstadkommas med Backbone.View eftersom de kan uppnå två syften: både rendering av atomkomponenter och montering av de komponenter som återges av andra vyer.

Vi har också sett att i Backbone delas ansvaret för en kontroller med både Backbone.View och Backbone.Router och i följande exempel kan vi faktiskt se att aspekter av det verkligen är sanna.

vår ryggrad PhotoViewanvänder Observatörsmönstret för att” prenumerera”på ändringar i en vys modell i radenthis.model.bind("change",...). Det hanterar också mallning irender() – metoden, men till skillnad från vissa andra implementeringar hanteras användarinteraktion också i vyn (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 annan (helt annan) åsikt är att ryggraden mer liknar Smalltalk-80 MVC, som vi gick igenom tidigare.

som vanlig Backbone blogger Derick Bailey tidigare har uttryckt det, är det i slutändan bäst att inte tvinga Backbone att passa några specifika designmönster. Designmönster bör betraktas som flexibla guider för hur applikationer kan struktureras, och i detta avseende passar Backbone varken MVC eller MVP. Istället lånar det några av de bästa koncepten från flera arkitektoniska mönster och skapar en flexibel ram som bara fungerar bra.

det är dock värt att förstå var och varför dessa begrepp har sitt ursprung, så jag hoppas att mina förklaringar av MVC och MVP har varit till hjälp. Kalla det ryggraden, MV*, eller vad som helst som hjälper till att referera till dess smak av applikationsarkitektur. De flesta strukturella JavaScript-ramar kommer att anta sina egna klassiska mönster, antingen avsiktligt eller av misstag, men det viktiga är att de hjälper oss att utveckla applikationer som är organiserade, rena och lätt kan underhållas.