Hay muy pocos marcos de JavaScript arquitectónicos que afirman implementar los patrones MVC o MVP en su forma clásica, ya que muchos desarrolladores de JavaScript no ven a MVC y MVP como mutuamente exclusivos (en realidad, es más probable que veamos MVP implementado estrictamente cuando miramos marcos web como ASP.NET o GWT). Esto se debe a que es posible tener lógica de presentador/vista adicional en nuestra aplicación y aún considerarla un tipo de MVC.

La colaboradora principal de Bocoup, con sede en Boston, Irene Ros, se suscribe a esta forma de pensar, ya que cuando separa las vistas en sus propios componentes distintos, necesita algo para ensamblarlas para ella. Esto podría ser una ruta de controlador (como un Backbone.Router, cubierto más adelante en el libro), o una devolución de llamada en respuesta a los datos que se obtienen.

Dicho esto, algunos desarrolladores sienten esa columna vertebral.js se ajusta mejor a la descripción de MVP que a MVC. Su punto de vista es el siguiente:

Una respuesta a esto podría ser que la vista también puede ser solo una vista (según MVC), porque Backbone es lo suficientemente flexible como para permitir que se use para múltiples propósitos. La V en MVC y la P en MVP se pueden lograr mediante Backbone.View porque pueden lograr dos propósitos: renderizar componentes atómicos y ensamblar los componentes renderizados por otras vistas.

también Hemos visto que en la Troncal de la responsabilidad de un controlador es compartido con Backbone.View y Backbone.Router y en el siguiente ejemplo, podemos ver que aspectos de los que son, sin duda, cierto.

Nuestro Backbone PhotoView utiliza el patrón de Observador para «suscribirse» a los cambios en el modelo de una vista en la línea this.model.bind("change",...). También maneja plantillas en el método render(), pero a diferencia de otras implementaciones, la interacción del usuario también se maneja en la vista (consulte 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(); }});

Otra opinión (bastante diferente) es que Backbone se parece más a Smalltalk-80 MVC, que analizamos anteriormente.

Como el blogger regular de Backbone Derick Bailey lo ha expresado anteriormente, en última instancia, es mejor no forzar a Backbone a adaptarse a ningún patrón de diseño específico. Los patrones de diseño deben considerarse guías flexibles sobre cómo se pueden estructurar las aplicaciones, y en este sentido, Backbone no se ajusta ni al MVC ni al MVP. En su lugar, toma prestados algunos de los mejores conceptos de múltiples patrones arquitectónicos y crea un marco flexible que simplemente funciona bien.

Sin embargo, vale la pena entender dónde y por qué se originaron estos conceptos, así que espero que mis explicaciones de MVC y MVP hayan sido de ayuda. Llámelo la forma de la columna vertebral, MV*, o lo que sea que ayude a hacer referencia a su sabor de arquitectura de aplicaciones. La mayoría de los marcos estructurales de JavaScript adoptarán su propia versión de los patrones clásicos, ya sea intencionalmente o por accidente, pero lo importante es que nos ayudan a desarrollar aplicaciones que están organizadas, limpias y se pueden mantener fácilmente.