Bonne manière de developper des interfaces graphiques.

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. :D

faire des usercontrols peut être

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.

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

Citation:

---

Envoyé par Pol63

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) ?

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 ^^)

Oui je vois bien la chose, j'avais essayé de m'attaquer à tout ce qui était MVVM qui semble être les nouvelles normes de développement en entreprises, mais comme vous dîtes c'est un gros morceau...
Pour l'instant je finis mon projet et je verrais par la suite à m'initier au WPF, databinding, MVVM etc...

Citation:

---

au niveau du code c'est lourd aussi car beaucoup d'élements graphiques impliquent beaucoup de méthodes dans le programme

---

Pol63 : Si tu veux faire moins de code il faut factoriser
Je suis d'accord.

Citation:

---

mon programme winform est assez lourd, j'ai pas mal de gridview

---

Les DataGridView s’optimise, si tu va assez loin il faut te pencher sur l’événement CellValueNeeded

Citation:

---

j'ai pas mal de gridview pour voir les différents éléments de la base

---

Est t'on obliger de voir toute la base en une seule fois ?
Peut être se contenter d'un seul DataGridView, et un choix de vue

Citation:

---

beaucoup d'élements graphiques impliquent beaucoup de méthodes

---

C'est à dire ?

Bonjour,

Je ne comprends pas ce que vous entendez par "factoriser", auriez vous une source ?

Pour ce qui est des éléments graphiques, je voulais dire que si j'ai 10 boutons sur ma form j'aurais 10 méthodes bouton[i]_click(...), et ça pour chaque éléments.
Si on a des tabcontrol avec différents contrôles qui apparaissent,, on se retrouve vite avec beaucoup de méthode click,indexchanged etc.

En ce moment je fait une interface graphique pour modifier des éléments dans ma base, donc j'ai fais un tabcontrol avec différents onglets, mais ensuite il y a différents panels pour les ajouts suppression etc.

le tabcontrol c'est le truc qui nécessite des usercontrols
pour chaque tabpage tu fais un UC et tu le poses dans le tabpage
sinon tu te retrouves avec une fenetre qui gère plein de choses, et ca c'est le truc à éviter, une classe (car une form est avant tout une classe) ne doit faire qu'une chose
tout mélanger n'aide pas à s'y retrouver


concernant la factorisation c'est le même principe qu'en maths ou (5x3) + (5x8) peut se factoriser en 5 x (3+8)
5 n'apparait plus qu'une fois
dans le code ca peut s'appliquer partout, perso dès que je vois 2 lignes/bouts de code qui se ressemblent je regarde s'il y un paramètre qui permettrait de ne l'écrire qu'une fois en fournissant ce paramètre
si c'est entre plusieurs UC/forms qu'un truc serait utile on met ca en static dans une lib

concernant l'accès aux données (avant l'utilisation massive d'EF certes) plein de débutants se retrouvaient dans plein de méthode avec 15 lignes de code pour ouvrir la connexion, définir la requete, exécuter la requete etc...
là on fait une classe qui gère l'accès aux données à laquelle on peut spécifier une chaine de connexion, une requete etc... (propriétés) et du coup ca réduit à une ligne ou deux pour exécuter une requête
par la même le code métier devient plus clair en faisant abstraction de l'aspect technique (d'une lecture ou d'un enregistrement ici)

Citation:

---

le tabcontrol c'est le truc qui nécessite des usercontrols
pour chaque tabpage tu fais un UC et tu le poses dans le tabpage
sinon tu te retrouves avec une fenetre qui gère plein de choses, et ca c'est le truc à éviter, une classe (car une form est avant tout une classe) ne doit faire qu'une chose
tout mélanger n'aide pas à s'y retrouver

---

Je vais essayer de creuser du côté des UC, je n'en ai jamais fait.

Citation:

---

concernant l'accès aux données (avant l'utilisation massive d'EF certes) plein de débutants se retrouvaient dans plein de méthode avec 15 lignes de code pour ouvrir la connexion, définir la requete, exécuter la requete etc...
là on fait une classe qui gère l'accès aux données à laquelle on peut spécifier une chaine de connexion, une requete etc... (propriétés) et du coup ca réduit à une ligne ou deux pour exécuter une requête
par la même le code métier devient plus clair en faisant abstraction de l'aspect technique (d'une lecture ou d'un enregistrement ici)

---

Si je te suis tu ferais, deux méthodes, une qui exécute des Insert, UPDATE etc et qui retournerait le nombre de lignes modifiées ou un booléen pour être sur qu'elle se soit bien déroulée.
Et une méthode générale pour tout ce qui est SELECT et qui retourneraient un datatable ou un reader ?

Citation:

---

Envoyé par LecGaël

Je vais essayer de creuser du côté des UC, je n'en ai jamais fait.

---

dans vs faire un form ou faire un uc c'est pareil, t'as une vue du design, tu poses des trucs dessus et tu mets du code
la différence est qu'un form tu l'instancies et tu fais .show et un uc tu le poses sur quelque chose (= instancier + Controls.Add)

Citation:

---

Envoyé par LecGaël

Si je te suis tu ferais, deux méthodes, une qui exécute des Insert, UPDATE etc et qui retournerait le nombre de lignes modifiées ou un booléen pour être sur qu'elle se soit bien déroulée.
Et une méthode générale pour tout ce qui est SELECT et qui retourneraient un datatable ou un reader ?

---

le nombre de lignes modifiées je suis pas fan, c'est pas toujours fiable
après insert/update/delete c'est la même chose, ca peut n'etre qu'une méthode (c'est le cas dans le Framework avec ExecuteNonQuery) et qui retourne un booléen si ca s'est bien passé
pour le select oui soit retourner le reader, soit un datatable, soit autre chose

D'accord, en l'occurrence j'avais déja dissocié deux méthodes, qui retournait un reader, mais est ce que retourner un reader ne comporte pas des risque sachant qu'il ne faut pas oublier de le ".Close()" ? ou alors peut on utiliser using(methode (return reader)){ .....} ?

Donc un UC, je fais comme avec une forme, je code le comportement de la fenêtre en quelque sorte ?
Et si je veux mettre un DGV dedans, quand je serais dans le code de ma form après ma requête, il faudra écrire uc.dgv.datasource = dataTable(reader) ?

les uc pour tabcontrol (ou autre menu) doivent être autonomes
la fenetre ayant un tabcontrol n'aura donc pas de code du tout, le uc se débrouillera pour récupérer ses données lui même (tout comme une fenetre le ferait)
la fenetre peut quand même avoir un peu de code pour gérer le tabcontrol, parfois on veut que quand on change d'onglet celui ci soit rafraichit, auquel cas c'est bien la fenetre qui va dire au uc hébergé de se rafraichir (pour ca une interface avec une méthode refreshdata permet aussi de gérér ca en une ligne de code peu importe le nombre de tabpages)

pour un uc normal (genre regroupement d'un label, un textbox etc...) on accède pas à ses sous controle normalement, il est fait pour être un peu autonome
on peut par contre lui rajouter des propriétés comme datatable DataToShow {get;set;} et dans le set on renvoi ce qu'on recoit vers le datagridview hébergé


retourner un reader c'est bien et pas bien à la fois
le retourner permet que l'appelant peut traiter les données au fur et à mesure de la lecture, ce qui est parfois une bonne idée, mais pas toujours non plus
retourner juste les données (datatable ou autre) permet de s'assurer du .close et de verrouiller moins longtemps les données (et aussi de ne pas laisser l'appelant utiliser un objet sql) (perso je suis sur cette solution)


après sur une classe d'accès aux données il faut penser à plein de choses pour avoir une converture assez complète, comme une propriété parameters qui permet de gérer les requetes paramétrées, des méthodes pour les transactions etc...

Auriez vous des sources, des exemples de codes pour de tels UC ?

Tels quoi ?

Des User control avec des datagridview ?

Si tu sais faire un form avec un dgv tu sais faire un uc avec un dgv, comme dit précédemment c'est pareil

Très bien je vais essayer de développer ça, je vous tiendrais au courant :D

Personnellement, je préfère passer par des objets métier plutôt que des DataTable.
Ensuite, rien n'empêche ces objets métiers d'utiliser et exposer un DataTable, mais l'avantage c'est que tout le code "métier" sera géré au niveau de l'objet et non dans l'UC.

Ainsi, quand on affiche un écran de commande, qui expose un premier datatable avec juste la ligne de commande, et un datatable avec un get;set; pour les lignes, un autres pour les livraison, etc.

Et lors du premier appel du get d'un datatable, vous lancer le chargement effectif des données.
Dans votre code, vous appelez une seule fois la commande, et lors de l'affichage du tabcontrol qui contient les lignes, vous n'avez qu'à appeler commande.lignes sans vous poser la question de comment les récupérer.

Quand vous parlez d'objets métiers vous voulez dire que vous faîtes des classes pour chaque objet de votre base de données ?

Car c'est pour moi encore un grand mystère, est ce qu'il faut créer des objets en c# de ce que l'on récupère via la base de données ?

Je trouve ça en effet plus pratique.

Par exemple, si vous chargez un client depuis votre base de données, et que vous voulez afficher trois userControls :
- UCClient : affiche le détail du client
- UCListeCommande : affiche une liste de commandes
- UCListeTelephone : affiche une liste de téléphones

Dans le premier, vous voulez les détails du client, et dans les autres, respectivement les commandes du client et la liste des numéros de téléphone du client.

Ce sera appréciable de faire :

Code:

---

1 2 3 4

myUCClient.DataSource = client; myUCListeCommande .DataSource = client.Commandes; myUCListeTelephone .DataSource = client.Telephones;

---

Et laisser la classe Client faire le boulot de charger les commandes du client et ses numéro de téléphone.

Ensuite, chaque commande et numéro de téléphone seront eux-mêmes des objets, comme ça vous pouvez définir ce qu'il se passe quand on en ajoute un, supprime un, met à jour un… etc.

Il ne vous restera alors dans les UC qu'à gérer l'affichage et les règles liées à l'affichage (si tel champ est vide, alors untel est grisé, etc.)

y en a qui utilisent des générateurs de code pour créer ce genre de classe, taper des propriétés c'est pas super cool non plus

sinon tu peux regarder du côté d'entity framework
dans visual studio tu lui dis où est ta base de données, il créé toutes les classes et les liaisons entre elle
et après en une ligne de code tu peux lui dire que tu veux la liste des clients qui ont telle valeur dans telle colonne, et que tu veux récupérer les commandes et les lignes de commandes
il génère la requete lui même et remplit les objets
et après tu as la souplesse de faire SelectedClient.Commandes ou autre ...
et après tu peux ajouter un client ou une commande, supprimer une ligne de commande ... et faire .save, et il génère les requetes pour sauvegarder les modifications

en général les débutants aiment bien ca, ca évite d'avoir à coder et à apprendre le sql

Pour l'instant le gros point bloquant pour moi, c'est de coder l'interface avec les datagridView etc.
Pour ce qui est du SQL je ne trouve pas ça bien compliqué.
Là où j'ai essayé des choses et j'ai échoué c'est d'utiliser des OledBDataAdapter avec des requêtes "jointées" je n'arrive pas à gérer le CRUD avec ça.
Du coup je me suis rabattu sur des requêtes SQL simples et dans ma BDD qui est sous Access j'ai fait mo schéma relationnel avec suppression en cascade etc...

Pour ce qui est des objets ça m'intéresse, mais je ne vois pas comment le mettre en application, à quel moment "hydrater" les objets métiers avec les données de ma base, etc...

Pour ce qui est de entityFrameWork, c'est un ORM comme LinQ ? je ne sais pas si ça fonctionne avec Access... je me rends compte que c'est vraiment de la m**** Access...

Linq c'est pas un orm c'est un genre de language fonctionnel intégré à c#, linq to sql ca devait en être un mais ef est son remplaçant.
Et oui access c'est nul, sql server express est gratuit en plus...

Citation:

---

Envoyé par Pol63

Et oui access c'est nul, sql server express est gratuit en plus...

---

Hélas la décision ne me revient pas...
Je suppose que EF ne fonctionne pas avec Access ? x)

Je sais pas mais en général au lieu de supposer il vaut mieux demander à google

Il existerait un provider EF pour Access mais je n'ai pas trouvé de doc :/

Citation:

---

Envoyé par LecGaël

Hélas la décision ne me revient pas...

---

En effet, la décision ne vous appartient pas, mais en tant que professionnel de l'informatique, vous devez indiquer les points qui vous semblent incompatibles avec le bon déroulement des développements et de l'utilisation ultérieure de l'application.

Access a un seul et unique avantage : il dispose de son propre moteur de GUI qui permet à des non développeurs de produire aisément les écrans nécessaires pour gérer leurs données sans avoir des compétences informatiques approfondies.
=> En gros, l'avantage d'Access est de permettre à n'importe qui de faire de la merde

Ensuite, Access n'a que des inconvénients :
- Onéreux : il faut une licence Office "complète" par poste pour pouvoir en bénéficier
- Ne tient absolument pas la charge : dès que la base commence à grossir Access devient inutilisable, et pire que ça, on risque la corruption des données
- Mono utilisateur : travailler à plusieurs dans Access en partageant le fichier sur un disque réseau est extrêmement dangereux
- Non respect des règles élémentaires de la norme SQL : par exemple, utilisation de * au lieu de % dans les like
- Support très pauvre des fonctionnalités SQL : la couverture du SQL d'Access n'englobe même pas SQL89 dans son ensemble
- Peu performant : à part travailler dans des fichiers XML à la main, vous aurez du mal à trouver plus lent qu'Access

Bref... si vous ne pouvez pas prendre la décision, demandez au moins quelles sont les motivations à utiliser Access à tout prix, et n'hésitez pas à argumenter pour ou contre les différentes solutions. Après tout, c'est votre métier.

Les alternatives à Access :
- SQL Server Express ou SQL Server LocalDB : gratuit, aisément packageable avec le programme, très performant, multi-utilisateur, limitations largement supérieures à celles d'Access, la plupart des exemples, tutos et docs C# utilisent SQL Server
- SQLite : gratuit, intégrable directement dans le programme, très performant pour de petites bases, mais mono utilisateur, limitations largement supérieures à celles d'Access, le reste des exemples, tutos et docs C# utilisent SQLite
- Vous pouvez aussi partir sur d'autres SGBD plus ou moins gratuits que sont PostgreSQL, MySQL ou Oracle XE par exemple, mais ils n'apporteront rien de mieux par rapport à SQL Server Express ou SQLite

Je suis d'accord avec vous et j'ai essayé de vendre SQL server sans réussite, je ne suis qu'un apprenti en Électronique et informatique industrielle, lorsque je parle d'informatique à mes supérieurs c'est comme si vous tentiez d'expliquer les couleurs à un aveugle...

Il existe des moyens de se protéger au moins en partie de ce genre de contraintes et qui répondrait à ton besoin de clarté et ça consiste à faire des modules logiques avec chacun ses propres responsabilité. Je ne sais pas quel est l'état actuel de ton code, mais souvent du code de débutant ça ressemble à une fonction button1_click de 150 ligne qui crée une requête SQL en dur avec des string concaténée à des textbox1.Text, ouvre connexion, envoie la commande et fait tout un tas d'autres choses ; c'est comme ça, on en est tous passé par là avant d'apprendre à faire mieux. Peut-être que pendant ta formation on t'a présenté des modèle comme MVC (Model / View / Controller) ou les architectures 3 couches (Présentation / Métier / Persistance). Bien que ces modèles datent un peu ils restent souvent pertinents.

Ma proposition serait de faire plusieurs dll à côté de ton exécutable applicatif :
- une couche de contrats de services ;
- une couche de services implémentant les contrats de services ;
- une couche de contrats de persistance de données ;
- une couche de persistance concrète implémentant les contrats de persistance ; en l'occurrence tu planquerais dedans tous les appels à Access.

Concernant l'interface graphique le conseil de créer des UserControls spécifique reste valable. Ça peut paraître un peu lourd comme ça et c'est vrai qu'il est parfois un peut fastidieux de devoir modifier plusieurs composants pour une évolution mineure. Mais il y a d'abord un gain immédiat en terme de lisibilité et de répartition des responsabilités : par exemple une règle métier trouvera naturellement sa place dans la couche de services. Par ailleurs il pourra y avoir un gain en cas d'évolution de méthodologie. Par exemple si tu obtiens l'abandon d'Access au profit d'une base de données en ligne tu n'auras que la couche d'accès aux données à modifier ; s'il est décidé de remplacer l'application en client lourd par une application web il n'y aura que la partie web à créer, le reste sera parfaitement réutilisable.

J'adorerais apprendre tout ça ! mais vers quels source je peux m'orienter pour apprendre ?

Idéalement il faut être dans une équipe avec des gens qui maîtrisent tout ça.
Si tu es le seul développeur ça va être compliqué de faire une archi complexe.
Après il faut aussi voir le besoin sur l'appli. Si c'est une appli interne utilisée par une seule personne développer des webservices sera une perte de temps.
Par contre faire une couche d'accès aux données (DAL) ça permettra de la modifier plus tard.
Ça en gros c'est une ou plusieurs classes que tout le monde appelle des qu'il veut lire ou écrire dans la base et seule la DAL contient des requêtes et des accès à la db.

D'accord, peut être un jour qui sait :/

C'est effectivement le cas idéal que je présente, en pratique il n'est pas toujours possible de faire comme on veut. Dans le cas présent je pense quand même que tu te faciliteras la vie en faisant au moins une DAL, comme le conseille Pol63.