Dans un appli Rails, on fait beaucoup de CRUD : Create, Read, Update, Delete. Les Controllers exécutent des Actions et en conséquence font appel au Model correspondant qui gère l’accès à la base de données. Le Model est alors une interface entre le Controller et la base de données. Dans ce chemin à double sens, qui est très souvent emprunté, on peut établir des points de contrôle au niveau du Model pour s’assurer de la conformité des valeurs enregistrées dans la base de données. En Rails, ça correspond aux Validations. J’en avais utilisé pour ma mini appli “Discographie” : je vérifiais par exemple que l’année de l’album était bien entre 1950 et 2010, et que le titre était bien présent.

J’ai des problèmes de gem (parce que je suis sur mon netbook) et je n’ai pas le net. Je vais donc parler uniquement de ce que je lis et non de ce que je fais. C’est frustrant de ne pas pouvoir appliquer ce que je suis en train de lire, et c’est contre-productif. En mettant en pratique, je fais des erreurs et ça m’aide à les contourner par la suite. Je vais essayer de ne pas dire trop de bêtises dans les prochains paragraphes en reprenant ce que dit le site.

Plusieurs niveaux de validation

Si je prend le chemin que prend une action Rails, ça serait ça :
View <--> Controller <--> Model <--> Base de données
La validation des données peut se faire à l’un de ces 4 niveaux.

  • au niveau de la base de données : la validation se gère directement dans la base données. Elle est donc dépendante de cette dernière. Si on veut changer de type de bdd, il faut re-gérer la validation. C’est un peu relou comme processus. Le seul scénario où ça peut paraître utile est lorsque plusieurs applications ont accès à la même base de données. Dans ce cas, on n’a qu’à gérer la validation à un seul endroit.
  • au niveau du client : la validation se fait dans le navigateur, avec du JS. C’est très mauvais et très dangereux. Mauvais parce que le client (l’internaute) peut désactiver le JS et ne voir aucune validation. Dangereux parce que la sécurité se fait au niveau du client. J’ai vu récemment un formulaire avec uniquement de la validation en JS, et il a suffi d’un peu de Firebug pour modifier les valeurs que l’on voulait. Les dév avaient pas mis de validation côté serveur. Bref, la validation JS, ça peut aider à remplir un formulaire, mais ça ne doit pas être la contrainte unique.
  • au niveau du Controller : on peut mettre des contraintes dans le Controller directement. Par exemple, je peux mettre un if machin, then save. Mais apparemment c’est difficile à maintenir, et sans doute compliqué d’éviter les oublis. J’imagine mettre une validation sur ma méthode create mais pas sur ma méthode update.
  • au niveau du Model : c’est LA meilleure solution et celle que naturellement préconise Rails. Cette validation ne dépend pas du type de la bdd, ne peut pas être forcé par l’internaute, et c’est facile à tester et maintenir. La validation se fait à un seul endroit et il y a pleins de méthodes que Rails fournit pour faciliter ça.