Discussion :

[totojava]

Bonjour,
J'ai posé une question dans la partie Java du forum car je code en java et je viens de découvrir cette section. Je n'ai pas fini d'éplucher tous les posts qui ont l'air très riche, mais je pose quand même mes questions ici, pour le cas où ça pourrait aller plus vite que de lire quelques centaines de messages .

La question :
http://www.developpez.net/forums/d10...g-pattern-mvc/


PS : éventuellement, je n'ai rien contre le déplacement du topic initial dans ce forum et la suppression de ce nouveau fil. Si un responsable/modérateur passe par là, merci ...

[Patriarch24]

Bonjour,

1) sur le modèle : je distingue nettement deux choses : le concept de dessin (par exemple une maison), et la représentation sous forme de données de ce dessin (par exemple une représentation bitmap ou au contraire une représentation vectorielle). Est-ce que je dois considérer que le modèle est le dessin "abstrait", le concept de dessin, la "possibilité" de représenter quelque chose en 2D, ou bien au contraire sa/ses modélisations mathématiques ?

Le modèle correspond à ton objet Maison (modélisation "mathématique" : pièces, etc.). La vue correspond à la représentation visuelle de ce modèle : un dessin 2D dans ton canevas (ou 3D par exemple).

Dans la mesure où différentes modélisations donneront (aux imprécisions près) la même forme géométrique, j'aurais tendance à dire que ces modélisations peuvent être des modèles de mon domaine. Mais le principe d'abstraction me fait penser qu'il vaut mieux prendre comme modèle le concept de dessin. Le problème, dans ce cas, c'est que je ne vois pas trop quoi coder dans mon logiciel dans la partie "M"...

Là, je ne te suis pas du tout. En fait tu veux découper le modèle en deux partie : modèle mathématique et visuel c'est bien cela ? Je ne comprends pas bien ton problème : tu peux avoir une Vue2D et une Vue3D, interchangeables, qui représenteront le même modèle (Maison) en fabriquant des formes différentes.

a priori, je dirais que la vue, c'est la surface à dessiner, la partie principale de la fenêtre dans laquelle l'utilisateur fait des glisser-déposer de formes prédéfinies pour les assembler entre elles.

Mon questionnement à ce sujet vient de ce que je ne sais pas où mettre le menu et les bibliothèques de formes prédéfinies. D'après ce que j'ai compris du MVC, ça ne fait pas partie de la vue, puisque la vue est la présentation des données du modèles. Or, quand l'utilisateur clique sur l'icône des rectangles pour afficher la bibliothèque des formes rectangulaires, ça ne change absolument rien au modèle, et pourtant la vue globale de l'application perçue par l'utilisateur change... Est-ce qu'il faut considérer que cet ensemble (menu + bibliothèques) fait partie du contrôleur ? (Malgré que ce soit de l'ihm pure et dure...)

Bref, comment séparer et traiter ce qui est "pure Vue" du modèle, et ce qui est "interaction" avec l'application mais sans impact immédiat avec le modèle ou la vue ?

Beaucoup de questions pour une réponse : les menus, boutons et autres sont des représentations d'actions, donc n'ont pas directement à voir avec le modèle. Par contre, quand tu modifies la bibliothèque courante via ton bouton, le modèle se trouve modifié (l'objet Bibliothèque est changé) : il s'agit bien du MVC. Ta confusion vient du fait que tu écartes la bibliothèque du modèle alors qu'elle en fait bien partie : tu écris un logiciel de dessin !

[totojava]

Merci pour ta réponse.

Il faut préciser tout cela car je ne suis pas certain de bien comprendre. Dire que "Le modèle correspond à ton objet Maison", ça me fait penser à un "concept de maison", c'est bien ça ? Dans ce cas, un modèle particulier de ce concept maison, ce serait par exemple une description sous forme de liste hiérarchique du type :
maison = RDC -> entrée(2x1.5x2.4, carrelage(type1), peinture(vert), convecteur)
-> séjour(4x6x2.4, carrelage(type2), peinture(jaune), cheminée)
-> cuisine(...)
->...
1er ETAGE -> chambre1(...)
-> ...
Un autre modèle ce serait l'écriture vectorielle d'un plan 2D accompagné d'une liste des caractéristiques des pièces non représentables sur la vue 2D (murs, etc.). Quelque chose du genre : draw from (0,0) to (2,0) with width .5, then to (2,1.5) with width .5, then...

Dans ce cas, je ne comprends pas cette phrase : "Ta confusion vient du fait que tu écartes la bibliothèque du modèle alors qu'elle en fait bien partie : tu écris un logiciel de dessin !"
La bibliothèque des composants, ça ne fait pas partie du modèle (du "concept") maison : quand je pense à une maison, je ne pense pas à toutes les sortes de cheminées rangées dans une bibliothèque de cheminées, à toutes les sortes de fenêtre rangées dans une biblio de fenêtres, etc.

Pour moi, c'est là que ça coince : il y a le modèle (le concept de maison représenté par un ou plusieurs modèles), la/les vue(s) de ce modèle (éventuellement, même pas obligée en fait !), et les contrôleurs qui font le lien. Mais le menu de l'application (bouton "open", "save", "export to jpg", "ajouter forme", etc.) qui me sert à créer une maison particulière, ça ne fait partie ni du M, ni du V ni du C.

Ce que tu suggères dans la dernière phrase, c'est que le MVC doit être pensé non pas par rapport à une modélisation, mais par rapport au logiciel.... ?

PS : je vais lire l'article sur le MVC tout frais. Mais je pense que mes questions vont subsister .

[Patriarch24]

Dire que "Le modèle correspond à ton objet Maison", ça me fait penser à un "concept de maison", c'est bien ça ? Dans ce cas, un modèle particulier de ce concept maison, ce serait par exemple une description sous forme de liste hiérarchique du type :
maison = RDC -> entrée(2x1.5x2.4, carrelage(type1), peinture(vert), convecteur)
-> séjour(4x6x2.4, carrelage(type2), peinture(jaune), cheminée)
-> cuisine(...)
->...
1er ETAGE -> chambre1(...)
-> ...

Exactement. On devrait plus souvent préciser "modèle" en ces termes : modèle du domaine métier. Si tu veux écrire un logiciel d'architecture 2D, alors ton modèle du domaine correspond aux maisons et leurs composants (voire les meubles si tu veux aussi). Dans le cas d'un logiciel de dessin vectoriel, le domaine correspond aux formes géométriques.

Un autre modèle ce serait l'écriture vectorielle d'un plan 2D accompagné d'une liste des caractéristiques des pièces non représentables sur la vue 2D (murs, etc.). Quelque chose du genre : draw from (0,0) to (2,0) with width .5, then to (2,1.5) with width .5, then...

Dans ce cas, tu crées un logiciel de dessin vectoriel plutôt...

Dans ce cas, je ne comprends pas cette phrase : "Ta confusion vient du fait que tu écartes la bibliothèque du modèle alors qu'elle en fait bien partie : tu écris un logiciel de dessin !" La bibliothèque des composants, ça ne fait pas partie du modèle (du "concept") maison : quand je pense à une maison, je ne pense pas à toutes les sortes de cheminées rangées dans une bibliothèque de cheminées, à toutes les sortes de fenêtre rangées dans une biblio de fenêtres, etc.

Au temps pour moi. Dans le cadre d'un logiciel d'architecture, la bibliothèque de formes fait partie de la vue, et peut-être modifiée via le contrôleur. Tu peux représenter de manières différentes (vues) le même objet du modèle (une cheminée par exemple).

Pour moi, c'est là que ça coince : il y a le modèle (le concept de maison représenté par un ou plusieurs modèles), la/les vue(s) de ce modèle (éventuellement, même pas obligée en fait !), et les contrôleurs qui font le lien. Mais le menu de l'application (bouton "open", "save", "export to jpg", "ajouter forme", etc.) qui me sert à créer une maison particulière, ça ne fait partie ni du M, ni du V ni du C.

Toutes les interactions entre la vue et le modèle se font via le contrôleur. Donc les actions des menus, boutons etc. font partie du contrôleur. Bien sûr, les widgets "font partie" de la vue, même s'il ne représentent pas un objet du domaine mais une action (ce n'est pas une vue du domaine si tu préfères).

Ce que tu suggères dans la dernière phrase, c'est que le MVC doit être pensé non pas par rapport à une modélisation, mais par rapport au logiciel.... ?

Pas exactement. Tu dois aligner ton MVC sur le modèle du domaine métier que tu traites : soit tu crées un logiciel de dessin vectoriel, soit un logiciel d'architecture.

J'espère avoir été assez clair.

[wiemwiem]

Bonjour,

j ai pose ma question dans deux forums mais tjs pas de reponse
est ce que vous pouvez m aider svp?
http://www.developpez.net/forums/d10...ation-donnees/

[elderion]

comme je vois ton logiciel :
- ton domaine :
l'architecture, (l'urbanisme...)

- ton but :
realiser un logiciel qui permet de créer/modeliser visuellement des formes architecturales.
A moins que tu fasse un logiciel pour modelider que des maison et rien d'autre,
la maison que tu modélise est abstraite, de type "forme architecturale".
ton objet fondamental c'est "juste" un container qui agrège différents objets issus de ta bibliotheque, avec chacun ses caracteristiques.
L''objet lui meme ne peut pas etre qualifié de "maison" puisque c'est (j'imagine ) un ensemble d'elements, de normes, etc.. qui font que ta forme peut est considérée comme une maison, un appartement, une cabane dans les bois.
Si tu veux créer un objet prétypé Maison, il faut que la classe "gabarit" contienne au moment de l'instanciation, les elements de base qui permettent de la qualifier comme telle.

- ton moyen :
1. une IHM pour produire ton modele.
2. un outil de représentation : la couche graphique vectorielle
pour décrire l'objet de type Forme dans un canvas 2D /3D , au moyen de ses données (traduites en SVG a cette occasion)

Ainsi a mon avis
- la couche vectorielle n'est le but de ton appli, ni le point de depart pour décrire ton Domain.
- les bibliotheques d'elements (widgets) cheminées, carrelages, menuiseries, ... sont des éléments d'un catalogue, un référentiel.
Ils sont représentés dans l'IHM par des icones, mais a mon avis ils ont leur place dans le Domain.
- ex d'interaction : quand "toi" (utilisateur) tu veux "placer" un objet "cheminée" dans le "salon" de la "maison"
ca doit se faire dans le controller : le ctrl recupere l'objet Maison, accede au sous objet "salon", et ajoute dans ses propres sous-objets une cheminée avec ses caracteristiques (position x,y, ...).

- tes fonctions métier :
* L'objet Cheminée peut avoir des fonctions métier, comme verifier des contraintes de sécurité incendie
* l'objet Salon peut avoir une fonction métier comme verifier si ya assez d'espace pour accueillir la cheminée suivant ses dimensions

Pour illustrer la problematique de "comment considerer la couche de représentation vectorielle" :
imagine que ton patron te demande de faire un rapport sur la productivité de ton service :
1. tu vas ouvrir Excel + cliquer sur des boutons (IHM principale)
2. pour importer (controller) des collections de données (Model)
3. enfin tu vas les visualiser via un cube OLAP (Vue, représentation, 2e IHM).
On voit bien que le but du jeu de ton appli c'est pas de créer un moteur de de cubes OLAP, mais un outil de Reporting, a l'intérieur d'un logiciel tableur.

En esperant apporter de l'eau a ton moulin...