Discussion :

[gagalive]

Slat à tous.J'ecris actuellement un programme java qui doit cmmuniquer avec une banque de données.J'ai deja reussit à établir le lien entre java et la banque de donnée(MySQL Databases).A present je ne sais plus exactement omment je dois continuer.Je veux dire le lien entre le GUI et la banque de données.Comment je dois structurer les classes.
Merci dejà à l'avance

[Regis.C]

...A present je ne sais plus exactement omment je dois continuer.Je veux dire le lien entre le GUI et la banque de données.Comment je dois structurer les classes.
Merci dejà à l'avance

Il n'y a pas de règles. C'est lors de ton analyse et de ta conceptualisation des cas d'utilisations que tu as du architecturer ton application et les interdépendances de tes objets...
C'est à toi, en fonction de ce que tu veux faire, et à qui tu veux le faire faire, de déterminer la structure de tes classes.

On ne peut pas vraiment te répondre sur ce coup...
Quel est exactement ton problème ?

[gagalive]

Merci de ta reponse.En fait je voulais savoir quel est le procede standard lorsqu'on veut faire comminiquer java avec une banque de donnée(Mysql ) via un GUI.Il s'agit en fait de gerer(y compris ajouter de nouveaux utlisateur) un groupe d'utilisateurs dont les donnés personnelles sont stoquées dans la base de données. Evidement tout ceci via le GUI.

[Regis.C]

Le fait d'avoir un GUI n'intervient en rien dans ta gestion de la communication avec une BDD.
Tu as 2 choses bien séparées :
- D'un côté ta couche GUI
- De l'autre une couche métier.

Je suppose que tu devrais avoir une classe "Utilisateur" et une classe "Groupe" qui sera instanciée en rapport avec le nombre de groupes, chacun des groupes étant composé d'une liste d'objets utilisateur, vu que tu va manipuler des groupes d'utilisateurs (jusque là pas besoin d'être ingénieur ;-) ).
Côté BDD, c'ets à toi de voir (ce que tu aurais du déjà prévoir lors des cas d'utilisation... ) soit pour chaque utilisateur instancié tu interroges la BDD pour initialiser des variables privées avec accesseurs (nom, prénom, ...), soit c'est uniquement lors d'une requete précise de l'utilisateur que tu interroges la BDD selon la requette du client.

Tu sais, c'est difficile de faire une analyse d'une appli dont on ne connait rien !
Tu es le mieux placé pour réaliser une architecture cohérente en fonction de ta connaissance de ton cahier des charges, tes cas d'utilisations, etc.

Dur de t'aider d'avantage.

[gagalive]

Bien le merci Regis.Voici en gros le probleme à resoudre.Il faut ecrire un programe JAVA facilitant la gestion de la cantine dans une firme(max 25 Personnes).Chaque utilisateur doit etre à meme à partir d'un systeme où le dit programme est intallé,pouvoir commander un repas.Dans la firme il ya un utiisateur ROOT qui administre(ajouter un nouveau compte,controle passwort,...) les comptes de chaque utilisateur.
Un grand merci pour ton aide

[Regis.C]

1) Identifies tes acteurs.
J'en voit au moins 3 : l'utilisateur, l'administrateur, et le système (ton programme) qui sera dans la plupart des cas d'utilisation un acteur secondaire.

2) A chaque cas d'utilisation, détermine tes scénarios.
Que fait l'utilisateur, que fait le système, etc.

3) Poses sur papier une première ébauche de ton architecture logicielle en organisant tes objets incontournables : Utilisateur, Administrateur (a voir si c'est une classe ou un comportement spécifique d'un utilisateur), Repas, Compte, etc. pour ta couche métier.

4) Poses sur papier une ébauche de ta couche System : communication avec la BDD, avec quel module, stockage des infos ou requête à la demande, etc.

A partir de là, ta couche GUI n'est pas importante, c'est juste la gestion d'affichage des infos pour ton utilisateur, mais le gros de l'appli se passe dessous. C'est avant tout cette partie "cachée" qu'il faut convenablement architecturer et implémenter.
Ensuite c'est une conception graphique qui organise la façon dont tes utilisateurs vont demander et recevoir des informations.
Si tes cas d'utilisations sont bons, ta GUI devrait déjà être moins floue (menus incontournables, sous menus, fenetre de commande de repas, etc.).

Régis.