on olemassa hyvin vähän, jos mitään arkkitehtonisia JavaScript-kehyksiä, jotka väittävät toteuttavansa MVC: n tai MVP: n mallit klassisessa muodossaan, koska monet JavaScript-kehittäjät eivät pidä MVC: tä ja MVP: tä toisensa poissulkevina (olemme itse asiassa todennäköisemmin MVP: tä tiukasti toteutettuna, kun tarkastellaan web-kehyksiä, kuten ASP.NET tai GWT). Tämä johtuu siitä, että on mahdollista saada lisää juontaja/view logiikkaa hakemuksessamme ja silti pitää sitä maku MVC.

bostonilaisen Bocoupin Runkovaikuttaja Irene Ros yhtyy tähän ajattelutapaan, sillä kun hän erottaa näkemykset omiksi erillisiksi osikseen, hän tarvitsee jotain, joka todella kokoaa ne häntä varten. Tämä voi olla joko rekisterinpitäjän reitti (kuten Backbone.Router, joka on käsitelty myöhemmin kirjassa), tai takaisinkutsu vastauksena datan hakemiseen.

tämä sanoi, jotkut kehittäjät eivät tunne, että selkäranka.js sopii paremmin MVP: n kuvaukseen kuin MVC. Heidän näkemyksensä on, että:

vastaus tähän voisi olla, että näkymä voi olla myös pelkkä näkymä (MVC: n mukaan), koska selkäranka on riittävän joustava, jotta sitä voidaan käyttää useisiin tarkoituksiin. MVC: n V ja MVP: n P voidaan molemmat saavuttaa Backbone.View, koska niillä voidaan saavuttaa kaksi tarkoitusta: sekä renderoida atomikomponentit että koota ne muiden näkemysten renderöimät komponentit.

olemme myös nähneet, että Backbonessa kontrollerin vastuu on jaettu sekä Backbone.View että Backbone.Router ja seuraavassa esimerkissä voimme itse asiassa nähdä, että osa siitä on varmasti totta.

Runkomme PhotoView käyttää Havainnoitsijakuviota ”merkitäkseen” näkymän mallin muutoksia rivillä this.model.bind("change",...). Se käsittelee templointia myös render() – menetelmällä, mutta toisin kuin eräät muut toteutukset, käyttäjien vuorovaikutusta käsitellään myös näkymässä (katso 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(); }});

toinen (aivan erilainen) mielipide on, että Backbone muistuttaa enemmän Smalltalk-80 MVC: tä, jonka kävimme läpi aiemmin.

kuten tavallinen Runkobloggaaja Derick Bailey on aiemmin asian ilmaissut, on lopulta parasta olla pakottamatta selkärankaa sopimaan mihinkään tiettyyn suunnittelukuvioon. Suunnittelumalleja olisi pidettävä joustavina oppaina siitä, miten sovellukset voidaan jäsentää, ja tältä osin selkäranka ei sovi MVC: hen eikä MVP: hen. Sen sijaan se lainaa joitakin parhaita käsitteitä useista arkkitehtonisista kaavoista ja luo joustavat puitteet, jotka vain toimivat hyvin.

on kuitenkin syytä ymmärtää, mistä ja miksi nämä käsitteet ovat saaneet alkunsa, joten toivon, että selityksistäni MVC: stä ja MVP: stä on ollut apua. Kutsu sitä Backbone way, MV*, tai mikä tahansa auttaa viittaamaan sen maku sovellusarkkitehtuuri. Useimmat rakenteelliset JavaScript puitteet hyväksyy oman ottaa klassisia malleja, joko tarkoituksella tai vahingossa, mutta tärkeintä on, että ne auttavat meitä kehittämään sovelluksia, jotka ovat järjestettyjä, puhdas, ja voidaan helposti ylläpitää.