Discussion :

[SlashEne]

Bonsoir,

J'applique actuellement le pattern MVC toute les fois que mon logiciel demande une interface graphique, je trouve en effet bien pratique le fait de pouvoir synchronisé la vue et le modele dans les 2 sens (en opposition a ce que j'appelle a 1 sens lorsqu'il y a juste un pattern observer).

Une autre idée largement répendu dans le monde de la conception c'est la notion de découplage, j'ai souvent entendu dire qu'il fallait favorser un max le découplage entre les classe pour une meilleurs reutilisabilité et clareté...
Je suppose que je ne peux pas aller a l'encontre de ce principe, surtout lorsque je passe derrriere le code de "developpeur" qui fait du programme TOUT-EN-UNE-CLASSE (malheur a moi).

Cependant je trouve que lorsqu'on applique le pattern MVC il y a forcement un couplage fort je m'explique :

la vue est un observer de votre objet metier ce qui signifie que votre vue est forcement fortement couplé avec votre objet metier (en effet sinon comment pourrait t'elle affiché les champs de l'objet metier correctement ??).

Je me suis pas beaucoup renseigné sur le pattern MVC2 j'ai cru comprendre qu'il etait efficasse pour les application web, et que tout passait par le controleur (evenement de l'objet metier, et interaction exterieurs).
Je pense que c'est deja une amelioration du pattern MVC car la vue n'est plus couplé avec l'objet metier.

J'ai réfléchi a une solution alternative sur l'interaction UI <-> objet metier
qui reduirerais considerablement le couplage.

-Le contenu de la vue serait entierement decrit par un document XML valide a un shema xml (doctype ou xsd) particulier a ce composant graphique.

-L'objet metier serait serializable en XML.

L'interaction entre la vue et l'objet metier se ferait par un fichier XSL
qui transformerai l'objet metier en objet graphique, et par un autre fichier XSL qui ferait l'inverse. De tel sorte que chaque interaction avec l'UI déclenche la mise a jour de l'objet metier par :
génération contenu UI en XML -> transformation XSL -> initialisation des champs de l'objet metier au document XML généré.
Toutes interactions sur l'objet metier ferait l'inverse.


En espérant m'etre fait comprendre,
-j'aimerai avoir vos avis sur le probleme de couplage que j'ai avec le pattern MVC,
-vos avis sur le pattern MVC2 pour ceux qui l'utilise (que ca soit dans le cadre d'une appli web ou lourde),
-vos avis sur ma méthode, et
-vos avis sur d'eventuelles alternatives à l'interaction bi directionnel UI <-> metier.

merci d'avance

[Franck SORIANO]

la vue est un observer de votre objet metier ce qui signifie que votre vue est forcement fortement couplé avec votre objet metier (en effet sinon comment pourrait t'elle affiché les champs de l'objet metier correctement ??).

Ou est le problème ?

On cherche a découpler les composants pour faciliter leurs réutilisations dans un contexte différent. On veut pouvoir utiliser l'objet métier indépendemment de sa représentation dans une vue. On veut également pouvoir changer la vue pour afficher le même objet différemment, ou en utilisant une autre techno.

En revanche, quelle est la raison d'être d'une vue sans l'objet qu'elle affiche ? On ne va pas chercher à réutiliser la vue pour afficher un autre objet...

Personnellement, je n'irais pas me faire c... à définir des sérialisations XML et transformations XSL, juste pour que la vue soit également indépendante de l'objet métier. Ca représenterait un coût exorbitant (en dev mais aussi en charge CPU) pour un gain douteux.

Je trouve que le MVC est déjà une très bonne solution pour que le métier soit indépendant de l'IHM. Et encore une fois, je ne vois pas de problèmes à ce que l'IHM soit dépendante du métier. C'est ça raison d'être.

[pseudocode]

En espérant m'etre fait comprendre,
-j'aimerai avoir vos avis sur le probleme de couplage que j'ai avec le pattern MVC,
-vos avis sur le pattern MVC2 pour ceux qui l'utilise (que ca soit dans le cadre d'une appli web ou lourde),
-vos avis sur ma méthode, et
-vos avis sur d'eventuelles alternatives à l'interaction bi directionnel UI <-> metier.

Personnelement, je découple la "vue" et l' "objet métier" en inserant une couche supplémentaire: la "présentation".

Code :

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

1
2
3
4
Vue  <----> Présentation <----> Objet Métier
 ^                ^
 |_____ Ctrl _____|

La "vue" contient les widgets.
La "présentation" contient les valeurs des widgets.
L' "objet métier" contient les valeurs métiers.

- Les widgets sont "bindés" sur les valeurs de la présentation (le binding est géré automatiquement dans la plupart des toolkits)
- La présentation a pour reponsabilité de "traduire" les données métier (chaîne, valeur, ...) en données utilisables par les widgets (texte, couleur, ....) et inversement.

Le triplet (Vue,Présentation,Ctrl) forme un modèle MVC.
La paire (Présentation,Objet Métier) forme un modèle "médiateur + business delegate".

[SlashEne]

Désolé de répondre un peu tard
merci pseudocode j'ai enfin compris l'utilité du Binding (je savais l'utiliser mais je ne voyais pas trop l'interet puisque je "bindais" mon widget directement a mon objet métier grace au pattern observer et j'envoyais les donnée de l'utilisateur a mon objet métier grâce au controleur.

Franck, mon problème était que dans la plupart des livres et des exemples que je voyais sur MVC la vue observait un objet métier grace au pattern observer/observable ce qui imposait à la vue d'implémenter l'interface observer(ce que je souhaitais éviter).

[Franck SORIANO]

Perso je trouve que le gros problème avec toutes les documentations qu'on peut trouver sur le Net avec le MVC, c'est qu'à chaque fois, on mélange complètement modèle en couches (type 3-tiers) et MVC.
Le terme "couche MVC" me fait bondir car au final on ne comprend plus rien. Pire encore, les gens finissent par croire que le MVC c'est le nom qu'on donne au modèle en couches.

Personnellement, je distingue deux choses :
1. Le modèle en couches, qui dit que l'appli est structurée de la façon suivante :

IHM -> Métier -> Données. (voir on peut encore avoir plus de couches)

Ce qui donnera :
- Données : Couche contenant les DAO, framework de persistance ou n'importe quoi du même genre.
- Métier : La couche qui contient les objets métiers.
- IHM : Ben on a le choix MVC, Document/Vue...

2. le MVC qui n'est qu'une façon d'implémenter la couche IHM.
Cette dernière est alors structurée comme l'a indiqué pseudocode avec (Vue, Présentation, Contrôleur), sauf que ce qu'il appelle Présentation, c'est que je considère être le modèle du MVC.

C'est seulement jouer sur les mots, au final l'implémentation est la même. Mais ça permet de ne pas prêter au MVC des vertus qui appartiennent à un autre modèle.
Je n'ai jamais vu de MVC utilisé sans un modèle en couches, par contre on peut très bien faire des modèles en couches sans utiliser de MVC.

D'autre part, ce qui prête souvent à confusion c'est qu'en fait, le MVC se définit de la façon suivante :
- Les Vues affichent les données. Elles ne font rien d'autre et ne possèdent pas d'intelligence.
- Le contrôleur reçoit les événements issus des interactions de l'utilisateurs, les interprêtes et les traduits en traitements à exécuter (bon je résume un peu).
- Tout le reste : Ben c'est un gros merdier qu'on appelle modèle. Et on a tendance à dire que le modèle, c'est la couche métier et tout ce qui va en dessous.

Cette définition ne fait pas apparaître la distinction entre les données manipulées (Présentation dans l'exemple de pseudocode), qui représentent l'état de l'IHM et qui sont observées par les vues selon le DP de l'observer. Et les objets métier (qui généralement d'ailleurs sont plutôts des services métiers) qui implémentent réellement la logique métier de l'application.

A mon avis, c'est la raison pour laquelle les débutants du MVC n'y comprenne jamais rien. La seule façon de comprendre, c'est de voir un exemple bien fait sur une véritable application. Après on comprend comment ça marche et on répète aux nouveaux les mêmes explications théoriques auxquelles on n'avait soit-même rien compris...