Discussion :

[touftouf57]

Bonjour à tous,

Je recherche désespérément comment mettre en place le modèle MVC sur une application client lourds / serveur.

Faut-il un MVC de chaque coté? Je trouve cette idée étrange puisque du coté serveur, il n'y a pas de vue.

Si ce n'est pas cela, peut-on considérer le "serveur" comme modèle?

En fait je dois créer un serveur de jeu de dé.

Sur le serveur j'aurais un socketServer qui écoutera le réseau et lorsqu'il aura le nombre de joueurs(sockets) attendus il les mettra dans un salon pour qu'ils jouent ensemble.
Ce salon lancera d'autres threads. Pour chaque client un thread de communication sera lancé. Et un thread de gestion de partie.

Maintenant coté client
Le joueur devra saisir son pseudo, définir la somme qui veut jouer durant la partie. Je précise qu'une Partie est composée de plusieurs JetDeDes. Mais il y aura aussi le choix du serveur( D6,2D6,D10,2D10,2D20..)[Pour ceux qui ne savent pas un D6 est un dé à 6 faces] J'aurais donc plusieurs serveur de jeu de dé.
C'est la que je me casse la tête, est-ce que cette liste de serveur fait partie du modèle?

J'ai bien saisi que à chaque état du diagramme d'états devrait correspondre un contrôleur. L'application sera donc un enchainement de contrôleurs.
Donc au début je serais à l'état "EnConnection" ou le modèle sera une classe regroupant

• la liste des serveurs
• le pseudo (="")
• le porte monnaie pour la partie (=0)

Et à l'état "EnJeu", le modèle sera sur la Partie coté serveur.

Est-ce que cela semble correct? Ou ai-je tout faux.

Merci par avance

[Yo Eight]

Il ne peut pas avoir de MVC du cote du serveur vu qu'il s'occupe uniquement de gérer des connexions. Sur ton serveur on aurait plus une couche de service, une couche d'accès aux données et la couche métier.

Le MVC est utile quand il y a une couche de présentation. Donc seul ton client lourd sera concerné par ce pattern

[Desboys]

Bonjour,

pour ma part, je pense que ton serveur constitue ton implémentation du Modèle.
Ton client lourd gèrerait alors la partie Vue/Contrôleur. Néanmoins, côté client lourd, je créerai les stubs de modèles ( en appliquant le design pattern Proxy ).

Pourquoi passer par un niveau Socket, et pas par RMI, pour les appels au serveur ?

Pour les questions d'implémentations, de déploiement, etc, je n'ai pas l'impression que tout ça soit clair. Si j'ai bien saisi, l'utilisateur choisit son "serveur de jet de dé" ( qui défini les règles de jeu alors ), défini son pseudo, défini la somme à jouer, et rejoint un salon?

Sébastien

[dida.ratsimba]

bonjour,
MVC doit s'appliquer lorsqu'on doit s'occuper de la couche présentation, et l'accès aux couches inférieures doit obligatoirement passer par le contrôleur qui joue le rôle de chef d'orchestre . Un pattern qui pourrait être utilisé au niveau de la couche métier et la couche DAO est l'adapter pattern.