Discussion :

[Invité]

Bonjour,

Juste une petite question. J'ai un bean tout simple nommé Person celui-ci possède un nom, un prénom et un email. Si je ne me trompe pas c'est un DataBean...

Je m'étais dis que je pourrais modifier un peu setMail(String mail) pour tester l'adresse et propager une InvalidParameterException si l'adresse est incorrecte. Mais si je fais cela, mon Bean n'est plus vraiment un DataBean puisqu'il contient de la logique ...

Ma question : puis-je placer la validation du mail dans mon bean Person sans 'violer' les règles ou est-il préférable d'accepter n'importe quoi et utiliser des méthodes de validations ailleurs ?

Merci

[Pollux]

On peut pas vraiment parler de logique si c'est simplement pour vérifier la validité de tes paramètres. Donc oui c'est très valable

[Invité]

Merci.

Par contre si ce bean possède une collection de listeners et autres fireXXXX(YYYEvent) ce n'est plus très correct ?

Pour avoir des événements sur ces bean, je dois passer par un Manager ?

[CyberChouan]

Puis-je placer la validation du mail dans mon bean Person sans 'violer' les règles ou est-il préférable d'accepter n'importe quoi et utiliser des méthodes de validations ailleurs ?

Tout dépend du type d'application: client riche en Swing, application web (J2EE, etc.)

Dans le premier cas, pourquoi pas, quitte à remonter une exception qui se propage jusqu'à l'IHM pour alerter l'utilisateur de son erreur.

Dans le deuxième cas, ça me paraît tardif. Faire la vérification au niveau du Bean signifie que tu as déjà fait un appel au serveur. Afin de décharger celui-ci, je ferais ce genre de vérification directement côté client en javascript/ajax. Ainsi tu ne solicites le serveur que si les paramètres sont déjà vérifiés comme corrects.

[adiGuba]

Salut,

Afin de décharger celui-ci, je ferais ce genre de vérification directement côté client en javascript/ajax. Ainsi tu ne solicites le serveur que si les paramètres sont déjà vérifiés comme corrects.

Attention à cela : il faut toujours avoir en tête que le coté client n'est pas sécurisé !

Même s'il y a une vérification coté client, le serveur DOIT obligatoirement vérifié toutes les données, sous peine de s'exposer à de potentiel faille...

a++

[CyberChouan]

Même s'il y a une vérification coté client, le serveur DOIT obligatoirement vérifié toutes les données, sous peine de s'exposer à de potentiel faille...

Certes! La vérification côté serveur n'est pas facultative. Ce que je dis, c'est qu'une vérification côté serveur seule, bien que suffisante pour la sécurité, n'est pas optimale du point de vue optimisation des ressources. Nous sommes donc d'accord

[adiGuba]

Nous sommes donc d'accord

Oui

a++

[Invité]

Merci pour ce petit débat très instructif mais j'avais déjà ces notions.

Par contre je ne sais toujours pas ce qu'il convient le mieux de faire pour :

Avoir un bean Person . Pouvoir l'utiliser aussi bien en Swing qu'en Web.
Etre sur que son adresse e-mail soit valide. Et effectuer des actions ( Recharge, mettre à jour le modèle, ..) lorsque mon bean est modifié.

Ou placer la validation du mail ?
Ou placer mes firePersonUpdated(Event e) et autres ..


Merci

[Pollux]

Moi je ferais comme ca:

Le bean contiendrait la vérification de l'email. A mon avis c'est son rôle de contenir les données mais aussi d'appliquer les règles de validités à ces données.

En ce qui concerne les firexxx tu ne les mets pas dans ton bean. Tu peux créer un wrapper qui lui contiendrait les firexxxx et redirigerait les appels sur les autres méthodes de ton bean. En swing tu utiliserais ce wrapper et non le bean directement.