Lorsque vous utilisez actuellement le framework de développement MVC, lorsque vous vérifiez la légalité du texte saisi par l'utilisateur sur le front-end de l'utilisateur, lorsque l'utilisateur le soumet, cela doit-il être géré par la couche C ou la couche M ?
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Je dois être d'accord avec la déclaration de Yi Wei. Permettez-moi d'ajouter ma compréhension. V est vérifié pour garantir l'expérience utilisateur, afin que les utilisateurs ne trouvent pas d'erreurs après la soumission et reviennent pour les corriger pour garantir la légalité de. les données elles-mêmes. Vérification (si les données appartiennent à l'utilisateur et si le changement de statut des données répond aux exigences logiques), M effectue une transaction pour garantir l'existence des données, si les données n'existent pas, il n'est pas nécessaire d'aller en dessous. , ça doit être anormal.
Cette question doit être analysée en combinaison avec des applications spécifiques, des langages spécifiques et des frameworks spécifiques, et est même liée au style et à la composition des membres de l'équipe.
Personnellement, je préfère que M fasse la logique de vérification, lève des exceptions, puis C pour la capturer et la convertir au format requis par le front-end pour la sortie. Ce code initial peut être un peu verbeux, mais il est plus bénéfique pour l'intégrité logique et l'expansion ultérieure.
Une autre approche consiste à établir ce que l'on appelle une couche logique entre M et C pour gérer la logique de vérification et une partie de la logique métier
Généralement, dans le framework MVC, une couche de service sera ajoutée en fonction du traitement métier. Le modèle sera mappé ORM ou supprimé directement et écrira un DAO. D'accord, parlons maintenant de la couche dans laquelle la vérification est effectuée. La plus correcte. La méthode est le contrôleur. La couche C et la couche de service S doivent être effectuées, car à mesure que le site Web se développe, il est absolument nécessaire de séparer le service en tant que composant de service public pour les appels à distance, donc si vous n'effectuez pas de vérification au niveau du contrôleur. , il y aura Pour les demandes de données, vous les envoyez directement aux services publics, puis renvoyez une erreur, cela gaspillera évidemment une IO réseau. Donc, si vous avez effectué une vérification des données au niveau du contrôleur. , lorsque les données sont incorrectes, lancez directement une exception, pas besoin de passer un appel à distance via RPC
Cela dépend certainement de la situation :
Gros modèle, contrôleur maigre.
Echang coding a un principe : les interfaces ne se font pas confiance.
Si vous l'écrivez vous-même sans aucun cadre, il doit appartenir à la couche c. Mais davantage de frameworks ont tendance à être placés dans la couche m.
De plus, n'effectuez pas uniquement la vérification des entrées sur la couche v. Les éléments frontaux peuvent facilement être contournés, ce qui peut entraîner des risques de sécurité.
Chaque couche doit être réalisée avec un accent différent.
Nous ajoutons généralement une couche de service entre C-M de MVC (mais elle peut également être comprise comme faisant partie de C ou M. Cette couche est conçue pour être découplée de View et Controller, et peut être supprimée indépendamment vers l'extérieur (). API).
Alors,
Dans la Vue, effectuez un contrôle de légalité relativement faible d'une seule valeur,
Dans le contrôleur, vérifiez la légalité des paquets de requêtes externes et vérifiez certaines autorisations de l'interface utilisateur ; Effectuer une vérification stricte de la légalité des données, une vérification des contraintes de la logique métier et une vérification des autorisations des données utilisateur dans le service ; Effectuer une vérification de la légalité physique des données dans le modèle.
Si le sujet a utilisé des frameworks tels que Django ou Flask de Python, vous constaterez qu'il existe également une classe Form. De manière générale, la logique de vérification du contenu utilisateur sera placée dans la classe Form. Car parfois, nous pouvons avoir besoin d'établir des règles de validation différentes pour le même modèle de données en fonction de différentes situations. Bien entendu, Django prend également en charge la vérification de la couche modèle. Relativement parlant. La couche Form fait cela avec un degré de couplage inférieur.
Simple MVC effectue généralement la vérification FORM sur la couche modèle, tandis que les solutions plus matures séparent généralement FORM. Prenez Joomla comme exemple, elle a une couche FORM et est structurellement intégrée à la couche modèle. l'implémentation de la fonction semble n'avoir rien à voir avec la couche modèle.
En fait, le contrôle de légalité est également divisé en côté local et côté serveur.
Par exemple, si l'entrée est vide, elle est vérifiée sur la couche V ; si le format d'entrée est incorrect, elle est vérifiée sur la couche M.
Si vous souhaitez vérifier davantage s'il est qualifié, vous pouvez le placer sur la couche M et le vérifier en accédant au serveur.