Discussion :

[dev_compil]

Bonjour,


Je m'intéresse au MVP pour ma future application. Dans ce design Pattern la vue et le modèle sont sensés être indépendants. Cette séparation me pose beaucoup de questions en terme d'architecture.
Je n'ai pas vu de tutos/documents décrivant les traitements interactifs ni la gestion des erreurs dans ce pattern.

Je vois le modèle comme une "bibliothèque" de service (Accès aux données du SGBD, accès à des web-services, ...) le tout derrière la façade du modèle. La vue quant à elle offre des services GUI pour communiquer avec l'utilisateur. On peut alors voir la couche de présentation entre ces deux façades (ie interfaces), elle-même serait comme une double interface. Une interface du modèle pour la vue et une interface de la vue pour les données.

Si j'ai bien compris ce design, la présentation serait la couche qui implémenterait la logique de l'application (Business logic, logic domain). Là où le modèle offrirait un accès aux fonctions métier, la logique métier serait dans la présentation.

Restent à gérer :
- La communication utilisateur durant un traitement (demande de confirmation, proposer une valeur corrigée car celle fournie comme paramètre ne convient pas, ...) de la logique métier
- La remontée des erreurs entre les couches.

Enfin, certains ont expliqué qu'ils se permettaient quelques dépendances notamment en mettant directement des instructions de dialogue utilisateur dans la couche présentation.

Ma vision de ce design est-elle correcte ou dois-je reformater ?



Merci pour vos points de vue

[Garvelienn]

Salut,

Je vois toujours le MVP comme l'image de la "tour de contrôle d'aéroport":

• Modèle : l'équipe technique qui gère les avions au sol
• Vue : les avions en vol
• Présentation : la tour de contrôle

L'équipe technique n'a pas de possibilité de communiquer directement avec les avions et de toute façon, elle utilise un jargon que les pilotes ne pourrait pas comprendre. Et réciproquement, les avions ne peuvent pas communiquer avec l'équipe technique. Et même si ils pouvaient, ils ne se comprendraient pas.

Par contre, les deux équipes peuvent communiquer avec la tour de contrôle et être comprises par celle-ci.

La tour de contrôle prend donc les demandes et les informations des deux équipes. Elle les analysent et si besoin, les retransmets à l'autre équipe en s'adaptant à son jargon. Toutes les données ne sont pas forcément transmises car pas forcément pertinentes ou tombant mal.

Voila ma vision. On peut prendre une autre image : chef de projet (présentation), équipe développeur (modèle), équipe infographiste (vue).

Donc concrètement, la présentation reçoit et/ou demande des informations à la vue et au modèle, les interprètent et les adaptent dans le format que l'autre module comprend. Ce ne donc pas forcément là où se situe la logique de l'application. Dans le cadre d'une interface d'un logiciel (boutons, tableau, formulaire, etc), c'est souvent le cas. Mais dans une application réseau, c'est le serveur qui s'occupera de la logique. C'est donc le modèle. La présentation étant l’interfaçage réseau-vue (bien que le client peut être un MVP à lui tout seul aussi). Dans un jeu, c'est également le modèle (qui tourne généralement en parallèle de la vue).

Après, chacun conçoit ses applications comme il préfère. Je te donne juste ma façon de faire et de voir ce pattern.

[dev_compil]

Bonjour,

Merci de proposer ton point de vue.

Donc concrètement, la présentation reçoit et/ou demande des informations à la vue et au modèle, les interprètent et les adaptent dans le format que l'autre module comprend. Ce ne donc pas forcément là où se situe la logique de l'application. Dans le cadre d'une interface d'un logiciel (boutons, tableau, formulaire, etc), c'est souvent le cas.

Je ne vois que la présentation pour interpréter car, pour reprendre ton exemple de la tour de contrôle, les pilotes ne savent pas forcément dialoguer avec l'équipe technique. Chacun propose ses services à la tour de contrôle. C'est là que la logique métier de la présentation intervient pour résoudre les problèmes éventuels et interagir en temps réel (ie dialoguer) avec le service concerné. Si la la présentation n'a pas de règle de gestion de certains problèmes celui-ci ne fait que transiter pour être remonté à la vue qui sollicitera l'utilisateur.

Mais dans une application réseau, c'est le serveur qui s'occupera de la logique. C'est donc le modèle. La présentation étant l’interfaçage réseau-vue (bien que le client peut être un MVP à lui tout seul aussi).

Je ne pense pas que le Pattern MVP se prête bien/facilement à ce genre d'application. Ou bien on peut voir le serveur comme le modèle et la vue et la présentation embarquée du côté client.

Dans un jeu, c'est également le modèle (qui tourne généralement en parallèle de la vue).

bien vu pour le côté parallèle du modèle


Apparemment on voit les choses grosso-modo de la même manière.

[Luckyluke34]

Ca va être compliqué d'avoir une réponse claire et précise à ta question, car MVP comme MVC sont des patterns historiques qui ont énormément évolué et généré d'innombrables variantes au fil des générations de technos et de développeurs.

Il y a un papier intéressant sur les débuts de MVP et sa différenciation avec MVC : http://www.object-arts.com/downloads...ngTheTriad.PDF A savoir que contrairement au Controller de MVC, le Presenter est autorisé à manipuler directement sa vue. Il faut aussi voir que MVC était au départ un patron fait pour manipuler des sous-parties de fenêtres (widgets) dans des GUI de clients lourds (pas vraiment ce que c'est devenu avec le web) alors que MVP, plus tardif, est plutôt au niveau de la fenêtre entière.

Sur les moutures récentes, on peut distinguer deux types d'implémentation, Passive View et Supervising Controller (oui, ça s'appelle Controller alors qu'on est dans du Presenter, merci aux gens qui ont nommé ça...)

Je vois le modèle comme une "bibliothèque" de service (Accès aux données du SGBD, accès à des web-services, ...) le tout derrière la façade du modèle.

C'est à peu près ça, oui. Parfois, le Model est une notion encore plus floue qui contient aussi les données à présenter dans la vue comme dans l'exemple de Supervising Controller ci-dessus.

Si j'ai bien compris ce design, la présentation serait la couche qui implémenterait la logique de l'application (Business logic, logic domain).

Non, la couche présentation (qui contient d'ailleurs à la fois View et Presenter)... présente. Elle affiche des choses à l'utilisateur et relaie ses actions dans l'UI. Il faut se garder de mettre de la logique métier dedans pour des raisons de séparation des responsabilités, de duplication de code, etc.

demande de confirmation

Je dirais que c'est du View/Presenter pur, sauf si un traitement métier doit déterminer si on affiche la demande de confirmation ou pas, auquel cas il y a des échanges avec le Model.

proposer une valeur corrigée car celle fournie comme paramètre ne convient pas

Ca me parait être un cas assez rare, mais dans "proposer" j'entends "logique" et ce n'est pas de la logique UI car pour décider quoi proposer, il faut se baser sur d'autres règles que les règles qui organisent ce qui est affiché à l'écran. Donc un aller retour Modèle.

notamment en mettant directement des instructions de dialogue utilisateur dans la couche présentation

Qu'est-ce que tu appelles des instructions de dialogue utilisateur ?

Restent à gérer :
- La communication utilisateur durant un traitement (demande de confirmation, proposer une valeur corrigée car celle fournie comme paramètre ne convient pas, ...) de la logique métier
- La remontée des erreurs entre les couches.

Reste à gérer... à peu près tout en fait, car ce n'est pas en décrétant qu'on va utiliser du MVP ni même en ayant créé notre classe Vue et notre classe Présenteur que les choses vont magiquement se mettre en place. Certains frameworks peuvent faciliter la déclaration des Vues et Presenters et la liaison entre eux, mais toute la logique UI et les interactions avec le Modèle restent à coder.

[Garvelienn]

Je ne pense pas que le Pattern MVP se prête bien/facilement à ce genre d'application. Ou bien on peut voir le serveur comme le modèle et la vue et la présentation embarquée du côté client.

Ce n'était pas très claire mais c'est bien ce je pensais: le serveur en Modèle et le client en Présentation+Vue. Bien que le client peut également avoir un modèle à part. Ex: le moteur de particule/physique dans un jeu. Chaque client ne verra pas la même scène de la même manière mais sans que cela influe sur la logique du jeu. Mais je m'égare.

[dev_compil]

Ce n'était pas très claire mais c'est bien ce je pensais: le serveur en Modèle et le client en Présentation+Vue. Bien que le client peut également avoir un modèle à part. Ex: le moteur de particule/physique dans un jeu. Chaque client ne verra pas la même scène de la même manière mais sans que cela influe sur la logique du jeu. Mais je m'égare.

non, ça m'intéresse comme implémentation. Thanks.

[dev_compil]

Merci pour les liens (je lirai ce soir au calme).

Non, la couche présentation (qui contient d'ailleurs à la fois View et Presenter)... présente.

Tu confirmes qu'elle contient bien une référence vers ces deux objets

Qu'est-ce que tu appelles des instructions de dialogue utilisateur ?

Pourquoi ce fil de discussion. En fait mon problème d'architecture est simple. Dois-je voir le modèle comme de petites fonctions élémentaires (reste à la présentation d’apporter la glue logique de l'application) ou bien le modèle vient avec ses grosses fonctions "prêtes à l'emploi" (quitte à dialoguer avec la vue ?). Un exemple de chaque cas sera plus explicite.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
// Modèle : "small business"
// ci-dessous la présentation qui appliqua la logique métier

if not model.fonction_small_1() then {

    if view.confirm("Poursuivre ?") then {
       model.fonction_small_2()
   }

}

Code :

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

1
2
3
4
5
// Modèle : "full business" (MVP passif) et ses gros traitements
// La présentation ne fait que remonter à la vue la confirmation demandée par le modèle

// <Rien dans la vue> (à part les connecteurs d'évènements)

ou bien

Code :

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

1
2
3
4
5
6
7
8
9
10
11
// Modèle : "full business" (Supervising Contrôler)

// Le modèle interroge directement avec l'utilisateur via la vue
if not fonction_small_1() then {

    if view.confirm("Poursuivre ?") then {
       fonction_small_2()
   }

}

Pour résumer : faut-il voir le modèle en mode "small business" ou "full business" sachant qu'il peut y avoir des interactions avec l'utilisateur durant le traitement. Signaler les erreurs aux utilisateurs n'étant qu'un cas particulier d'interaction. Quand je disais présenter une valeur, cela signifiait présenter une valeur à confirmer par l'utilisateur qui ne provoquera plus d'erreur de traitement.

Certains frameworks peuvent faciliter la déclaration des Vues et Presenters et la liaison entre eux, mais toute la logique UI et les interactions avec le Modèle restent à coder.

Tel est la raison d'être de ce fil de discussion. Je n'ai vu aucun forum qui explique comment assurer des traitements interactifs surtout lorsque les applications doivent gérer des dizaines d'assertions. Donc mon problème est où dois-je les mettre ? Dans la présentation qui fera à du "small business model" ou les intégrer directement dans du "full business model" avec de gros traitement potentiellement bloqués ?

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
// Modèle : "small business"
// ci-dessous la présentation qui appliqua la logique métier

if not model.fonction_small_1() then {

    if view.confirm("Poursuivre ?") then {
       model.fonction_small_2()
   }

  switch ...    // Selon le tests des assertions
    case ...
   view.confirm(...)
}

Tel est mon dilemme.

[Luckyluke34]

Heu, j'avoue que tu m'as un peu perdu.

Tu sembles avoir implicitement des principes et un contexte métier bien spécifiques en tête qui m'échappent

Ce que je comprends :

- Tu ne fais pas du web mais du client lourd ?

- Ton application effectue des "traitements interactifs", c'est à dire une longue séquence de traitements entrecoupés par des questions posées à l'utilisateur ?

- Ces traitements gèrent des "assertions" - c'est quoi et comment ça marche ?

- Tu crains que les traitements soient bloqués mais je ne comprends pas trop pourquoi

Je n'ai vu aucun forum qui explique comment assurer des traitements interactifs surtout lorsque les applications doivent gérer des dizaines d'assertions

Actuellement, je dirais que 80% de l'utilisation de MVP est dans des applications web avec des cycles requête/réponse très courts. Du coup, ça me parait normal que tu n'aie rien vu sur ton cas si tu es dans du client lourd avec un cas d'utilisation qui dure très longtemps.

[Garvelienn]

Heu, j'avoue que tu m'as un peu perdu.

Tu sembles avoir implicitement des principes et un contexte métier bien spécifiques en tête qui m'échappent

Ce que je comprends :

- Tu ne fais pas du web mais du client lourd ?

- Ton application effectue des "traitements interactifs", c'est à dire une longue séquence de traitements entrecoupés par des questions posées à l'utilisateur ?

- Ces traitements gèrent des "assertions" - c'est quoi et comment ça marche ?

- Tu crains que les traitements soient bloqués mais je ne comprends pas trop pourquoi

En effet, dev_compil, cela serait intéressant d'avoir un peu plus de détails sur le type de ton application. Car le MVP ne fonctionnera pas toujours pareil en fonction de l'application. Cela sera très certainement plus facile de convenir de notre vision du MVP si on a la même base de référence. (bien que je pense qu'on soit d'accord mais avec des mots différents )

Actuellement, je dirais que 80% de l'utilisation de MVP est dans des applications web avec des cycles requête/réponse très courts. Du coup, ça me parait normal que tu n'aie rien vu sur ton cas si tu es dans du client lourd avec un cas d'utilisation qui dure très longtemps.

Le MVP se remarque plus facilement dans des applications web avec des cycles requête/réponse courts car justement, l'architecture est beaucoup plus simple à comprendre. Dans des clients lourds MVP, il y a tellement de patterns que le pattern global ne voit plus. Donc je transformerais tes 80% en 80% des MVP facilement compréhensibles sont des applications web avec des cycles requête/réponse courts. Dis moi si je me trompe

[dev_compil]

Je dois faire une application lourde effectivement.
Il y a beaucoup de conditions quand à la validité des informations saisies (ie assertions à valider) dans les différents champs (d'où ma remarque sur la logique métier à mettre dans la présentation ). Les traitement eux-même doivent vérifier beaucoup de conditions.

Une fois que l'utilisateur valide ses informations je lance le traitement (du modèle).
Dans l'architecture MVP peut-on envisager un traitement qui demande un confirmation à l'utilisateur ? En MVP passif ce n'est apparemment pas possible.

Je vais présenter le problème autrement :
Question 1 : Est-ce au modèle de contrôler la validité de chaque valeur saisie (à la sortie de chaque champ par exemple) ou est-ce plutôt à la présentation de le faire ?
Question 2 : Si le traitement du modèle voulait demander une confirmation, est-ce envisageable dans l'architecture MVP ? (dans le cas de mon "full business") sinon faut-il passer par de petits traitements du modèle ("small business") appelés depuis la présentation.

Tu vois je me pose pas mal de questions pour savoir comment architecturer mon application selon les règles du MVP.

Actuellement, je dirais que 80% de l'utilisation de MVP est dans des applications web avec des cycles requête/réponse très courts. Du coup, ça me parait normal que tu n'aie rien vu sur ton cas si tu es dans du client lourd avec un cas d'utilisation qui dure très longtemps

Effectivement, les "petits" traitements demandés dans les applications web font qu'ils retournent une erreur (en général).


Encore merci pour tes réponses.

[Luckyluke34]

Dans l'architecture MVP peut-on envisager un traitement qui demande un confirmation à l'utilisateur ? En MVP passif ce n'est apparemment pas possible.

Pourquoi ? Le Presenter peut très bien ordonner à la View d'afficher la confirmation et récupérer la réponse en sortie. Passive View veut juste dire que c'est le Presenter qui contient toute la logique d'affichage et remplit la vue.

Question 1 : Est-ce au modèle de contrôler la validité de chaque valeur saisie (à la sortie de chaque champ par exemple) ou est-ce plutôt à la présentation de le faire ?

En général, on met ceinture et bretelles donc les deux. Parfois, certaines vérifications de saisies sont View-only (par exemple le champ "Confirmer Mot de passe") ou Model-only (vérification qui doit déclencher une règle métier complexe qu'il n'est pas possible de mettre côté client).

Question 2 : Si le traitement du modèle voulait demander une confirmation, est-ce envisageable dans l'architecture MVP ? (dans le cas de mon "full business") sinon faut-il passer par de petits traitements du modèle ("small business") appelés depuis la présentation.

Dans cet exemple, c'est clairement le traitement donc la partie Model qui a le lead. A partir de là, je vois mal comment la Présentation pourrait décider toute seule du moment où on va demander une confirmation à l'utilisateur. La seule solution que je vois, c'est que le dans la chaine d'exécution, le Model appelle le Presenter qui va demander à la View d'afficher le dialogue de confirmation. Ca peut se faire via un abonnement du Presenter aux événements du Model ou simplement en attendant que le Model rende la main et en regardant la valeur de retour du Model. Le Model pourrait être une sorte de machine à états que le Presenteur va interroger à chaque fois qu'elle a fini de se transformer.

En réalité, j'ai un peu de mal à répondre car tout ça reste très vague. Quel type d'interruptions peut avoir lieu dans le traitement qui demanderait qu'on interroge l'utilisateur avant de reprendre ? Dans un même traitement métier, y a-t-il un nombre fini d'interruptions bien déterminé et si oui, jusqu'à combien ? Plus simplement, que fait l'application ?

Le MVP se remarque plus facilement dans des applications web avec des cycles requête/réponse courts car justement, l'architecture est beaucoup plus simple à comprendre. Dans des clients lourds MVP, il y a tellement de patterns que le pattern global ne voit plus. Donc je transformerais tes 80% en 80% des MVP facilement compréhensibles sont des applications web avec des cycles requête/réponse courts. Dis moi si je me trompe

C'est un peu l'idée, oui. Ceci dit, il peut très bien y avoir des applications client lourd avec un cycle action => changement d'écran à quasi chaque interaction de l'utilisateur, comme pour le web. Mais ici ça n'a pas l'air d'être le cas.

[Garvelienn]

Pourquoi ? Le Presenter peut très bien ordonner à la View d'afficher la confirmation et récupérer la réponse en sortie. Passive View veut juste dire que c'est le Presenter qui contient toute la logique d'affichage et remplit la vue.

C'est exactement ça.

En général, on met ceinture et bretelles donc les deux. Parfois, certaines vérifications de saisies sont View-only (par exemple le champ "Confirmer Mot de passe") ou Model-only (vérification qui doit déclencher une règle métier complexe qu'il n'est pas possible de mettre côté client).

C'est quelque chose qu'il faut faire : toujours vérifier les entrées mêmes si tu sais qu'elles ont déjà été vérifiées dans un autre module. Surtout si le projet contient une équipe de plusieurs développeurs ! (oula oui ! Combien de fois, ça m'a sauvé !)

Pour le reste, mêmes remarques que Luckyluke34.