Discussion :

[zakilife]

Bonjour,

Je travaille actuellement sur une IHM développée en JAVA. Je dois refactorer le code et le transformer en pattern MVC.

L'application contient plusieurs packages (actionsboutons, actionsmenu, interfacegraphique, receptiontrame ...).

Merci de m'orienter sur quelques pistes suivant les questions ci-dessous selon votre expérience:

-est-ce je dois créer 3 packages (modèle, vue et contrôleur) et repartir tous les classes la-dedans?

-le package actionsboutons contient les classes d'écoute des boutons que l'ihm contient, ces derniers sont l'extension de la classe AbstractAction. De ce fait, est-ce que ce package appartient au modèle ou bien au contrôleur car il contient les traitements enclenchés après les cliques sur les boutons. Est-ce que je dois rapporter des changements, genre MVC n'acceptent pas AbstractAction?

- J'en ai aussi un package "dessin" contenant des graphiques qui se dessinent dans le canvas de l'ihm, la même question précédente, je dois les répartir où exactement?

-Quelqu'un aurait la possibilité de publier un exemple bien évolué sur le pattern MVC en java car tous les exemples que j'ai récupérés sur Internet sont de base.


Merci par avance,

[autran]

ton IHM à migrer est en SWING .... ?
tu veux migrer vers quelle techno SWING JAVAFX ?

[damtoul]

Bonjour,

Je suis fan du modèle MVC et je développe en amateur autour de ce modèle. Voici comment je fais globalement, à toi de voir si tu veux/peux adapter :
- J'ai une classe Controller qui contient le JFrame qui contient un content panel avec un cardlayout. Ca me permet d'accéder à toutes les pages principales du logiciel. Controller contient aussi tous les listeners et leurs actions. Controller instancie toutes les sous-classes Controller.
- J'ai fait des sous-classes Controller qui implémentent une interface : ces sous-classes correspondent à une page principale du logiciel et contiennent tous les composants pouvant être écoutés de cette page.

-De même tout ce qui concerne les composants qui ne sont pas écoutés/d'affichage sont mis dans des sous-classes Vue et fait sur le même modèle que Controller : Vue instancie toutes les sous-classes vue.

- Tout ce qui est calcul et logique métier transite par la classe Model et est appelé par la classe Controller ou Vue.

Bref je ne sais pas si je suis très clair, mais cette organisation est très facile à maintenir car suivant le problème à corriger ou l'évolution à apporter, je sais très vite de quelle classe ça vient.

Pour répondre à ta questions sur les packages d'écoute sur les boutons, si c'est M ou C : tout ce qui est écoute et action=>c'est dans le controller qui appelle des méthodes dans le model qui lui derrière s'occupe de faire les calculs et renvoie le résulat par la méthode appelée. Donc si l'action concerne une modif graphique, ça reste dans le controller qui gère tout, si l'action demande un calcul/modif de données ça passe par le model qui renvoie le résultat au controller qui modifie ou pas l'IHM.

[zakilife]

@damtoul
Merci pour votre réponse détaillée. ça m'a éclairé pas mal de choses.

J'en ai également là-dedans une architecture serveur/client et une classe qui gère la connexion à la base de données, j'ai utilisé les threads. Où dois-je répartir tout ça?

Si vous aurez par hasard un exemple que vous avez développé et que vous pouvez le partager, n’hésitez pas. Merci encore une fois.

[damtoul]

@damtoul
Merci pour votre réponse détaillée. ça m'a éclairé pas mal de choses.

J'en ai également là-dedans une architecture serveur/client et une classe qui gère la connexion à la base de données, j'ai utilisé les threads. Où dois-je répartir tout ça?

Si vous aurez par hasard un exemple que vous avez développé et que vous pouvez le partager, n’hésitez pas. Merci encore une fois.

Perso, en respectant le modèle MVC tu gardes tout ça dans tes classes actuelles : action utilisateur=>le C appelle les méthodes dans le M qui a instancié tes classes serveur/client et qui va donc chercher les infos dans ta BdD via ta classe de connexion. Les infos sont soit récupérées et envoyées vers la V, soit juste mises à jour et la vue va les récupérer à la demande du C.
Tu as donc juste à créer une classe Model qui va servir de relais pour accéder à ta logique métier : calcul, requêtes client/serveur, base de données, etc...

Pour les threads je dirais que ça ne concerne pas le modèle MVC c'est juste de la tambouille interne aux classes.

Pour un exemple oui j'ai développé une appli en archi MVC mais c'est bien trop lourdpour être posté ici. J'ai une base de données locale, et dans mon cas mon M instancie une classe dbase qui a pour attributs les différentes classes/données. Le M se sert dans this.dbase pour renvoyer/mettre à jour les données sur ordre du C.

Bonne journée.

[zakilife]

Perso, en respectant le modèle MVC tu gardes tout ça dans tes classes actuelles : action utilisateur=>le C appelle les méthodes dans le M qui a instancié tes classes serveur/client et qui va donc chercher les infos dans ta BdD via ta classe de connexion. Les infos sont soit récupérées et envoyées vers la V, soit juste mises à jour et la vue va les récupérer à la demande du C.
Tu as donc juste à créer une classe Model qui va servir de relais pour accéder à ta logique métier : calcul, requêtes client/serveur, base de données, etc...

Pour les threads je dirais que ça ne concerne pas le modèle MVC c'est juste de la tambouille interne aux classes.

Pour un exemple oui j'ai développé une appli en archi MVC mais c'est bien trop lourdpour être posté ici. J'ai une base de données locale, et dans mon cas mon M instancie une classe dbase qui a pour attributs les différentes classes/données. Le M se sert dans this.dbase pour renvoyer/mettre à jour les données sur ordre du C.

Bonne journée.

Merci d'avoir pris la peine pour me répondre, Je comprends le principe et j'ai même opté pour ce que vous avez dit, le truc qui me reste et me semble un peu compliqué c'est la façon d'établir le lien entre le M, V et C.

Ceci est mon mail: zakilife@gmail.com, si vous aurez le temps j'apprécie que vous m'enverriez votre exemple.
Bonne journée

[zakilife]

@Kevinternet
Oui, c'est en SWING.
Je vais pas la migré, je dois juste l'organiser en pattern (modèle/vue/contrôleur).