Discussion :

[LecGaël]

Bonjour,

Je suis actuellement en train de développer une interface graphique pour interroger,modifier, etc (vous connaissez la musique) dans une base de données.
Actuellement mon programme winform est assez lourd, j'ai pas mal de gridview pour voir les différents éléments de la base etc, au niveau du code c'est lourd aussi car beaucoup d'élements graphiques impliquent beaucoup de méthodes dans le programme.
De plus lorsque on veut gérer les différents scénarios il faut être sur de ne pas oublier de rendre invisible certains panels etc....
Tout ça pour dire que ça peut vite devenir le foutoir.

Ma question c'est est ce qu'il existe des méthodes de travailles permettant de faire quelque chose de propre, surtout lorsque l'on doit ajouter de nouveaux éléments pour plus tard.
Voilà merci d'avance et bonne journée.

[Pol63]

faire des usercontrols peut être

[LecGaël]

Des users control me permettraient de mieux gérer les différentes parties à afficher ?
Car je n'ai pas besoin d'afficher plusieurs fois les mêmes controles je cherche juste une manière d'avoir un code clair et des méthodes pour gérer les différents éléments à afficher en fonctions des actions de l'utilisateur.

[Pol63]

Après tu décris pas trop ce que tu as non plus...
Et un usercontrol même s'il n'est utilisé qu'à un endroit permet de séparer du code et donc de faciliter la maintenance.

Si tu veux faire moins de code il faut factoriser, afficher une liste de client ou une liste de facture y a une requête de différence, et modifier un client ou une facture c'est modifier un ensemble de propriété qui ont une gestion différente en fonction du type de données.
Donc au lieu de coder 80 écrans on peut coder une quinzaine de types à gérer.
Potentiellement une fois qu'on a réfléchit et codé les bases on peut faire un écran d'affichage et la gestion des modifications en 20 lignes de code. Donc en faire 80 ça va vite.
(L'autre avantage c'est que ca repose tout sur le même code donc y a moins de bugs)

Automatiser est aussi une solution, quand on utilise des requetes, le datareader permet d'obtenir la liste des colonnes dans un select, leur type etc...
la reflection permet d'analyser une classe au runtime, et donc de trouver la liste des propriétés et leur type, on peut aussi faire des attributs pour définir des comportements, et une fois le moteur codé on a juste à mettre des attributes du type [obligatoire], [numeric(min = 0, max =30)] et le moteur analyse ca pour créer l'interface et gérer la validation

pour moi écrire à longueur de journée des if (txtnom.text = "") return false c'est pas vraiment ce qu'il y a de plus intéressant

et sinon y a wpf qui une fois qu'on l'a compris demande souvent moins de code par rapport à winform, après quand on est sur une grosse appli historique c'est pas évident de trouver une utilité économique à perdre du temps pour migrer

[LecGaël]

Après tu décris pas trop ce que tu as non plus...


pour moi écrire à longueur de journée des if (txtnom.text = "") return false c'est pas vraiment ce qu'il y a de plus intéressant

C'est justement là que je veux en venir, quand tu as plein d'événement de click bouton que dans chacun de ces événement il faut dire, faire disparaitre ça,ça,ça et ça.
C'est super lourd au niveau du code.

Pour ce qui est de WPF je n'ai pas bien saisie tout ce qui était MVVM il faudrait que je creuse plus de ce côté là, si j'ai bien compris la philosophie c'est que l'interface est à l'écoute des données (databinding) ?

[Pol63]

oui entre autre, ca permet de mieux différencier le code de l'interface du reste du code
l'interface ne se fait plus en posant des controles, mais en écrivant du XAML (syntaxe xml), et en théorie en c# on écrit plus telcontrol.tellepropriété = ca (enfin on essaye d'éviter)
pour la visibilité ca serait dire en XAML que la visibilité de tel control dépend de la valeur de telle(s) propriété(s) de tel(s) control(s), et les propriétés notifient de leur changement, donc c'est automatique (les listbox et autres sont aussi à l'écoute de changement de collection, donc plus besoin de faire listbox.items.add non plus par exemple)
mais il faut du temps pour appréhender le monstre et devenir plus productif qu'en winform

mais wpf n'est qu'un Framework graphique, j'ai vu des gens taper des millions de lignes de XAML et de c# qui se ressemblent comme ils l'auraient fait en winform
et les solutions techniques pour éviter tout ca en winform ne sont pas forcément les même en wpf, wpf est vraiment différent de winform

après je vois que t'es étudiant, maitriser tout ca prend du temps, et si on veut taper moins de code et du code plus intéressant il faut être assez pointu techniquement, donc là aussi faut un peu de temps pour progresser
(d'un autre côté en étant étudiant c'est bien le moment de potasser et t'as le temps ^^)