Quelques petits rappels sur les contrôleurs en MVC
Le contrôleur : un chef d'orchestre, pas un musicien…
Les contrôleurs ont pour vocation de recevoir les requêtes des utilisateurs, et de mettre en branle la machinerie nécessaire pour produire les réponses adaptées. Ils jouent en ce sens le rôle de chef d'orchestre, invoquant les modèles pour récupérer et/ou mettre à jour les données métier, et déclenchant le rendu des vues (templates sous Django) sur la base des données récupérées.
Django aime les petits contrôleurs et les gros modèles !
L'une des « particularités » de Django est qu'il encourage les développeurs, au contraire d'autres framework (mais pas tous), à développer des contrôleurs (views) extrêmement simples, en déportant tout ou presque la logique métier dans les modèles.
En Django : les modèles comportent tout le code métier, toutes les classes applicatives et tout ce qu'il est possible de faire avec. Il ne reste plus grand chose pour les contrôleurs (views) : et c'est très bien comme ça !
Les contrôleurs : des classes ou des fonctions ?
Voilà une question très intéressante d'un point de vue philosophique, et qui a, à ce titre, fait couler beaucoup d'encre dans la communauté Django (et ailleurs !).
Les javaïstes convaincus ne se posent même pas de genre de question : réutilisabilité, spécialisation, les contrôleurs (views) doivent être des classes, c'est bien sûr ! Hum, oui, mais Django est un framework pour pythonistes : c'est là que les choses se compliquent (ou au contraire, deviennent plus simples…).
Revenons à notre définition : un contrôleur (views) est un simple chef d'orchestre, qui ne doit pas forcément savoir comment faire un bend avec une guitare ou un rim shot avec une batterie… Autrement dit, le contrôleur (views) embarque le moins possible de logique métier (celle-ci étant reportée au niveau des modèles). Il doit donc être réduit à une forme très simple.
Django a été pensé, à l'origine, pour permettre le développement de contrôleurs (views) qui sont de simples fonctions et pas des classes. Pourquoi ? Parce que c'est beaucoup plus simple ! Et les pythonistes aiment les choses simples. En Django, un contrôleur peut être défini en 2 lignes : une pour le nom de la fonction, une pour le traitement. Dans bon nombre de situations, cette façon de faire est très largement suffisante au point de vue des possibilités de traitement, et est beaucoup plus lisible et maintenable : pas de magie noire, pas de boilerplate code, que de la bonne camelote.
Depuis quelques années, sous la pression des adeptes des contrôleurs (views) sous forme de classes (!), l'équipe de développement de Django a cédé un peu de terrain et a introduit les class-based views, autrement dit les contrôleurs (views) sous forme de classes. Ceci a généré de gros débats au sein de la communauté, comme l'atteste ce billet de Luke Plant (core developer sur Django) devenu assez populaire chez les passionnés du framework : Django's class-based views were a mistake. Quoi qu'il en soit, les deux stratégies sont maintenues et c'est au développeur de choisir comment il veut programmer ses contrôleurs (views).
Vous vous ferez votre propre opinion. Pour ce cours, nous commencerons par implémenter les contrôleurs (views) sous forme de fonctions.
Testez vos connaissances…
- Cela permet de créer des applications plus rapides à l'exécution.
- Cela participe à une implémentation intelligente du patron MVC : toute la logique métier dans les modèles, uniquement de l'aiguillage et du contrôle dans les contrôleurs.
- Il n'y a aucun intérêt.
- Cela facilite la maintenance des applications, car le programmeur a une bonne idée, a priori, de où doivent se trouver les traitements métier et les actions de contrôle.
- Des assertions.
- De simples fonctions.
- Des classes.
- Des modèles.