Devrais-je faire confiance à la validation ASP.NET DataTypeCheck?

Question

J'utilise les contrôles ASP.NET CompareValidator pour effectuer des vérifications de type de données. Dois-je suffisamment confiance à ces contrôles pour analyser directement leurs valeurs ou devrais-je utiliser TryParse?

Exemple:

<asp:TextBox ID="uxVolume" runat="server" /> 
<asp:CompareValidator ID="uxVolumeDataTypeValidator" runat="server" 
    ControlToValidate="uxVolume" ErrorMessage="Volume must be a number." 
    Type="Double" Operator="DataTypeCheck" Text="*" Display="Dynamic" /> 

dans le code behind dois-je Parse:

var volume = double.Parse(uxVolume.Text); 
// do something 

ou TryParse:

double volume; 
if (double.TryParse(uxVolume.Text, out volume)) 
{ 
    // do something 
} 

Answer 1

Personnellement, je ne voudrais pas déranger. Si le validateur échoue, cela signifie que quelque chose de réel se passe, donc l'exception sur double.Parse() n'est probablement pas complètement mauvaise à ce moment-là. Je les ai utilisé quelques milliers de fois et je n'ai pas eu de problème. . .

Answer 2

Dans mon expérience faisant confiance au validateur est sûr. Cependant, vous ne pouvez pas vous tromper en faisant un TryParse dans votre codehind.

Answer 3

Dans ce cas, vous attendez que le validateur fonctionne correctement, donc je n'utiliserais pas le tryparse. De cette façon, si quelqu'un changeait votre validateur, une exception serait lancée, au lieu d'échouer silencieusement si vous aviez utilisé le tryparse.

Answer 4

J'utiliserais TryParse. Le validateur devrait fonctionner. Je n'ai pas vu et par exemple où ce n'est pas le cas. Cela dit, vous devriez toujours essayer de vous protéger des mauvaises valeurs. Le code peut maintenant avoir le validateur, mais il ne le sera peut-être pas dans le futur, donc vous ne pouvez pas compter sur lui, et juste parce que le validateur devrait fonctionner, ne veut pas dire qu'il le fera toujours (vous pourriez déplacer accidentellement le code analyser la variable avant que le validateur ne se déclenche du côté serveur). Aussi simple que cela puisse être pour remplacer Parse avec TryParse, il n'y a aucune raison de ne pas utiliser TryParse et de vous protéger d'un problème potentiel d'un élément d'entrée non validé.

En réponse à un commentaire de Jakes. Il écrit que vous saurez si la validation ne fonctionne pas en lançant une erreur, et dans ce cas, il devra être dans un bloc try catch. Donc, dans ce cas, vous faites vraiment la même chose que l'instruction TryParse, sauf que vous devez écrire du code supplémentaire pour gérer l'exception potentielle levée et que les exceptions de lancement sont plus lentes que la vérification d'un booléen pour le succès.

Answer 5

Oui, mais si quelqu'un change/supprime votre validateur, alors vous voulez vraiment que l'exception soit levée pour que vous sachiez qu'il y a un problème avec l'application. Échouer tôt échouer rapidement (ou quelque chose comme ça). De même, vous n'avez pas besoin d'ajouter un bloc try try supplémentaire car cela devrait être une exception et être intercepté par votre gestionnaire d'erreurs global. Dans web config customerErrors code = 500 ou quelque chose comme ça.