Refactoring de code JAVA en MVC

Fermé
zakilife - 17 juil. 2015 à 14:49
nichola Messages postés 111 Date d'inscription jeudi 7 juin 2007 Statut Membre Dernière intervention 24 avril 2016 - 22 juil. 2015 à 15:35
Bonjour,

Je travaille actuellement sur une IHM développé 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,


A voir également:

1 réponse

nichola Messages postés 111 Date d'inscription jeudi 7 juin 2007 Statut Membre Dernière intervention 24 avril 2016 11
Modifié par nichola le 17/07/2015 à 17:32
Salut,

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

Je dirai qu'en principe oui

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

L'action en elle même n'est pas une vue. En principe, à partir du contrôleur de ta vue, tu devrais avoir accès à ta vue. Donc c'est au niveau du contrôleur que tu vas attacher l'événement sur ta vue. Du coup généralement on implémente directement la méthode abstraite de l'action au niveau du controleur, mais si l'implementation de celle-ci est trop longue, bien sûr il faut faire une classe. Pour moi avoir une classe qui étend AbstractAction au niveau du package Contrôleur n'est pas choquant puisque de toute façon il finira dedans...

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

Il me paraît assez clair que çà doit aller dans le package vue .

Edit:
Si par "graphiques", tu veux dire images. Ca va dans le package vue mais au niveau des ressources
0
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?
0
nichola Messages postés 111 Date d'inscription jeudi 7 juin 2007 Statut Membre Dernière intervention 24 avril 2016 11
22 juil. 2015 à 15:35
En principe tu devrais avoir un projet séparé pour la partie client, et un autre pour la partie serveur qui est lui même séparé en plusieurs partie.

Pour la partie client c'est que j'ai expliqué en précédemment, et pour la partie serveur tu devrais avoir:

- un sous projet pour la partie service: contient tous les services métiers de ton appli que tu es censé appeler au niveau du contrôleur.
Dans cette couche tu peux retrouver une partie "DAO" qui va consister à accéder à la BDD, parfois cette couche est séparée dans un projet à part entier.
Tu peux également avoir

- un sous projet pour la partie modèle ou DTO qui contient les entités métiers qui transitent entre le client et serveur - utilisé aussi bien au niveau des services que du client

Bon c'est pas forcément une règle absolue d'avoir des projets découpés comme çà, mais c'est le découpage le plus commun il me semble
0