|
La validation des données au niveau de la couche de présentation |
|
|
|
Conception -
Anti-patterns
|
|
Ecrit par Kamal AOUDA
|
|
23-12-2005 |
|
La validation des données au niveau de la couche de présentation
Les développeurs doivent souvent
valider les données renseignées dans les formulaires électroniques aussi bien au
niveau du client qu’au niveau du serveur. Ces validations peuvent être
complémentaires ou redondantes dépendamment de la confidentialité de
l’algorithme de validation, des ressources nécessaires pour l’implémenter et de
la configuration du browser utilisé par le client.
Par exemple si l’objectif de l’algorithme de validation est de vérifier qu’un
numéro de carte de crédit respecte la structure Master Card ou VISA, il serait à
première vue aberrant de l’implémenter au niveau du serveur. Cet algorithme est
en effet public. De plus des appels fréquents à un serveur distant peuvent
l’épuiser inutilement et augmenter le temps de réponse perçu par le client. En
revanche si l’objectif de l’algorithme est de vérifier que le numéro de la carte
de crédit existe dans la base de données de la banque est qu’il n’a pas été
opposé par le détenteur de la carte, son implémentation au niveau du serveur
devient incontournable.
Un autre problème posé par le caractère fortement distribué du web est celui des
scripts clients sur lesquels le développeur n’a aucune forme de contrôle. Ainsi
si le client désactive l’interprétation du Javascript ou du Vbscript sur son
browser le développeur est obligé d’implémenter un deuxième mécanisme de
validation au niveau du serveur.
Pour éviter les va et vient inutiles entre le browser et l’application, le
développeur peut toujours insérer dans son code des instructions pour vérifier
si Javascript ou Vbscript sont activés sur le poste du client [168]. Dans
l’affirmative, une double validation au niveau du serveur ne ferait qu’accroître
le temps de réponse et la consommation des ressources.
Habituellement, les scripts et les messages de validation sont générés
dynamiquement à partir d’un fichier de ressources partagées comme celui utilisé
par Struts (Resource Bundle) ou codés en dur manuellement dans la vue. La
première approche facilite la maintenance du code mais elle a des retombées non
négligeables sur les performances parce qu’elle fait appel à des opérations
complexes comme :
• Le parsing des fichiers de ressources [169] pour charger les algorithmes et
les paramètres de validation dans des objets Java.
• L’interprétation des formules de l’Expression Language. Notons cependant que
ces formules peuvent parfois se révéler plus performantes que les algorithmes de
validation basés sur les boucles et les switchs (surtout lorsque les validations
déclenchent des itérations dans les éléments d’une chaîne de caractères).
Pour sa part, la deuxième approche consomme moins de ressources parce que le
serveur traite les scripts client inclus dans les JSP comme du code statique.
Contrairement à la première approche le script de validation n’est pas construit
de toutes pièces à partir du fichier des ressources. Il est renvoyé au browser
aussitôt qu’il est détecté par le serveur web.
NB : Il est important de noter que la mixture de plusieurs langages de scripts
dans une même page est une cause de ralentissement de l’interprétation au niveau
du browser.
On constate encore une fois que les besoins en performance et les besoins en
maintenance ne vont pas toujours de pair.
Face à ce dilemme il faut essayer de trouver une solution de compromis en
gardant à l’esprit que la performance n’est pas seulement une affaire de temps
de réponse mais aussi une affaire de coûts.
Notes de bas de page
[168] Cette information est incluse
par le browser dans l’entête du paquet http envoyé au serveur.
[169] Formatés souvent en XML
|
|
Dernière mise à jour : ( 20-02-2006 )
|
Accueil 
Conception 
