Discussion :

[olibara]

Bonjour

Avant de réinventer la roue je me permet un questionnement sur les usages ou classe existantes facilitant la gestion d'erreur a l'encodage d'une form

J'ai une Form FrmMachin qui permet l'encodage des elements d'une classe Machin

Bien entendu lors de la validation je compte faire un certain nombre de test de validité de format (int, float, etc) et d'intégrité logique

La classe Machin pouvant etre manipulée par une Page Web ou par une WinForm ou... il me semble judicieux d'intégrer la validation au sein de la classe Machin

Et donc organiser d'une part le transfert des valeurs des controles de la form dans la classe machin

D'autre part renvoyer a la Form une eventuelle Liste d'erreur d'encodage qu'elle pourra traiter

Ma question porte dons sur la maniere de rendre cela le plus propre et reusable !

Existe-t-il une maniere "Classique" ou bien c'est chacun sa cuisine ?

[Guulh]

Hello,

ce que t'appelles encodage, c'est juste la liaison (binding en bon angliche ) entre tes contrôles graphiques et tes objets métier ? Alors oui, il existe des façons standardisées de le faire, avec les Bindings et les validators. Ils s'occupent de traduire la saisie user en données métier applicables et récupérables sur les objet de la couche métier.

Après, si tu as une logique métier indépendante de l'UI (par exemple, telle propriété est la somme de telles autres), tu peux les implémenter directement dans l'objet lui-même. Mais formater et parser des chaînes, c'est pas du métier, c'est de l'UI, et ça n'a pas sa place dans ton objet.

[olibara]

Salut Guuhl

Après, si tu as une logique métier indépendante de l'UI (par exemple, telle propriété est la somme de telles autres), tu peux les implémenter directement dans l'objet lui-même. Mais formater et parser des chaînes, c'est pas du métier, c'est de l'UI, et ça n'a pas sa place dans ton objet.

100 % d'accord

Par contre les binding je n'ai utilisé qu'une fois que pour voir
et les validator je ne connais pas du tout
Donc je me demande si ca simplifie vraiment la vie ou si ca n'oblige pas parfois certaines acrobaties ?

[Guulh]

Bah c'est loin d'être parfait, les bindings (pour winforms en tout cas,parait que c'est mieux gaulé en WPF). Mais au moins dans les cas simple (genre une string <=> une textbox, un bool <=> une checkbox), il est dommage de s'en priver.

Le mieux, c'est de tester Fais-toi un petit objet avec des propriétés bool, string, int, bindes-les à des contrôles, et tu verras ca marche tout seul
Par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
// product est une instance de la classe Product
// qui a une propriété DateDeVente de type DateTime
monDateTimePicker.DataBindings.Add("Value", product, "DateDeVente", false, DataSourceUpdateMode.OnPropertyChanged, null);

Et pour aller plus loin, fais implémenter INotifyPropertyChanged à ton objet métier ; sans ça, l'UI n'a pas moyen de savoir que l'objet métier a changé, et ne peut se mettre à jour automatiquement.

[olibara]

Merci Guuhl

Je viens de trouver ta réponse par hazard (il arrive souvent que je ne recoive pas de notification ??)

En définitive j'ai eliminé tous les binding que j'avais mis en place pour les remplacer par des methodes plus dures GetValues et SetValues

Les raisons :

1- Je suis pas fan de la syntaxe du binding
2- Je n'ai pas trouvé beaucoup de partisans du binding
3- J'ai constaté que si le save de la form se faisait via un toolstrip on prenait le focus sur le toolstrip sans que la form fasse le le commit le binding du dernier control touché. Donc si il faut en plus penser a faire des commit sur les binding. Je trouve qu'en définitive l'usage de methodes explicite est plus transparent !

(Je dis commit mais j'ai meme pas trouvé une methode du genre )

Mais je me trompe peut etre par manque d'experience dans ce domaine ?

[Guulh]

Tu peux specifier que le binding ne se fait pas a la validation mais des le changement du controle. Ca devrait resoudre ton souci.

Et se passer completement de binding, ca veut dire que tu dois t'abonner aux event de tes controles, pour copier sa nouvelle valeur vers l'objet metier. Donc des tripotees de methode textbox_TextChanged, checkBox_CheckChanged, ... contenant une seule ligne de code du style objet.Propriete = int.Parse(((TextBox)sender).Text).

Un poil repetitif Donc meme si je suis pas un fana du binding, je pense que dans les cas simples, ou le parsing et le formatage sont triviaux, c'est dommage de s'en passer.

[olibara]

Salut

Et se passer completement de binding, ca veut dire que tu dois t'abonner aux event de tes controles, pour copier sa nouvelle valeur vers l'objet metier. Donc des tripotees de methode textbox_TextChanged, checkBox_CheckChanged, ... contenant une seule ligne de code du style objet.Propriete = int.Parse(((TextBox)sender).Text).

Je suis peut etre tout a fait hors norme mais moi je ne me préoccupe pas du tout des event Changed des controle !
Soit je fais du binding et en définitive je trouve ca finalement un peu lourd

Soit j'attends betement le bouton Save pour appeller un methode SetValues de ma form qui fera tous les parsing nécessaire pour passer les valeurs des controles a ma classe metier !

J'ai donc un premier niveau de controle dans la form (valeurs numeriques etc)
Ensuite ma classe metier fais tous les test d'intégrité et renvoie l'erreur a la form si nécessaire

Ca marche tres bien je trouve que la structure est propre et claire mais quand tuu me parle de gestion des event changed je fremis a l'idée de ce que ca peut donner dans le code et de ce que j'ai peut etre raté dans le concept de UI

[Kaidan]

Je fais souvent pareil.

Le binding c'est sympa ... de temps en temps ... et une épine dans le pieds le reste du temps.

[Guulh]

Ca marche tres bien je trouve que la structure est propre et claire mais quand tuu me parle de gestion des event changed je fremis a l'idée de ce que ca peut donner dans le code et de ce que j'ai peut etre raté dans le concept de UI

Bah ça dépend du dynamisme de ton UI Dans les cas simples, on peut se contenter de copier les valeurs métiers dans l'UI a l'ouverture de la fenêtre, vérifier que tout est bon au click sur le bouton "Save", et recopier les valeurs de l'UI vers le métier.

Apres, suppose que t'aies un objet comme ca :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
class ObjetMetier
{
   ...
   public int Machin { get { return _machin; } set { _machin = Math.Max(value, 100); } }
}

dont le code métier assure que Machin sera toujours <= 100.
Avec du binding, si tu tapes "105" dans une textbox liée a la propriété Machin, la chaine "105" sera parsée et transformée en l'int 105, qui sera affecté à la propriété Machin, qui va donner la valeur 100 a _machin ; le contrôle va ensuite relire la valeur métier correcte, c'est a dire 100.
Et imagine maintenant que cette limitation a 100 ne soit faite que si une autre propriete boolenne est true, tu comprendras pourquoi je parlais tout a l'heure de checkbox1_CheckChanged

Ca permet donc de ne pas attendre la validation de ta form pour déclencher le code métier. De faire qu'un contrôle donne ne soit qu'une vue d'une propriété, maintenue a jour en permanence.
Et y'a des scénarios ou ca se justifie

Mais comme je le disais plus haut, ça marche nickel pour les cas simples, mais dès qu'on touche aux combos ou aux grilles, ça devient plus touchy.

Autre exemple d'utilisation : si t'as une fenêtre qui te sert a visualiser un objet en temps réel, susceptible de changer par ailleurs. L'objet implémente INotifypropertyChanged, et balance des events quand une de ses propriétés change de valeur. Si tu fais ça sans binding, tu dois t'abonner a l'event, et MAJ chaque contrôle en fonction de la propriété modifiée. Avec du binding, bah ca se fait tout seul.

[olibara]

Tout a fait d'accord avec toi Guuhl !
Il y a evidement des cas ou c'est bien pratique !

Et finalement il est toujours preferable d'adopter la meilleure strategie selon le context plutot que de vouloir systematiser des principes !

Merci de vos réponses