nagyon kevés, ha bármilyen építészeti JavaScript keretrendszerek, amelyek azt állítják, hogy végre az MVC vagy MVP minták a klasszikus forma, annyi JavaScript fejlesztők nem megtekintése MVC meg MVP-nek, mint az, hogy kölcsönösen kizárják egymást (több valószínű, hogy MVP szigorúan végrehajtott ha ránézünk a webes keretrendszerek, mint ASP.NET vagy GWT). Ez azért van, mert lehetséges, hogy további presenter/view logika az alkalmazás, és még mindig úgy vélik, hogy egy íz MVC.

a bostoni székhelyű Bocoup Gerinchálózata, Irene Ross ezt a gondolkodásmódot támogatja, mivel amikor elválasztja a nézeteket a saját különálló összetevőiktől, szüksége van valamire, hogy ténylegesen összeállítsa őket neki. Ez lehet egy vezérlő útvonal (például egy Backbone.Router, amelyet később a könyv tartalmaz), vagy visszahívás a beolvasott adatokra válaszul.

Ez azt jelenti, hogy egyes fejlesztők ezt a gerincet érzik.a js jobban illeszkedik az MVP leírásához, mint az MVC. Véleményük szerint:

erre az lehet A válasz, hogy a nézet is csak nézet lehet (MVC szerint), mert a gerinc elég rugalmas ahhoz, hogy több célra is használható legyen. A V az MVC – ben és a P az MVP-ben egyaránt megvalósítható a Backbone.View segítségével, mivel két célt tudnak elérni: mind az atomkomponensek renderelését, mind az összetevők más nézetek által történő összeszerelését.

azt is láttuk, hogy a gerinchálózatban a vezérlő felelősségét megosztják mind a Backbone.View, mind a Backbone.Router és a következő példában valójában láthatjuk, hogy ennek szempontjai minden bizonnyal igazak.

gerincünk PhotoView a megfigyelő mintát használja a” feliratkozáshoz”a Nézet modelljének a this.model.bind("change",...)sorban történő módosításához. A render() metódusban is kezeli a sablonokat, de más implementációktól eltérően a felhasználói interakciót a nézetben is kezelik (lásd 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(); }});

egy másik (egészen más) vélemény szerint a gerinc jobban hasonlít a Smalltalk-80 MVC-re, amelyen korábban mentünk keresztül.

ahogy a rendszeres gerinchálózat-blogger Derick Bailey korábban fogalmazott, végső soron a legjobb, ha nem kényszerítjük a gerincet, hogy illeszkedjen bármilyen egyedi tervezési mintához. Tervezési minták kell tekinteni, rugalmas vezetőket, hogy az alkalmazások lehetnek strukturált, s ebben a tekintetben, Gerince illik sem MVC, sem MVP. Ehelyett a legjobb koncepciók egy részét több építészeti mintából kölcsönzi, és egy rugalmas keretet hoz létre, amely csak jól működik.

érdemes azonban megértése, hol, miért ezeket a fogalmakat származik, így remélem, hogy az a magyarázat, MVC, valamint MVP volna segíteni. Nevezzük a gerinc utat, MV*, vagy bármi, ami segít hivatkozni az ízét alkalmazás architektúra. A legtöbb strukturális JavaScript-keretrendszer saját, akár szándékosan, akár véletlenül a klasszikus mintákat veszi át, de a lényeg az, hogy segítenek nekünk olyan alkalmazások fejlesztésében, amelyek szervezettek, tiszták, könnyen karbantarthatók.