Ci sono pochissimi framework JavaScript architettonici che affermano di implementare i pattern MVC o MVP nella loro forma classica, poiché molti sviluppatori JavaScript non vedono MVC e MVP come reciprocamente esclusivi (in realtà è più probabile che MVP venga implementato rigorosamente quando si guardano framework web come MVP). ASP.NET o GWT). Questo perché è possibile avere una logica di presentatore/visualizzazione aggiuntiva nella nostra applicazione e considerarla ancora un sapore di MVC.

La collaboratrice Backbone di Bocoup con sede a Boston Irene Ros si iscrive a questo modo di pensare, come quando separa le viste nelle proprie componenti distinte, ha bisogno di qualcosa per assemblarle effettivamente per lei. Questo potrebbe essere un percorso del controller (come un Backbone.Router, trattato più avanti nel libro), o un callback in risposta ai dati che vengono recuperati.

Detto questo, alcuni sviluppatori sentono quella Spina dorsale.js si adatta meglio alla descrizione di MVP rispetto a MVC. La loro opinione è che:

Una risposta a questo potrebbe essere che la vista può anche essere solo una Vista (come da MVC), perché Backbone è abbastanza flessibile da consentirne l’uso per più scopi. Il V in MVC e il P in MVP possono essere entrambi realizzati da Backbone.View perché sono in grado di raggiungere due scopi: sia il rendering di componenti atomici che l’assemblaggio di quei componenti resi da altre viste.

Abbiamo anche visto che in Backbone la responsabilità di un controller è condivisa sia conBackbone.Viewche conBackbone.Router e nell’esempio seguente, possiamo effettivamente vedere che aspetti di ciò sono certamente veri.

Il nostro BackbonePhotoView utilizza il pattern Observer per “sottoscrivere” le modifiche al modello di una vista nella rigathis.model.bind("change",...). Gestisce anche i modelli nel metodorender(), ma a differenza di altre implementazioni, l’interazione dell’utente viene gestita anche nella Vista (vedereevents).

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(); }});

Un’altra opinione (abbastanza diversa) è che Backbone assomiglia più da vicino Smalltalk-80 MVC, che abbiamo esaminato in precedenza.

Come il blogger Backbone Derick Bailey lo ha precedentemente messo, in definitiva è meglio non forzare Backbone per adattarsi a schemi di progettazione specifici. I modelli di progettazione dovrebbero essere considerati guide flessibili su come le applicazioni possono essere strutturate e, a questo proposito, Backbone non si adatta né a MVC né MVP. Invece, prende in prestito alcuni dei migliori concetti da più modelli architettonici e crea un quadro flessibile che funziona bene.

Vale comunque la pena capire dove e perché questi concetti hanno avuto origine, quindi spero che le mie spiegazioni di MVC e MVP siano state di aiuto. Chiamalo Backbone way, MV*, o qualsiasi altra cosa aiuta a fare riferimento al suo sapore di architettura dell’applicazione. La maggior parte dei framework JavaScript strutturali adotterà il proprio approccio ai modelli classici, intenzionalmente o per caso, ma l’importante è che ci aiutino a sviluppare applicazioni organizzate, pulite e facilmente mantenibili.