Discussion :

[Link3]

Bonjour à tous,

J'ai un problème qui est plus conceptuel qu'autre chose je pense. Je vous explique, j'ai un site en ASP .NET divisé en plusieurs couches, la vue est séparée de mon métier.

Dans mes vues j'ai de multiples champs qui doivent être contrôlés de type :
- Ma date doit être comprise entre telle et telle date
- Les champs ne doivent pas être vides
- Ce champ n'accepte que du texte (un autre que des chiffres)
etc ...

D'après vous, vaut il mieux faire ces tests dans les "Control Validator" des pages Web ou dans ma partie métier ?

Ma première impression était d'effectuer ces tests dans la partie métier, ainsi lorsqu'un jour on changera de vue on ne devra pas tout refaire et on sera certain que la couche métier jongle avec de bonnes données, mais certains de mes collaborateurs pense que ça va allourdir considérablement le travail du serveur et donc le chargement des pages.

De plus même s'il y a des erreurs on ne pourra pas réellement montrer quel champ est invalide (système des petites étoiles rouges à coté des champs lorsque ceux ci sont faux).

J'aimerai donc avoir votre avis, quelle solution selon vous serait la plus adaptée ?

[lutecefalco]

Faut faire les 2.
Côté client car ça évite de faire des post back pour rien
Et côté serveur car il faut toujours considérer que les données envoyées par le client ne sont pas "sûres"

[CUCARACHA]

Salut,

Je te conseille d'initialiser les caractéristiques de tes contrôles de validation côté serveur mais de leur laisser faire leur office côté client.

Personnellement, et en attendant d'utiliser les nouveautés de l'Entity Framework 4, j'ai créé une sorte de générateur de formulaires dynamique qui intègre directement les contrôles de validation.

Donc, oui à ton idée d'intégrer tes tests de validation à ta business layer mais ils doivent agir depuis le client. J'ajoute qu'il arrivera que tu sois obligé de faire des posts backs pour cérifier certains points qui ne peuvent l'être que côté serveur...

++

Laurent Jordi