Discussion :

[Anubis]

Bonjour,

J'ai une question concernant le modèle MVC.
Je ne vais pas refaire ici un cours sur le modèle MVC et ce qui j'y ai compris, je vais me contenter du minimum utile pour ma question.
Pour moi le M qui représente le Modèle dans ce Design partern, correspond aux classes de données de mon application.
Et c'est dans le C qui représente le Controller que je vais aller mettre les traitements permettant de manipuler ces classes.
Je me demandais si c'était la bonne méthode ou si j'avais fait une erreur d'interprétation du pattern.

Je vais prendre un exemple.
Si je fais une application qui affiche dans un tableau une liste de personnes avec certaines informations, ainsi qu'un bouton ajout de personnes.
Je vais avoir dons mon contrôleur une méthode "AjoutPersonne" et elle va construire un nouvel objet Personne de mon modèle et l'ajouter à une liste de personnes de mon contrôleur.

Pensez-vous que c'est la bonne méthode?
Auriez-vous fait autrement?

Merci.

[joel.drigo]

Salut,

La liste de personnes fait aussi partie du modèle. Sinon, oui, le contrôleur va être chargé de réagir à l'action Ajout en créant une instance de Personne et à l'ajouter à la liste. Le modèle lancera un évenement et les vues qui affichent la liste se mettront à jour pour afficher la nouvelle instance le cas échéant.
Dans un MVC métier, le modèle ou le contrôleur ne sont pas forcmément qu'une seule instance d'une seule classe (les actions sont des instances de classes différentes par exemple, qui peuvent d'ailleurs délèguer d'ailleurs à des commandes, encore d'autres instances d'autres classes) .

[OButterlin]

C'est une confusion assez commune du MVC, au début, on mélange souvent des notions...
Pour moi, il faut tout ramener à la Vue (donc ce qu'on présente à l'utilisateur).
Le Modèle représente les données de cette Vue (dans ton cas, avec la liste de personnes en plus de la définition d'une personne).
Le Contrôleur fait juste le lien entre la Vue et le Modèle, un chef d'orchestre en quelque sorte, c'est lui qui prendra en compte toutes les interactions à partir de la vue.

Ça n'empêche pas d'avoir des choses plus complexes, le modèle peut être alimenter à partir de données provenant de la base de données, les contrôles liés aux données peuvent être déportés dans une classe "Métier" spécialisée (EJB par exemple) etc...

[Anubis]

Salut,

La liste de personnes fait aussi partie du modèle. Sinon, oui, le contrôleur va être chargé de réagir à l'action Ajout en créant une instance de Personne et à l'ajouter à la liste. Le modèle lancera un évenement et les vues qui affichent la liste se mettront à jour pour afficher la nouvelle instance le cas échéant.
Dans un MVC métier, le modèle ou le contrôleur ne sont pas forcmément qu'une seule instance d'une seule classe (les actions sont des instances de classes différentes par exemple, qui peuvent d'ailleurs délèguer d'ailleurs à des commandes, encore d'autres instances d'autres classes) .

Donc il faudrait que j'implémente une classe "CollectionPersonne" que je place dans le modèle et qui aurait une méthode "AjoutPersonne" et qui attend les paramètres nécessaire à la création d'une nouvelle personnes. ai-je bien compris ta façon d'implémenter le pattern MVC?

Ça n'empêche pas d'avoir des choses plus complexes, le modèle peut être alimenter à partir de données provenant de la base de données, les contrôles liés aux données peuvent être déportés dans une classe "Métier" spécialisée (EJB par exemple) etc...

Dans ce cas-là comment est-ce que tu considères cette classe métier? C'est une partie du modèle ou un partie du contrôleur?

[OButterlin]

Dans ce cas-là comment est-ce que tu considères cette classe métier? C'est une partie du modèle ou un partie du contrôleur?

Non, c'est une classe à part, elle n'a rien à voir avec le pattern MVC, elle est juste référencée par le contrôleur.

[Anubis]

Non, c'est une classe à part, elle n'a rien à voir avec le pattern MVC, elle est juste référencée par le contrôleur.

OK, tu considères donc que seul une partie de ton application implémente le design pattern MVC mais que l'application n'a pas à coller au design pattern MVC dans sa totalité.
Est-ce que tu es d'accord avec moi sur ce point?

[OButterlin]

OK, tu considères donc que seul une partie de ton application implémente le design pattern MVC mais que l'application n'a pas à coller au design pattern MVC dans sa totalité.
Est-ce que tu es d'accord avec moi sur ce point?

Oui, tout à fait...

Une application peut mettre en œuvre plusieurs pattern, c'est même normal.
Chaque choses à leur place...
MVC pour la couche présentation, Facade pour l'accès aux EJB, etc...

Ce n'est absolument pas incompatible, le Contrôleur (de MVC) peut faire appel à toutes les ressources nécessaires.