Django vs Model View Controller [fermé]

110

Quelqu'un peut-il m'expliquer où se trouvent les différences entre Django et le modèle Model View Controller?

Fonctionnellement, que pouvons-nous attendre de ces différences - c'est-à-dire qu'est-ce qui fonctionne différemment en comparant Django à, par exemple, Ruby on Rails?

django model-view-controller frameworks

— Léonard
source

2

Lorsque vous dites «le» contrôleur de vue modèle, voulez-vous dire le modèle général ou une implémentation spécifique (comme Ruby on Rails)?

— Paul D.Waite

33

Cette question ne se qualifie pas comme «non constructive» et a une réponse simple sans «débat, arguments, sondage ou discussion approfondie». Pourquoi le fermer alors?

— utilisateur

6

pas constructif? Alors les super mods frappent à nouveau.

— Amit Tripathi

4

À ce jour, près de 24 000 personnes ont trouvé cette question constructive. Moi y compris.

— Frozenjim le

3

En 2017, cette question est toujours constructive

— Leonardo Pessoa

140

Selon le livre de Django , Django suit le modèle MVC assez étroitement pour être appelé un framework MVC.

Django a été qualifié de framework MTV car le contrôleur est géré par le framework lui-même et la plupart de l'excitation se produit 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 êtes familier avec d'autres frameworks de développement Web MVC, tels que Ruby on Rails, vous pouvez considérer les vues Django comme les contrôleurs et les modèles Django comme les vues .

C'est une confusion malheureuse provoquée par des interprétations divergentes de MVC.

Dans l'interprétation de Django de MVC, la vue décrit les données qui sont présentées à l'utilisateur; il ne s'agit pas nécessairement uniquement de l'apparence des données, mais des données présentées.

En revanche, Ruby on Rails et des cadres similaires suggèrent que le travail du contrôleur consiste à décider quelles données sont présentées à l'utilisateur, alors que la vue est strictement à quoi les données ressemblent, pas quelles données sont présentées.

— Paolo Moretti
source

6

Merci pour la bonne réponse. Venant de Rails à Django, cela répond à l'une des choses que j'ai trouvées les plus frustrantes: pourquoi django met-il le code du contrôleur dans un fichier appelé views.py !?

— dgmdan

@dgmdan C'est juste une convention par défaut, vous pouvez choisir le nom que vous aimez. Mais je suis d'accord, ça semble bizarre :)

— Paolo Moretti

1

Je préférerais laisser views.py comme couche de vue et créer un ensemble de classes de contrôleurs dans un package de contrôleurs pour éviter la confusion de Django.

— stanleyxu2005

5

@dgmda: Parce que le concept de «contrôleur» est un abus de langage dans les applications Web. MVC est un framework piloté par les événements qui ne s'adapte pas uniquement au modèle REQUEST / RESPONSE sans état de HTTP. Il ne devrait pas s'appeler MVC en premier lieu. Presque toutes les applications Web ne sont pas MVC, mais utilisent un modèle et une fonction ou une classe généralement appelée vue. La vue peut à son tour déléguer le rendu HTML à un modèle, mais ce n'est pas nécessaire. Il n'y a donc pas de contrôleur, en fait.

— Lennart Regebro

2

Je soutiens le concept de Lennart Regebro selon lequel un modèle sans état comme HTTP ne devrait pas avoir de contrôleur et un modèle MVC pour les applications Web apporte juste une confusion majeure

— Hussam

23

La FAQ Django elle-même est un bon point de départ:

https://docs.djangoproject.com/en/dev/faq/general/#django-appears-to-be-a-mvc-framework-but-you-call-the-controller-the-view-and-the -voir-le-modèle-comment-venir-ne-pas-utiliser-les-noms-standards

Dans notre interprétation de MVC, la «vue» décrit les données qui sont présentées à l'utilisateur. Ce n'est pas nécessairement à quoi ressemblent les données, mais quelles données sont présentées. La vue décrit les données que vous voyez, pas comment vous les voyez. C'est une distinction subtile.

...

De plus, 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 quelles données sont présentées, mais une vue délègue normalement à un modèle, qui décrit la façon dont les données sont présentées.

Où se situe alors le «contrôleur»? Dans le cas de Django, c'est probablement le framework lui-même: la machine qui envoie une requête à la vue appropriée, selon la configuration de l'URL de Django.

Si vous avez soif d'acronymes, vous pourriez dire que Django est un framework «MTV», c'est-à-dire «modèle», «modèle» et «vue». Cette ventilation a beaucoup plus de sens.

Gardez à l'esprit que «Model View Controller» n'est qu'un modèle, c'est-à-dire une tentative de décrire une architecture commune. Une meilleure question pourrait donc être: «Dans quelle mesure Django s’adapte-t-il au modèle Model View Controller?»

— Paul D. Waite
source

3

C'est peut-être la réponse la plus directe.

— utilisateur

11

Lorsque vous codez, sans penser aux noms des pièces du cadre, il n'y a pas de différences douteuses entre, par exemple RoR. Mais cela dépend de l'utilisation que vous en faites models, car sur Django, ils contiennent facilement une logique qui, sur d'autres frameworks, resterait au niveau du contrôleur.

Le viewsur Django a tendance à être un ensemble de requêtes pour récupérer des données et les transmettre au modèle.

— inigomedina
source

10

Un viewsdans Django est quelque chose comme un controllerdans MVC et un templatedans Django est plus probableviews

— Roel

7

Dans mvt, une requête adressée à 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 et émis en tant que réponse. idéalement dans les frameworks Web, le contrôleur est caché de la vue.

C'est là que réside la différence avec MVC: dans mvc, l'utilisateur interagit avec l'interface graphique, le contrôleur gère la demande et notifie le modèle et la vue interroge le modèle pour afficher le résultat à l'utilisateur.

— Samuele Mattiuzzo
source