Django contre le contrôleur de vue de modèle
Quelqu'un peut-il m'expliquer où sont les différences entre Django et le modèle Model View Controller?)
Fonctionnellement, que pouvons-nous attendre de ces différences - c’est-à-dire qui fonctionne différemment en comparant Django à, par exemple, Ruby sur Rails?)?
Selon le Django Book , Django suit suffisamment le modèle MVC pour être appelé un framework MVC.
Django a été qualifié de framework MTV parce que le contrôleur est géré par le framework lui-même et que l'excitation se produit principalement dans les modèles, les modèles et les vues.
Vous pouvez en savoir plus sur MTV/MVC ici:
Le modèle de développement MTV (ou MVC)
Si vous connaissez d’autres frameworks de développement Web MVC, tels que Ruby sur Rails, vous pouvez considérer Django comme étant les vues contrôleurs et Django les modèles sont les vues .
C'est une confusion malheureuse provoquée par différentes interprétations de MVC.
Dans l’interprétation de MVC par Django, la vue décrit les données présentées à l’utilisateur; l’apparence des données, mais les données présentées.
En revanche, Ruby sur Rails et des cadres similaires suggèrent que le travail du contrôleur inclut le choix des données à présenter à l'utilisateur, alors que la vue est strictement comment les données sont présentées. regarde, pas quelles données sont présentées.
Le Django FAQ est en soi un bon endroit pour commencer:
Dans notre interprétation de MVC, la "vue" décrit les données présentées à l'utilisateur. Ce n’est pas nécessairement l’apparence des données, mais les données présentées. La vue décrit quelles données vous voyez, pas comment vous les voyez. C’est une distinction subtile.
...
En outre, il est judicieux de séparer le contenu de la présentation - c’est là que les modèles entrent en jeu. Dans Django, une "vue" décrit les données présentées, mais une vue délègue normalement un modèle, qui décrit la manière dont les données sont présentées.
Où se situe le "contrôleur", alors? Dans le cas de Django, il s’agit probablement du cadre lui-même: la machine qui envoie une demande à la vue appropriée, selon la configuration de l’URL Django.
Si vous êtes avide d'acronymes, vous pouvez dire que Django est un framework “MTV” - c'est-à-dire “modèle”, “modèle” et “vue”. Cette ventilation en fait beaucoup plus sens.
Gardez à l’esprit que "Model View Controller" n’est qu’un motif, c’est-à-dire une tentative de description d’une architecture commune. Donc, une meilleure question pourrait être: "Dans quelle mesure Django correspond-il au modèle de contrôleur de vue de modèle?
Lorsque vous codez, sans penser aux noms des éléments du framework, il n'y a pas de différences substantielles entre, par exemple, RoR. Mais cela dépend de l'utilisation que vous donnez à models, puisque Django), ils contiennent facilement une logique qui, dans d'autres cadres, resterait au niveau du contrôleur.
Le view on Django a tendance à être un ensemble de requêtes permettant d'extraire des données et de les transmettre au modèle.
Dans MVT, une demande à une URL est envoyée à une vue. Cette vue appelle le modèle, effectue des manipulations et prépare les données pour la sortie. Les données sont transmises à un modèle qui est rendu en réponse. idéalement, dans les cadres Web, le contrôleur est masqué.
C'est là que réside la différence par rapport à MVC: dans mvc, l'utilisateur interagit avec l'interface graphique, le contrôleur gère la demande, notifie le modèle et la vue interroge le modèle pour afficher le résultat à l'utilisateur.