[Frameworks] Un Controller ne doit pas avoir de logique métier!
Il existe de nombreuses pratiques pour développer du code propre, pérenne et accessible. Nommer la liste ici serait une perte de temps.
Parmi toutes ces lois, techniques et conseilles, la liste des 13 plus mauvaises pratiques appliquées à Rails soulève un point intéressant que l'on ne retrouve pas forcément dans les sites à base de Frameworks :
Chubby Controllers Must Die
There should be no business logic in a controller. Read that again. There should be no business logic in a controller. Controllers do two things: they take data from the params or session and send it to the model. The MODEL performs all the necessary logic. Then, the controller does the other thing that's completely necessary: it decides what should be shown to the user. That's it. The sum total of a controller action is two steps long.
If you are doing ANYTHING ELSE in your action, you are doing it in the wrong place. The end.
- Send information to the model.
- Decide what to display.
Le problème n'est pas forcément le développeur, qui ignore cette pratique, mais aussi les créateurs du framework, qui, par l'absence de composants adaptés, force le développeur à mettre du code métier dans ses controlleurs.
J'apprécie particulièrement cette remarque qui soulève un point fondamental sur l'usage des frameworks et prouve que leur utilisation n'est pas le stade ultime en matière de développement efficace.
Ce n'est pas parce que vous utilisez un framework que vous faites les choses bien !