J'apprends actuellement Ruby on Rails, et je me pose la question de la "bonne" architecture à suivre. Je m'explique avec un exemple simpliste :
Admettons que j'aie un modèle quelconque, par exemple User, pour représenter un utilisateur. Pour effectuer les différentes actions relatives à la lecture / l'écriture de mes utilisateurs en base, j'ai un contrôleur, ici UsersController.
Ma question est la suivante : mon contrôleur doit-il effectuer ces actions lui-même, ou doit-il les déléguer au Helper associé ? (Je penche pour cette seconde solution)
Par ailleurs, n'hésitez pas à me faire part de bonnes pratiques au sujet de RoR, je suis tout ouïe
Ruby on Rails n'est qu'un framework MVC, il vas donc faire des traitements et actions "web" sur tes ressources.
Une bonne pratique reste de développer ton application hors du contexte Rails, en pur Ruby, et que ton controlleur fasse appel au model concerné et le donne à l'application.
Comme toute app, c'est une meilleur approche que de coupler ton code avec le framework, comme ça lors d'un changement coté framework (mise a jours, passage à Hanami) tu as beaucoup moins d'obstacle.
Souvent ce que l'on garde coté Rails, c'est la validation des données, l'affichage des données, ainsi que la gestion des bases de données.
Tu peux regarder un peu le DDD et les DTO pour faire la traduction entre ton domaine métier et ton domaine technique (Rails)
disclamer: Cette approche est assez récente dans le monde Ruby, tu trouveras beaucoup d'approches qui partent dans un couplage fort avec le framework, mais je pense que l'expérience RoR 3 ==> RoR 4 a réussi à changer les mentalités.
- Edité par necros211 15 septembre 2020 à 17:44:11
Architecte logiciel - Software craftsmanship convaincu.