Passer de CakePHP à Django - un fichier de vues monolithique?

Question

J'essaie de démarrer avec Django, et j'ai déjà travaillé avec CakePHP, et mon environnement MVC en découle. Je suis conscient de l'architecture MTV légèrement différente de Django, et je suis d'accord avec les fichiers modèles monolithiques - plusieurs classes dans un fichier que je peux gérer très bien.

Mais je suis confus sur la façon de faire les vues (qui sont à peu près analogues aux contrôleurs dans MVC, correct?). Les exemples que j'ai vus ont juste un views.py qui a des méthodes comme index(), view(), etc. Mais si j'ai un groupe d'utilisateurs qui créent et possèdent des widgets qu'ils peuvent partager, par exemple, je veux /users/view courir view() pour le modèle des utilisateurs et /widgets/view qui exécute view() pour le modèle de widgets.

Je ne vois aucun moyen de les séparer, et je ne sais pas quelle est la bonne façon de le faire. J'ai peut-être aussi du mal à comprendre comment Django fonctionne. Devrais-je avoir des méthodes au view.py qui sont user_view et widget_view? Cela semble très maladroit.

Ou devrais-je user_view.py ou même user/view.py qui contient index() et view()? Puis-je faire référence à ceux du routage d'URL? Comment ça se passe généralement avec Django et ce genre de choses?

Ceci peut finalement être lié à (ou même résolu par) this answer, mais je demande plus comme une question de quelle convention et la bonne façon de penser à de telles choses est.

De plus, les documents/exemples ne devraient-ils pas être plus clairs à ce sujet? J'ai été impressionné par les docs jusqu'à présent, mais je suis sûr que la plupart des applications web traiteront de plus d'un "objet", et il me semble que cela arriverait assez souvent.

Answer 1

Les fichiers d'affichage Python ne sont que des modules Python. Les vues elles-mêmes sont juste des fonctions qui peuvent vivre où vous voulez - le module n'a même pas besoin d'être appelé views.py. L'urlconf (dans urls.py) peut faire référence à des vues n'importe où. Une manière évidente de séparer les choses est dans des applications séparées, ce qui est bien couvert dans la documentation - vous pouvez également avoir des fichiers urls.py séparés pour chaque application et utiliser include dans le site principal urls.py pour inclure tous les sous-fichiers. Mais rien ne vous empêche de subdiviser les vues d'une seule application en plusieurs fichiers, par exemple en créant un module views contenant un __init__.py (vide) et autant de fichiers de vue que vous le souhaitez. Ou, si vous avez vraiment des vues associées uniquement à un modèle particulier - et vous seriez surpris de voir à quel point c'est rarement le cas - vous pourriez faire vos vues classmethods sur la classe modèle elle-même. Tout ce que la vue a à faire est d'accepter une requête, et tout autre paramètre, et retourner une réponse.