Version imprimable
Bonjour,
J'ai lu des articles sur le MVC mais j'ai toujours un peu de mal.
J'ai du mal à voir dans mes classes Java, quelle classe contiendra un attribut pour contenir les autres composants...
J'ai mes 3 classes :
controller
view
model
Mais qui va contenir qui ?
est-ce que c'est que le controller qui a 2 attributs pour avoir le model et la vue ?
Merci de m'éclairer
++
Le pattern MVC c'est plus un concept et une théorie. Et dans la pratique, le pattern MVC est implémenté de différentes façons.
L'idée est toujours la même.
Il y a un controller (qui parfois peut déléguer du boulot à d'autres controller). Ce controller fait des appels à une couche métier (model). Cette couche métier fait son travail (accès à une bdd et tout un tas d'autres choses, mais tout ça ne rentre pas dans le scope du MVC). Le controller récupère éventuellement des données en provenance de la couche métier, et passe la main à une vue pour l'affichage à l'utilisateur.
Il y a plusieurs framework qui proposent une implémentation du MVC. Les plus connus dans le monde Java pour le web étant Struts, et JSF.
Il y a quelques années je me posais exactement la même question que toi. Le mieux à faire c'est de te lancer dans l'apprentissage d'un de ces framework.
le model = les objets metier , ce sont ces objet qui contient les attributs (id, nom, age + les get&set de chaque attribut pour respecter les norms)Citation:
Envoyé par italiasky
la vue ou view = c'est à part ! ce sont des pages (jsp par exemple) pour afficher les resultats et/ou recupérer les données saisies par l'User (càd interagit avec l'User)
le Controleur = c'est l'Orchestre (reçoit la requete de Client et c'est lui seul au sein de ton application qui sait bien vers quel Action il va l'envoyer...)
Tout ça cette blabla est à l'étage PRESENTATION;
à l'étage en bas! le METIER ! ici y a autre blabla celle de Traitement ...
cet étage en général a besoin de descendre à l'étage en dessous celui de PERSISTENCE qui persiste les Données physique dans ta Base
ceci just une breve intro !
en plus:
il faut destinguer entre:
1) l'Architecture 3 tiers :
Client(browser)||Application(Serveur d'application)|données(SGBD)
2) le model MVC ou MVC2:
M + V + C =! c'est pas 3 de 3Tiers!
MVC c'est un design pattern qui facilite le developenet de la couche Presentation SEULEMENT! il touche pas ailleur!
on l'implemente grace à STRUTS ou JSF ...
3) les celebre 5 couches:
(selon les nominations)
PRESENTATION
METIER
SERVICE
PERSISTENCE
BAZDONNEES
encore une fois MCV il joue au niveau de PRESENTATION (étage 5) avec ces M,V et C (3 elements) et toute cette application est déployée au sein d'un Serveur d'application tomcat par exemple et constitu un tiers à coté de tiers browser de Client et le tiers SGBD oracle par exemple. ce qui fait (3 tiers)
j espere que c bien
Merci de vos réponses mais en fait mon projet ne va pas si loin je pense.
On ne doit pas utiliser un framework mais juste implémenter notre programme avec le design pattern MVC; en gros pour qu'on sépare un peu le traitement, de l'affichage, des données quoi...
Ca je comprends très bien les 3 parties mais le problème c'est au moment de l'implémenter, de faire mes classes...
J'ai une classe Jeu qui contient et décrit le jeu sur lequel le projet se porte.
Ensuite, je vois 3 classes : Controller, Model, et View
Pour moi, la classe model doit contenir mon jeu, ainsi j'ai :
Mais ensuite comment lié le Controller, le Model et la View... D'une certaine manière il faut bien qu'ils soit reliés non ?Code:
2
3
4
5
6
7
8
9
MerciCode:
2
3
4
5
6
7
8
9
10
11
12
13
14
++
Le M de MVC est bien le Modèle.
Ce pattern gère principalement la couche Présentation. Mais la couche Métier peut aussi être inclue si on considère le Modèle comme la couche Métier.
Pour ce qui est des liens entre objets :
- le Modèle contient la logique de manipulation des objets métier (méthodes de calcul, de modification des attributs des objets métiers et de maintient de cohérence des données métier) ; elle peut déléguer une partie des traitement à des sous-couches (ex : utilisation de procédures stockées),
- la Vue implémente un Observateur (Pattern qui observe les changements d'un Observable, ici ton Modèle) ;
- ce n'est qu'une vue, elle ne sait rien faire qu'afficher des données... on lui dit "ceci doit être coché" et elle s'exécute ; si on lui dit affiche telles données du modèle, elle sait comment les afficher, point barre
- en tant qu'observateur elle s'enregistre (ou plutôt se fait enregistrer) auprès du Modèle et doit connaître celui-ci à un moment donné (donc il y a une dépendance, au moins à l'interface Observable implémentée par le Modèle) :
lorsque le Modèle informe ses Observateurs (dont le principal, voire le seul, représentant est la Vue), il fait appel à la méthode update()
Là deux possibilités :
- Méthode PULL (l'observateur, càd la Vue, "tire" les données dont il a besoin) : si un composant implémente un observateurDeTruc la méthode sera concrètement updateTruc(TrucObservable modele) car l'Observateur se passe en paramètre ; la Vue appelle alors uniquement les méthodes qui lui permettront d'obtenir les éléments "Truc" qui lui sont nécessaires.
- Méthode PUSH (l'observateur "envoie" les données utiles à la vue) : la méthode sera concrètement updateTruc(donnéesTruc_du_modèle).
- le Contrôleur implémente une sorte de Stratégie (autre Pattern) ; il connaît la vue puisqu'il la contrôle (littéralement : il initialise les composants, sait que cliquer ici doit désactiver cela, etc), mais également le modèle puisqu'il traduit les actions sur la Vue en "manipulations" sur le modèle ; ce sont ces modifications du modèle qui vont déclencher les messages vers la vue en retour. On parle parfois de pattern Mediateur pour le contrôleur (notamment dans MVC2 ou la vue est totalement décorrélée du modèle et doit passer par le Contrôleur pour toutes ses requêtes (notes que j'utilise sciemment requête puisque MVC2 est principalement employé en mode Client/Serveur HTTP).
Concrètement :
- le modèle aura une référence aux composants de la vue qui l'observent (sauf dans MVC2)
- le contrôleur aura une référence au modèle (pour le manipuler) et à la vue (pour la contrôler)
- la vue aura une référence au contrôleur (pour lui notifier les actions effectuées)
Tu peux aussi passer par des interfaces pour réduire la dépendance entre ta vue et ton contrôleur (tentes d'extraire des abstractions pour les méthodes).
Bon courage.