MVC、MVP、およびバックボーン。多くのJavaScript開発者がMVCとMVPを相互に排他的であるとは思わないので、MVCまたはMVPパターンを古典的な形式で実装すると主張するアーキテクチャJavaScriptフレームワークASP.NET またはGWT）。 これは、アプリケーションに追加のプレゼンター/ビューロジックを追加しても、それをMVCの味と見なすことができるためです。
ボストンベースのBocoup Irene Rosのバックボーン寄稿者は、ビューを独自のコンポーネントに分離するとき、実際にそれらを組み立てるために何かが必要なので、この考え方に加入しています。 これは、コントローラルート（この本の後半で説明するBackbone.Routerなど）、またはデータのフェッチに応答するコールバックのいずれかです。
それは言った、一部の開発者は、そのバックボーンを感じています。jsはMVCよりもMVPの説明に適しています。 MVPのプレゼンターは、コントローラよりもBackbone.ViewBackbone.Modelに適合します（MVCのモデルとまったく違いはありません）。
ビューは、テンプレートを最もよく表します(例:Handlebars/Mustacheマークアップテンプレート)。これに対する応答は、Backboneが複数の目的で使用できるように十分柔軟であるため、ビューを（MVCごとに）ビューにすることもできるということです。 MVCのVとMVPのPは、Backbone.View二つの目的を達成することができるので、アトミックコンポーネントをレンダリングすることと、他のビューによってレまた、Backboneでは、コントローラの責任がBackbone.ViewBackbone.RouterPhotoViewthis.model.bind("change",...)render()eventsを参照）。別の（全く異なる）意見は、Backboneが以前に行ったSmalltalk-80MVCにより密接に似ているということです。
通常のBackbone blogger Derick Baileyが以前にそれを入れているように、最終的にはBackboneを特定のデザインパターンに合わせないことが最善です。 設計パターンは、アプリケーションがどのように構造化されるかについての柔軟なガイドと考えるべきであり、この点でBackboneはMVCもMVPにも適合しません。 代わりに、複数のアーキテクチャパターンから最良の概念のいくつかを借りて、うまく機能する柔軟なフレームワークを作成します。しかし、これらの概念がどこで、なぜ生まれたのかを理解する価値があるので、MVCとMVPの説明が助けになることを願っています。 それをBackbone way、MV*、またはアプリケーションアーキテクチャの味を参照するのに役立つものと呼びます。 ほとんどの構造的なJavaScriptフレームワークは、意図的に、または偶然に、古典的なパターンに独自のテイクを採用しますが、重要なことは、それらが組織され、クリーン