Concevoir une architecture MVC

Bonjour,

Je suis actuellement en train de coder une application Java pour un stage.
Je tente de respecter l'architecture MVC mais j'avoue que je ne sais jamais si ce que je fais est correct, je code un truc, j'hésite, je le modifie, je supprime tout, je recommence, je rechange... J'hésite vraiment sur la façon d’interagir entre classes concernant la gestion du modèle...

Pourrait-on m'aider ? (Je peux passer la source zippé mais pas tout copier-coller). Voici comment j'organise actuellement l'application pour gérer un ajout d'un objet du modèle :

La vue (package v) remplit le formulaire, si le formulaire est valide, il crée un objet (package m) et l'envoie au controleur avec l'action à effectuer (ADD).
Le controleur (package c) va alors après des tests de conformité tenter d'ajouter l'objet dans la base de donnée et s'il réussis, ajouter cet objet à une collection de cet objet qui se trouve dans une classe Repository (package m), puis le controleur va appeller une méthode de la vue en renvoyant l'objet qui sera alors affiché (ou appel d'un message d'erreur si l'opération a échouée).
La suppression et la modification procède de la même facon.
Pour ce qui est du simple affichage, la vue se sert librement dans la classe Repository (package m) sans rien modifier.

Cela respecte-t-il le MVC, tant le procédé que le placement des classes dans les bons packages ?
Merci d'avance

Ne prends pas ce que je te dis pour argent comptant : des personnes plus expérimentées pourraient avoir un avis différent, mais moi rien ne me choque dans la solution que tu proposes.

D'une manière générale, il ne faut pas non plus attacher une importance plus grande que nécessaire aux patterns. Ils ont une raison d'exister et c'est là-dessus que tu dois te concentrer : Quel est l'intéret du pattern MVC, et est-ce que la solution que tu proposes permet bien de profiter de ces intérêts ?

Il y a toujours plusieurs façon possible pour concevoir une application. Chacune a en général des avantages et des inconvénients par rapport aux autres. Il faut faire un choix et essayer de s'y tenir. Sinon, comme tu dis, tu finis par passer 10 fois d'une solution à l'autre quand tu es confrontée à leurs inconvénients.

L'essentiel, c'est que les rôles soient clairement répartis. Que l'application soit facile à debugguer, à relire, à comprendre.

Merci pour ta réponse, ca me rassure un peu.
Enfait ce qui me stresse c'est que cette application sera présentée à un jury lors de mon examen, d'où l'importance que les choses soient faites aux normes et que je puisse justifier mes choix.

Ce qui me parait étrange c'est l'utilisation d'objet du modèle dans la vue, cela dit c'est justement l’intérêt de la POO, si la vue envoyait et recevrait 50 paramètres séparés de type différents ca serait pas pratique.
Mon autre doute est au niveau de mon Repository, ce ne devrait pas être plutot à lui de gérer la base de données ? mais si oui pourquoi la vue passerait par le controleur ca serait une étape totalement inutile. :/

Encore une fois, ce que je te dis n'es peut-être pas la vision de tout le monde, mais pour moi il y a deux façon de comprendre le rôle du Contrôleur dans le MVC :

Soit tu le vois comme un Big Brother : tout passe par lui et il contrôle tout. Ca peut être un peu pénible à coder parce que tu rajoute des étapes inutiles, mais au moins quand tu veux intercepter un flux d'information, tu peux facilement le faire.

Soit tu fais fonctionner tes classes en triangles et dans ce cas le Modèle et la vue peuvent communiquer entre eux directement par moment. Le contrôleur ne joue alors le rôle que de contrôler les moments délicats.

En fait, on peut dire que ton application respecte le pattern MVC tant que :
- un bug dans la vue se corrige dans la vue
- un problème de modèle se change dans le model
- un contrôle se fait via le contrôleur.

Après, la façon de faire communiquer les classes peut varier grandement selon les sensibilités sans pour autant remettre en cause ce modèle.

J'avais donné une réponse de ma compréhension du MVC ici : http://www.developpez.net/forums/d10...n-3-tiers-mvc/

J'ai trouvé ce tutoriel sinon dont le schéma montre bien qu'il n'y a pas un fonctionnement mettant le contrôleur au milieu de tout mais plutôt une relation cyclique (ou en triangle comme le dit Sharcoux) : http://baptiste-wicht.developpez.com...onception/mvc/

Citation:

---

L'architecture MVC pour une appli avec IHM : Son principe est cyclique puisque d'une action dans la Vue, le Controleur agit en conséquence. Ce Controleur va chercher les informations dans le Modèle qu'il envoie à la Vue pour se mettre à jour.

---

Si on veut être pointilleux, il me semble que le contrôleur signale à la vue qu'elle doit se mettre à jour et la vue a alors le droit de piocher dans le modèle pour se mettre à jour.

Le vrai truc important en fait, c'est que la vue ne doit pas modifier le modèle sans passer par le contrôleur, ceci afin d'assurer la stabilité du modèle et de ses données.