MVC, MVP et Backbone.js
Il y a très peu de frameworks JavaScript architecturaux, voire aucun, qui prétendent implémenter les modèles MVC ou MVP dans leur forme classique, car de nombreux développeurs JavaScript ne considèrent pas MVC et MVP comme s’excluant mutuellement (nous sommes en fait plus susceptibles de voir MVP strictement implémenté en regardant des frameworks Web tels que ASP.NET ou GWT). En effet, il est possible d’avoir une logique de présentation / vue supplémentaire dans notre application et de la considérer toujours comme une saveur de MVC.
La contributrice Backbone de Bocoup basée à Boston, Irene Ros, souscrit à cette façon de penser, car lorsqu’elle sépare les vues en leurs propres composants distincts, elle a besoin de quelque chose pour les assembler pour elle. Cela peut être une route de contrôleur (telle qu’un Backbone.Router
, couvert plus loin dans le livre), ou un rappel en réponse à la récupération des données.
Cela dit, certains développeurs ressentent cette épine dorsale.js correspond mieux à la description de MVP qu’à MVC. Leur point de vue est le suivant :
-
Le présentateur dans MVP décrit mieux le
Backbone.View
(la couche entre les modèles de vue et les données qui y sont liées) qu’un contrôleur. -
Le modèle correspond à
Backbone.Model
(il n’est pas du tout très différent des modèles de MVC). -
Les vues représentent le mieux les modèles (par exemple, les modèles de balisage de guidon/Moustache).
Une réponse à cela pourrait être que la vue peut également être simplement une vue (selon MVC), car Backbone est suffisamment flexible pour pouvoir être utilisée à plusieurs fins. Le V dans MVC et le P dans MVP peuvent tous deux être accomplis par Backbone.View
car ils sont capables d’atteindre deux objectifs: à la fois le rendu des composants atomiques et l’assemblage de ces composants rendus par d’autres vues.
Nous avons également vu que dans Backbone, la responsabilité d’un contrôleur est partagée à la fois avec Backbone.View
et Backbone.Router
et dans l’exemple suivant, nous pouvons voir que certains aspects de cela sont certainement vrais.
Notre colonne vertébrale PhotoView
utilise le modèle d’observateur pour « s’abonner” aux modifications apportées au modèle d’une vue dans la ligne this.model.bind("change",...)
. Il gère également les modèles dans la méthode render()
, mais contrairement à d’autres implémentations, l’interaction de l’utilisateur est également gérée dans la vue (voir 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
();
}
});
Une autre opinion (assez différente) est que Backbone ressemble plus à Smalltalk-80 MVC, que nous avons traversé plus tôt.
Comme l’a déjà dit le blogueur régulier de Backbone, Derick Bailey, il est finalement préférable de ne pas forcer Backbone à s’adapter à des modèles de conception spécifiques. Les modèles de conception doivent être considérés comme des guides flexibles sur la façon dont les applications peuvent être structurées, et à cet égard, Backbone ne convient ni au MVC ni au MVP. Au lieu de cela, il emprunte certains des meilleurs concepts à de multiples modèles architecturaux et crée un cadre flexible qui fonctionne bien.
Il vaut cependant la peine de comprendre d’où et pourquoi ces concepts sont nés, j’espère donc que mes explications sur MVC et MVP ont été utiles. Appelez-le la méthode Backbone, MV *, ou tout ce qui aide à référencer sa saveur d’architecture d’application. La plupart des frameworks JavaScript structurels adopteront leur propre approche des modèles classiques, intentionnellement ou par accident, mais l’important est qu’ils nous aident à développer des applications organisées, propres et faciles à entretenir.