Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Futur Membre du Club
    Profil pro
    Développeur informatique
    Inscrit en
    décembre 2012
    Messages
    7
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : décembre 2012
    Messages : 7
    Points : 6
    Points
    6

    Par défaut MVP - Logique de l'application

    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

  2. #2
    Membre éprouvé
    Avatar de Garvelienn
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    septembre 2016
    Messages
    230
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Oise (Picardie)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : septembre 2016
    Messages : 230
    Points : 918
    Points
    918

    Par défaut

    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.
    «Le management, tel qu’on l’apprend dans les écoles et tel qu’on l’applique ensuite, sous prétexte de «motivation du personnel», organise exactement le contraire, à savoir la démotivation organisée.» - Bernard Stiegler

  3. #3
    Futur Membre du Club
    Profil pro
    Développeur informatique
    Inscrit en
    décembre 2012
    Messages
    7
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : décembre 2012
    Messages : 7
    Points : 6
    Points
    6

    Par défaut

    Bonjour,

    Merci de proposer ton point de vue.

    Citation Envoyé par Garvelienn Voir le message
    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.

  4. #4
    Membre émérite
    Inscrit en
    janvier 2011
    Messages
    805
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : janvier 2011
    Messages : 805
    Points : 2 925
    Points
    2 925

    Par défaut

    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...)

    Nom : 2.png
Affichages : 1193
Taille : 25,0 Ko

    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.

    Citation Envoyé par dev_compil
    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.

    Citation Envoyé par dev_compil
    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.

    Citation Envoyé par dev_compil
    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.

    Citation Envoyé par dev_compil
    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 ?

    Citation Envoyé par dev_compil
    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.

  5. #5
    Membre éprouvé
    Avatar de Garvelienn
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    septembre 2016
    Messages
    230
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Oise (Picardie)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : septembre 2016
    Messages : 230
    Points : 918
    Points
    918

    Par défaut

    Citation Envoyé par dev_compil Voir le message
    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.
    «Le management, tel qu’on l’apprend dans les écoles et tel qu’on l’applique ensuite, sous prétexte de «motivation du personnel», organise exactement le contraire, à savoir la démotivation organisée.» - Bernard Stiegler

  6. #6
    Futur Membre du Club
    Profil pro
    Développeur informatique
    Inscrit en
    décembre 2012
    Messages
    7
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : décembre 2012
    Messages : 7
    Points : 6
    Points
    6

    Par défaut

    Citation Envoyé par Garvelienn Voir le message
    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.

  7. #7
    Futur Membre du Club
    Profil pro
    Développeur informatique
    Inscrit en
    décembre 2012
    Messages
    7
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : décembre 2012
    Messages : 7
    Points : 6
    Points
    6

    Par défaut

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

    Citation Envoyé par Luckyluke34 Voir le message
    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

    Citation Envoyé par Luckyluke34
    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.

  8. #8
    Membre émérite
    Inscrit en
    janvier 2011
    Messages
    805
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : janvier 2011
    Messages : 805
    Points : 2 925
    Points
    2 925

    Par défaut

    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

    Citation Envoyé par dev_compil
    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.

  9. #9
    Membre éprouvé
    Avatar de Garvelienn
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    septembre 2016
    Messages
    230
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Oise (Picardie)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : septembre 2016
    Messages : 230
    Points : 918
    Points
    918

    Par défaut

    Citation Envoyé par Luckyluke34 Voir le message
    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 )

    Citation Envoyé par Luckyluke34 Voir le message
    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
    «Le management, tel qu’on l’apprend dans les écoles et tel qu’on l’applique ensuite, sous prétexte de «motivation du personnel», organise exactement le contraire, à savoir la démotivation organisée.» - Bernard Stiegler

  10. #10
    Futur Membre du Club
    Profil pro
    Développeur informatique
    Inscrit en
    décembre 2012
    Messages
    7
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : décembre 2012
    Messages : 7
    Points : 6
    Points
    6

    Par défaut

    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.

  11. #11
    Membre émérite
    Inscrit en
    janvier 2011
    Messages
    805
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : janvier 2011
    Messages : 805
    Points : 2 925
    Points
    2 925

    Par défaut

    Citation Envoyé par dev_compil Voir le message
    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.

    Citation Envoyé par dev_compil Voir le message
    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).

    Citation Envoyé par dev_compil Voir le message
    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 ?

    Citation Envoyé par Garvelienn
    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.

  12. #12
    Membre éprouvé
    Avatar de Garvelienn
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    septembre 2016
    Messages
    230
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Oise (Picardie)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : septembre 2016
    Messages : 230
    Points : 918
    Points
    918

    Par défaut

    Citation Envoyé par Luckyluke34 Voir le message
    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.

    Citation Envoyé par Luckyluke34 Voir le message
    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.
    «Le management, tel qu’on l’apprend dans les écoles et tel qu’on l’applique ensuite, sous prétexte de «motivation du personnel», organise exactement le contraire, à savoir la démotivation organisée.» - Bernard Stiegler

Discussions similaires

  1. Logique Application 5-tiers et DLL
    Par mactwist69 dans le forum VB.NET
    Réponses: 6
    Dernier message: 17/02/2015, 14h24
  2. Réponses: 1
    Dernier message: 13/12/2012, 22h56
  3. Réponses: 0
    Dernier message: 28/03/2011, 14h33
  4. architecture logique d'une application
    Par Minoucha2006 dans le forum Architecture
    Réponses: 0
    Dernier message: 03/03/2008, 11h07

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo