Meilleur endroit pour la validation dans le modèle/vue/modèle de contrôleur?
Je travaille sur un projet PHP qui utilise beaucoup le modèle de conception MVC. Je cherche à ajouter une validation à un formulaire et je suis curieux de savoir quel est le bon endroit pour la validation.
En raison de la manière dont les formulaires sont générés, la validation des données de publication est beaucoup plus simple et moins répétitive dans les composants de vue. Est-il acceptable que la vue valide les données de réponse, ou est-ce que cela devrait être implémenté dans le contrôleur, voire dans le modèle?
Quels sont les bénéfices?
Si vous validez les données côté client (c'est-à-dire la validation Javascript) qui ne sont absolument ni suffisantes ni sécurisées, vous devez les implémenter dans View.
Si vous validez des données côté serveur et que votre validation ne nécessite pas de logique métier d'application (c'est-à-dire que vous ne vérifiez pas si l'utilisateur dispose de suffisamment de crédit sur son compte), vous devez valider dans le contrôleur.
Si la validation nécessite une logique métier, implémentez-la dans le modèle et appelez-la via le contrôleur.
La validation de la publication n'est pas bonne car elle met beaucoup de pression et de retard, et le seul avantage est pour le programmeur (à ne pas comptabiliser).
Vous pouvez utiliser regex pour la plupart des validations, qui ont la même syntaxe (presque) sur PHP et JS.
Le bon endroit pour la validation est le Model .
Cela a plus de sens car vous effectuez une validation sur les données, ce que représente le modèle. En ce qui concerne les mises à jour CRUD, le modèle doit toujours être utilisé d’une manière ou d’une autre.
Si vous modifiez des données à partir de la vue , Vous devez faire vérifier les validations
Si vous avez des contrôleurs en train de changer des données, vous devriez avoir les validations .__ en cours de vérification.
Et enfin, si vous avez le modèle Qui modifie lui-même les données, vous devriez toujours avoir des validations.
La seule façon d'atteindre cet état consiste à faire en sorte que la validation soit intégrée au modèle.
En raison des performances et d'une réponse plus rapide, après avoir implémenté les validations dans le modèle, vous devez essayer d'ajouter une sorte de côté client (JS) pour informer immédiatement l'utilisateur final.
La validation concerne toujours les données. Pourquoi validez-vous les données? Ainsi, vous pouvez conserver l’intégrité des informations que vous stockez. Avoir les validations au niveau du modèle permet aux données d'être théoriquement toujours correctes. C'est toujours une nécessité. À partir de là, vous pouvez ajouter des validations supplémentaires dans votre logique métier et votre côté client pour rendre votre application plus conviviale.
La validation dans le modèle semble être l'approche la plus commune (vous obtenez quelque chose comme $obj->isValid()) et cela convient dans de nombreuses situations.
Cependant, selon votre cas d'utilisation, il peut exister de bonnes raisons d'effectuer une validation en dehors du modèle, en utilisant un code de validation séparé ou dans le contrôleur, etc.:
- Si une grande partie du problème de validation global implique des informations inaccessibles au modèle (par exemple, si un utilisateur admin peut effectuer des transformations qu’un utilisateur normal ne peut pas modifier ou si certaines propriétés ne peuvent pas être modifiées après une certaine date), vous pouvez vérifier toutes les ces contraintes au même endroit.
- Il peut également être pratique ou nécessaire d’appliquer des règles de validation très laxistes lors de la construction d’objets pour les tests. (Un objet "panier" peut généralement nécessiter un utilisateur associé, qui à son tour requiert une adresse électronique valide, etc. Un objet panier à 100% valide peut ne pas être pratique à intégrer dans les tests unitaires du panier.)
- Pour des raisons historiques, les règles de validation peuvent changer (par exemple, imposer un "genre" alors qu'aucune ne l'était auparavant) et vous pouvez donc vous retrouver avec différentes versions de données qui doivent être traitées différemment. (Des règles de validation différentes peuvent également s'appliquer à l'importation de données en bloc.)
- Si la validation est très complexe, vous pouvez vouloir fournir différents messages d'erreur (ou aucun message du tout) en fonction de ce qui est le plus utile pour l'appelant. Dans d'autres situations,
trueoufalsepourrait suffire.
Il peut être possible de gérer ces différents cas d'utilisation via des arguments à la méthode isValid() du modèle, mais cela devient de plus en plus lourd à mesure que le nombre de styles de validation augmente. (Et je pense qu'il est presque garanti qu'une méthode unique "one size fits all" isValid() s'avérera finalement insuffisante pour la plupart des projets non triviaux.)
Ne confondez pas la désinfection ou le nettoyage de la valeur affichée avec validation. Vous devez récupérer les valeurs publiées et les éliminer en supprimant les éléments malveillants des valeurs du contrôleur. Envoyez ensuite les données au modèle à valider pour les valeurs ou le format attendus. En divisant ces actions en deux procédures, vous réduisez le risque de code malveillant à mettre en œuvre. Cette méthode fonctionne bien si vous utilisez la stratégie «Ne faites confiance à aucune entrée»; sachant que certains programmeurs peuvent devenir négligents ou paresseux. Un autre aspect positif consiste à éviter que votre modèle ne soit gonflé et trop travaillé. Si c'est le cas, utilisez un assistant modèle pour effectuer le travail sale. Cette approche aidera également à équilibrer la charge de votre application et à améliorer les performances.