Pourquoi les professionnels de Ruby on Rails n'utilisent-ils PAS Scaffolding ?

Question

Je lis parfois, de la part de personnes qui semblent travailler avec rails depuis plus longtemps, qu'une leçon importante qu'ils ont apprise est "N'utilisez pas d'échafaudage". J'ai également lu sur irc des conseils allant dans ce sens. Ma question est de savoir pourquoi, quel est le point négatif ? Et est-ce que nifty_scaffolding mauvais aussi ?

Je pense qu'il est mauvais parce qu'il génère par défaut une version xml de votre action de contrôleur, ce qui exposerait les noms des champs de notre application à n'importe qui et la rendrait plus vulnérable aux attaques, alors peut-être est-ce cela ?

Quelles sont vos raisons de ne pas faire d'échafaudage ?

Answer 1

J'ai de l'expérience avec les rails et j'utilise rarement le scaffolding simplement parce que mon objectif final est loin d'être de simples actions CRUD. Cependant, il n'y a pas de règle stricte pour ne pas utiliser de scaffolding. Certains codeurs le désapprouvent parce qu'il est en réalité échafaudage littéralement. Ce n'est pas un produit fini. L'échafaudage vous soutient pendant que vous construisez le produit réel. Cherchez "échafaudage" sur Google Images et vous devriez avoir une idée.

Gardez à l'esprit scaffold n'est qu'un des nombreux éléments intégrés Générateurs dans Rails . Un générateur Rails est simplement un script qui produit un code générique. Les générateurs sont très utiles pour gagner du temps, et vous vous retrouverez rapidement dans la situation suivante générateurs d'écriture pour vos propres besoins.

Answer 2

Je pense que la plupart des professionnels évitent les échafaudages parce qu'ils préfèrent une approche de développement piloté par les tests pour écrire le code de production. Cela signifie qu'ils veulent d'abord écrire un test qui échoue, puis écrire le code qui fait passer le test. C'est un excellent moyen de produire un code solide, mais il fonctionne mieux à un niveau très granulaire. L'échafaudage semble faire trop de choses à la fois et perturbe donc la boucle serrée qui consiste à écrire un test défaillant pour une fonctionnalité spécifique, puis à écrire le code qui fait passer cette fonctionnalité particulière. Il est peut-être plus important de prendre cette habitude que de profiter de la facilité d'utilisation de l'échafaudage.

Cela dit, l'échafaudage peut être assez puissant en soi.

Answer 3

Il est important de comprendre l'utilisation des rails générateurs d'échafaudages et d'être conscient de leurs limites. L'échafaudage vous aide à faire fonctionner quelque chose rapidement et à tester une hypothèse. Mais dans le monde réel, il ne vous mènera pas très loin. Disons que vous avez créé un modèle avec un échafaudage

rails generate scaffold Article title:string body:text

Super ! Vous avez maintenant un prototype prêt. Mais disons maintenant que vous devez ajouter un autre champ "auteur".

rails generate migration add_to_article_author author:string
rake db:migrate

Maintenant, la table articles a une nouvelle colonne mais les fichiers dans /app/views/articles sont dans le même état, c'est-à-dire que le formulaire n'aura pas de champ auteur, etc. Si vous exécutez à nouveau Scaffold

rails generate scaffold Article title:string author:string body:text --skip-migration

Cette fois, vous avez ajouté --skip-migrate parce que cela a déjà été fait auparavant et que Rails se plaindrait vraiment si vous deviez migrer à nouveau la même table. Maintenant, Scaffold va vous demander d'écraser le fichier qu'il a créé la première fois. L'écrasement détruira également toutes les modifications apportées à votre contrôleur /app/controllers/article_controller.rb ou aux fichiers de vues comme /app/views/article/show.html.erb ou index.html.erb.

Étant donné que toute application Rails digne de ce nom comporte du code personnalisé (et non du code passe-partout créé par Scaffold), un programmeur Rails ne devrait utiliser Scaffold que pour tester une idée. Utilisez Scaffold pour donner à votre client quelque chose avec lequel jouer. Mais dans le monde réel, le code standard de Scaffold n'est pas utilisé.

Answer 4

Les échafaudages ne sont pas vraiment destinés à être utilisés en production. Il sert à démarrer rapidement une application et peut ensuite être modifié ou supprimé.

L'échafaudage de Rails 3 est en fait assez décent, mais il lui manque encore certaines choses, comme un moyen de gérer les ressources imbriquées, et il n'utilise pas la fonction plus simple respond_with (sur respond_to qui encourage la verbosité là où elle n'est pas nécessaire ou bienvenue).

Il est peu probable que les formulaires d'échafaudage par défaut fonctionnent sans être modifiés. Vous avez probablement des relations entre vos modèles qui se traduisent par une colonne dans la base de données, par exemple user_id . Lors de la création d'un échafaudage d'un modèle avec une relation, cette colonne apparaît comme un champ de texte dans le formulaire alors qu'elle devrait être déduite de l'URL ou sélectionnée via une autre interface plus conviviale.

De nombreux petits détails comme celui-ci font de l'échafaudage un candidat vraiment improbable pour un code prêt à l'emploi. Vous pouvez certainement construire une application en générant l'échafaudage, puis en comblant les lacunes et en nettoyant les zones dont vous n'avez pas besoin, et je pense que la plupart des développeurs Rails le font dans une certaine mesure.

Answer 5

Je n'utilise pas d'échafaudage pour deux raisons :

• Le scaffolding de Rails met tout dans un tableau html - je n'aime pas ça.
• Je préfère utiliser rails_admin pour mes pages d'administration, de sorte qu'il n'est pas nécessaire d'utiliser 90 % du code de l'échafaudage.

Vos préoccupations en matière de xml ne sont pas la raison pour laquelle les gens déconseillent l'utilisation d'échafaudages. Je ne m'embête pas avec les versions XML de mes pages car cela double le nombre de routes que votre application doit générer, ce qui augmente un peu les frais généraux...