Discussion :

[PilloBuenaGente]

Bonjour,

Serait-il judicieux pour un programme en mode console d'appliquer le mvc ainsi ? :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
Model model;
View view;
Controler controler;
 
while( model.run())
    view.print( model.work( controler.recive()));

( print ne renvoie rien, work revoit un vecteur de string, et recive revoit une string )

Je pense que, à défaut de perdre en flexibilité, je vais gagner en organisation. Mais je me trompe peut être.

Qu'en pensez vous ?

[Astraya]

Bonjour,

Pour un programme en mode texte ( console ) je doute que le MVC soit approprié. Quel est ton objectif final en faisant ça?

[white_tentacle]

C’est toujours une bonne idée de séparer l’interface (la vue) du cœur du programme (le modèle et le contrôleur).

Par contre, je ne comprends pas ta boucle. model.work, ça me hérisse : le traitement doit se faire au niveau du contrôleur (qui agit sur le modèle), pas du modèle.

Idem pour controller.receive --> c’est plutôt la vue qui reçoit des commandes, qu’elle transmet ensuite au contrôleur (qui est indépendant d’une vue particulière).

[Médinoc]

En fait, ce serait plutôt une boucle du genre:

Code C++ :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
Model model;
View view;
Controler controler;
 
do
{
	view.display(model);
	Input input=view.read();
	controler.work(model, input);
}
while(!controller.quitting);

[koala01]

Salut,

Il est toujours utile de découper très finement les différents éléments et de prévoir de travailler selon le principe MVC.

Et je vais même aller plus loin : si tu peux travailler avec des abstractions pour tes classes View, (Input, introduite par Médinoc) et Controler, c'est encore mieux.

Sait-on jamais : As-tu la certitude absolue que ton programme restera en ligne de commande "ad vitam"

On ne connait rien de ton projet, et l'on ne saura de toutes manières pas répondre à ta place, mais, à moins que tu ne crées un service (quelque chose qui tourne en tâche de fond), il me semble difficile d'avoir une telle certitude... Et encore!

Si, un jour, tu décides de rajouter une interface graphique à ton programme, et d'utiliser non plus le clavier mais les événements souris (entre autres) pour introduire tes commandes, tu seras bien content d'avoir utilisé une abstraction pour ta vue, ton contrôleur et ton système d'entrées car les adaptations ne signifieront pas que tu dois "tout casser" pour venir les greffer

[PilloBuenaGente]

Merci pour votre temps !!

Astraya -> L'objectif était d'avoir une forte contrainte d'organisation pour m'aider à construire le tout.
( Plus j'en apprends sur le c++, moins je vois comment organiser mes affaires.. La digestion m'est longue. )

white_tentacle -> J'y vois plus clair sur le MVC.

Médinoc ->Très clair maintenant !
On peut donc avoir un main ainsi ?! Ni plus ni moins ?!

koala01 -> La modularité n'était pas mon objectif premier mais en effet, ça peut s’avérer utile ! ( Le jour ou je me lancerais sur Qt )

si tu peux travailler avec des abstractions pour tes classes View, (Input, introduite par Médinoc) et Controler, c'est encore mieux.

EditPour, par exemple, pouvoir switcher dynamiquement d'un contrôleur à un autre ?Désolé

[Kaamui]

En fait, ce serait plutôt une boucle du genre:

Code C++ :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
Model model;
View view;
Controler controler;
 
do
{
	view.display(model);
	Input input=view.read();
	controler.work(model, input);
}
while(!controller.quitting);

Moi j'aurais plutôt dit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
Model model;
View view;
Controler controler;
 
while (view.isOpen())
{
   Input input;
   if (view.getEvent(input))
      controller.work(input, model);
   view.diplay(model);   
}

Ce qui revient presque au même je te l'accordre



Sinon pour le code, je ne pige pas pourquoi tu as un controller.work suivi d'un model.update ?

Pour les premières questions, ton model peut contenir la liste de tes id, s'il s'agit d'une espèce de type énuméré c'est tout à fait recevable en tant que donnée du modèle (personnellement j'ai tendance à considérer les models dans un MVC comme des classes de données brutes plus que des classes de services). Après si tu as une liste de choses qui concernnent toute ton application sans forcément concerner ton modèle en particulier, tu peux passer par un bete fichier plat de configuration, ou une classe de base pour que ce soit conceptuellement plus juste en terme de vision humaine.

Pour ta deuxième question oui si tel est ton besoin les templates ou l'héritage peuvent etre emplyés à cela.

[PilloBuenaGente]

Lors du changement de page, je change à la fois le contrôleur et la vue, je ne peux donner cette charge au contrôleur ?!

Pour les premières questions, ton model peut contenir la liste de tes id, s'il s'agit d'une espèce de type énuméré c'est tout à fait recevable en tant que donnée du modèle (personnellement j'ai tendance à considérer les models dans un MVC comme des classes de données brutes plus que des classes de services). Après si tu as une liste de choses qui concernnent toute ton application sans forcément concerner ton modèle en particulier, tu peux passer par un bete fichier plat de configuration, ou une classe de base pour que ce soit conceptuellement plus juste en terme de vision humaine

Merci pour ces précisions. Je vais peut être rajouter un accès à une database (données brut) via mon modèle.

(personnellement j'ai tendance à considérer les models dans un MVC comme des classes de données brutes plus que des classes de services)

Mais, comme le disait Koala01, si j'implante ces services dans le contrôleur, cela impliquera de retoucher aux algorithmes d'accès pour changer d'interface.