50 votes

Question MVC: Devrais-je mettre des règles de validation de formulaire dans le contrôleur ou le modèle?

D'une part, la validation du formulaire pourrait être considéré comme une partie de la logique de l'application et donc appartenant dans le modèle.

D'autre part, il traite directement avec l'entrée en provenance de vue et gère l'affichage des erreurs, etc. De ce point de vue, il est plus logique de le mettre dans les contrôleurs.

Laquelle est la bonne approche de la MVC point de vue?

P. S mon formulaire de validation consiste en réalité seulement de l'écriture d'une liste de champs, de leurs règles, et de les transmettre à une forme de validation de la bibliothèque, qui renvoie true/false si il est passé de la validation ou non.

Exemple:

$this->load->library('form_validation');
$this->form_validation->set_rules('name', 'Name', 'required');
$this->form_validation->set_rules('email', 'Email', 'required|valid_email');
//........
if ($this->form_validation->validate())
    // Process data
else
    $this->register_form(); //A controller action that will show a view with errors

Cela devrait-il être mis dans un contrôleur ou d'un modèle?

72voto

Wesley Murch Points 48959

Idéalement, vous voulez 3 couches de validation:

  1. Vue: côté Client (javascript, html5, validation, etc.). Cette captures d'évidentes erreurs et omissions des données avant de les hits du contrôleur, de gaspiller le temps de l'utilisateur et de l'invocation inutile de chargement de la page si il y a des erreurs.
  2. Contrôleur: C'est votre Formulaire de validation de la couche. Les contrôleurs sont généralement destinés à gérer les signaux d'entrée directement, et de l'envoyer sur le modèle. Il est très rare que chaque domaine dans votre formulaire directement liées colonne dans votre base de données, vous avez généralement besoin de modifier les données d'une certaine façon avant de le transmettre au modèle. Juste parce que vous avez un champ, vous devez valider appelé "confirmer l'e-mail", ne signifie pas que votre modèle aura affaire à un "confirmer l'e-mail" de la valeur. Parfois, ce sera la dernière étape de validation.
  3. Modèle: C'est votre dernière ligne de défense pour la validation, et éventuellement de votre seule la validation dans le cas de l'envoi des données au modèle sans venir directement à partir d'un formulaire post. Il y a beaucoup de moments où vous avez besoin d'envoyer des données à la base de données à partir d'un contrôleur d'appel, ou avec des données qui n'est pas saisie de l'utilisateur. Nous ne voulons pas voir DB erreurs, nous voulons voir les erreurs levées par l'application elle-même. Les modèles ne doivent généralement pas être aux prises avec des $_POST données ou de la saisie de l'utilisateur directement, ils devraient recevoir des données à partir du contrôleur. Vous ne voulez pas avoir affaire avec des données inutiles ici, comme l'e-mail de confirmation.

19voto

Nemoden Points 4520

La validation est un problème pour Model. Seul le modèle sait à quoi vos données devraient ressembler. Vous décrivez vos champs de données dans le modèle. Vous devez donc décrire les règles de validation de ces champs au même endroit.

Cela semble évident pour moi, mais j'écouterais volontiers les adversaires.

12voto

JohnWright Points 190

Je dirais que le code de validation du formulaire devrait être dans le contrôleur (pas le modèle) dans la plupart des cas.

Madmartigan a dit le mieux dans son commentaire ci-dessus "Validation du formulaire! == Validation des données. Tous les formulaires n'interagissent pas avec un modèle"

Les formulaires Web font logiquement partie de la partie Afficher / Contrôleur de MVC, car l'utilisateur interagit avec eux dans la vue.

5voto

Ryan Williams Points 167

Semble que tout le monde dit toujours le modèle de mains à cette question, ce qui a ses avantages (par rapport à l'autre), mais je pense que la réponse à la question est plus subtile. La Validation de la donnée elle-même doit être effectuée sur le modèle.

Mais il existe d'autres types de validation, comme si le formulaire a été soumis avec des domaines inattendus (pour des raisons de sécurité, bien évidemment) ou si un utilisateur est autorisé à effectuer l'opération demandée. En mettant ces types de validation du modèle, il ciments du modèle (une abstraction des données) à séparer complètement les choses, comme la façon dont le système de l'utilisateur ou comment fonctionne formulaire de soumissions sont évaluées à des fins de sécurité.

Vous pouvez imaginer le changement de l'un de ces classes ou des systèmes de classes, puis d'avoir un gâchis parce que vous avez à modifier l'ensemble de vos modèles, trop. Alors que les contrôleurs sont le médiateur entre le client d'entrée et les données: dans ce rôle, ils sont de la bonne validateurs des exemples ci-dessus, et probablement beaucoup d'autres.

2voto

Luís Points 31

C'est une intéressante discussion théorique, mais si nous nous concentrons sur le point que la question a été faite dans le contexte de Codeigniter(IC):

Dans CI, vous pouvez spécifier une règle de validation personnalisée comme ceci:

$this->form_validation->set_rules('email', 'Email', 'required|callback_my_validation');

Dans ce scénario, vous devez définir une fonction publique qui est appelé "my_validation" qui doit retourner true ou false et le cadre va ajouter de l'erreur (en cas de renvoi false) pour une pile d'erreurs.

Alors... si vous mettez ce code dans le contrôleur, vous êtes inadvertedly exposer une url publique, le sens qu'il serait possible d'appeler quelque chose comme "http://yoursite.com/my_validation" (je ne pense pas que vous avez l'intention que). La seule façon de protéger cette url, serait d'aller dans le "routes.php" fichier et prévenir il y a l'accès à cette url. Cela ne semble pas pratique et semble pointer dans la direction que CI les développeurs nous a destinés à gérer la validation du modèle.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X