La vue ne doit-elle pas effectuer de validation?

Je lisais " Dans MVC, un modèle devrait-il gérer la validation? ", Car j'étais curieux de savoir où la logique de validation devrait aller dans un site Web MVC. Une ligne dans la réponse du haut se présente comme suit: "les contrôleurs doivent gérer la validation, les modèles doivent gérer la vérification".

J'ai aimé cela, mais cela m'a laissé me demander pourquoi nous ne ferions pas de validation des données dans la vue, pour plusieurs raisons:

1. Les vues ont généralement un support de validation robuste (bibliothèques JS, balises HTML5)
2. Les vues peuvent valider localement, réduisant les E / S réseau
3. L'interface utilisateur est déjà conçue avec le type de données à l'esprit (calendriers pour les dates, spinners pour les nombres), ce qui en fait un petit pas depuis la validation

La validation dans plus d'un endroit est contraire au concept de MVC d'isoler les responsabilités, donc «le faire dans les deux» semble inapproprié. La validation des données uniquement dans le contrôleur est-elle vraiment l'approche dominante?

Je ne pense pas qu'il y ait un seul endroit où vous pouvez dire que toute la validation devrait aller. C'est parce que nous avons quelques stratégies de programmation concurrentes différentes qui travaillent ensemble dans un site Web asp.net mvc standard.

Nous avons d'abord l'idée de séparer la logique du domaine en modèles, la logique «action» en contrôleurs et l'affichage en vue. Ceci est basé sur l'idée que toute la logique aura lieu sur le serveur avec le navigateur fournissant simplement un rendu de la vue.

Ensuite, nous étendons la vue en utilisant le javascript côté client. C'est tellement avancé de nos jours que l'idée d'un site Web d'une page avec Jquery / knockout / angular est une pratique courante.

Cette pratique peut être équivalente à l'écriture d'une application côté client entière qui implémente elle-même un modèle MVC ou MVVM. Nous dénigrons la vue en un objet de transfert de données et le contrôleur en un point de terminaison de service. Déplacement de toute la logique métier et d'interface utilisateur dans le client.

Cela peut donner une meilleure expérience utilisateur, mais vous devez faire confiance à un client essentiellement non fiable. Vous devez donc toujours effectuer une logique de validation sur le serveur, quelle que soit la qualité de la pré-validation de vos demandes par votre client.

De plus, nous avons souvent des exigences de validation qui ne peuvent pas être effectuées par le client. par exemple. 'mon nouvel identifiant est-il unique?'

Toute application que vous créez dans le but d'offrir la meilleure expérience / performance empruntera nécessairement pour plusieurs paradigmes de programmation et fera des compromis sur eux pour atteindre son objectif.

La validation dans plus d'un endroit est contraire au concept de MVC d'isoler les responsabilités, donc «le faire dans les deux» semble inapproprié.

Pourrait-il y avoir plusieurs responsabilités de validation à considérer ici? Comme vous l'avez dit dans votre # 3:

L'interface utilisateur est déjà conçue avec le type de données à l'esprit (calendriers pour les dates, spinners pour les nombres), ce qui en fait un petit pas depuis la validation

Alors peut-être que c'est:

Vue : Validez le type d'entrée, le format, l'exigence ... validation de base de l'entrée utilisateur qui n'a rien à voir avec la logique métier. Attrapez tous ces trucs moelleux avant de générer du trafic réseau en faisant une demande au serveur.

Modèle : valider les préoccupations commerciales des données. Est-ce une valeur légale selon les règles commerciales? Oui, c'est une valeur numérique (nous nous en sommes assurés dans la vue), mais est-ce logique?

Juste une pensée.

Je vais supposer que vous avez besoin d'une validation pour la persistance.

Non seulement View, mais Model ne doit pas non plus gérer la validation. Pendant mes jours dans l'informatique, j'ai réalisé que DDD est l'un des moyens de vous assurer que vous faites les choses correctement, c'est-à-dire. les classes sont en fait responsables de ce qu'elles devraient être.

Lorsque vous suivez une conception pilotée par domaine, vos modèles incluent votre logique métier, et c'est tout. Mais ils n'incluent pas la validation, pourquoi pas?

Supposons que vous êtes déjà aussi loin que vous utilisez Data Mapperau lieu de Active Recordconserver votre couche de domaine. Mais malgré tout, vous voulez que les modèles soient validés, vous ajoutez donc la validation à votre modèle.

interface Validation
{
    public function validate();
}

class ConcreteModel extends MyModel implements Validation
{
    public function validate() { // the validation logic goes here }
}

La logique de validation garantit que vous pouvez correctement insérer le modèle dans votre base de données MySQL ... Quelques mois passent et vous décidez, vous voulez également stocker vos modèles dans des bases de données noSQL, des bases de données, qui nécessitent des règles de validation différentes de MySQL.

Mais vous avez un problème, vous n'avez qu'une seule méthode de validation, mais vous devez en valider une Modelde 2 manières différentes.

Les modèles doivent faire ce qu'ils sont chargés de faire , ils doivent prendre soin de votre logique métier et bien le faire. La validation est liée à la persistance et non à la logique métier, la validation n'appartient donc pas à un modèle .

Vous devez Validatorplutôt créer des s, qui prendront un modèle à valider dans leur constructeur en tant que paramètre, implémenteront l' Validationinterface et les utiliseront Validatorpour valider vos objets.

interface Validation
{
    public function validate();
}

class MySQLConcreteModelValidator implements Validation
{
    public function __construct(ConcreteModel $model) { }

    public function validate()
    {
        // you validate your model here
    }
}

class RedisConcreteModelValidator implements Validation
{
    public function __construct(ConcreteModel $model) { }

    public function validate()
    {
        // you validate your model with different set of rules here
    }
}

Si à tout moment dans le futur vous décidez d'ajouter une autre méthode de validation pour une autre couche de persistance (parce que vous avez décidé que Redis et MySQL ne sont plus la voie à suivre), vous allez simplement en créer une autre Validatoret utiliser votre IoCconteneur pour obtenir la bonne instance en fonction sur votre config.

Pour de nombreux développeurs, les modèles Fat contre les contrôleurs laids stupides sont la méthode préférée.

Le concept de base dans le texte est

... N'oubliez donc pas que le modèle n'est pas seulement la base de données. Même les données que vous obtenez des services Web peuvent être exprimées comme un modèle! Oui, même Atom se nourrit! Les cadres qui font vibrer les introductions au modèle n'expliquent presque jamais cet aspect initial qui ne fait qu'exacerber les malentendus.

et

La vue ne doit se préoccuper que de générer et de présenter une interface utilisateur afin que les utilisateurs puissent communiquer leur intention au modèle . Les contrôleurs sont les orchestrateurs qui traduisent les entrées de l'interface utilisateur en actions sur le modèle et retransmettent la sortie de la vue qui a été informée du ou des modèles qu'il présente. Les contrôleurs doivent définir le comportement de l'application uniquement dans le sens où ils mappent les entrées utilisateur sur les appels dans les modèles, mais au-delà de ce rôle, il doit être clair que toute autre logique d'application est contenue dans le modèle. Les contrôleurs sont des créatures modestes avec un code minimal qui ouvrent la voie et laissent les choses fonctionner de manière organisée.

La vue ne devrait être concernée que par la génération et la présentation d'une interface utilisateur afin que les utilisateurs puissent communiquer leur intention au modèle est la partie importante. Un modèle doit définir les données stockées, il doit donc également être chargé de vérifier la validité des données.

Lors de l'enregistrement d'une personne, chaque personne doit avoir un numéro d'identification unique donné par le pays. Cette vérification (généralement) est effectuée par la UNIQUEvérification des clés par la base de données. Chaque numéro d'identification donné doit satisfaire à certaines étapes de contrôle (la somme des chiffres impairs doit être égale à la somme des chiffres pairs, etc.). Ce type de contrôles doit être effectué par leModel

Le contrôleur collecte des données Modelet les transmet View, ou inverse, collecte les données utilisateur Viewet les transmet Model. Toute restriction d'accès aux données et de validation ne doit pas être effectuée par le Controller. Ce sont les personnes Controllerqui collectent les données des cookies et ce sont elles Modelqui vérifient s'il s'agit d'une session valide ou si l'utilisateur a accès à cette partie de l'application.

Viewest l'interface utilisateur qui collecte les données de l'utilisateur ou présente les données à l'utilisateur. Des contrôles simples peuvent être effectués par le Viewmême que l' adresse e-mail entrée par l'utilisateur ou non (ainsi cela peut également être fait dans la vue) IMO.

La vue est du côté client, et vous ne devez pas pousser l'entrée utilisateur. Les javascripts peuvent ne pas s'exécuter côté client, un utilisateur peut utiliser des scripts manuscrits pour les modifier ou désactiver le script à l'aide du navigateur. Vous pouvez définir des scripts de validation côté client, mais vous ne devriez jamais les pousser et faire le vrai contrôle sur la Modelcouche.

Les vues doivent effectuer des validations à des fins ff:

1. ) Une validation frontale peut réduire le trafic de données sur votre serveur.
2. ), il gère les données non valides avant de pouvoir voyager sur votre serveur.
3. ) si vous voulez une sécurité plus élevée, une combinaison de validation frontale et arrière est meilleure.