Où stocker l'état dans une architecture MVP

Dans d'autres questions MVP sur SO, les gens parlent du Presenter qui conserve les informations d'état (pourrait être l'état de la session ou de l'interface utilisateur). Ce que je me demande est, puisque l'état est fondamentalement des «données transitoires», et le but du modèle est d'encapsuler l'accès aux données, ne peut pas être maintenu à l'intérieur du modèle? Existe-t-il des règles générales ou des avantages/inconvénients concernant le stockage de l'état dans le Présentateur par rapport au Modèle? Est-ce que le modèle MVP impose l'utilisation du présentateur?Où stocker l'état dans une architecture MVP

Source

2010-08-17 Ates Goral

Le but du modèle n'est pas d'encapsuler l'accès aux données, mais de fournir une représentation (modèle) de votre domaine, quel qu'il soit. Parfois, l'accès aux données est inclus dans le modèle (par exemple avec Active Record accès aux données de style), mais le plus souvent, il est distinct. Lorsque j'ai créé MVP dans des applications de bureau, par exemple, le présentateur récupérait directement le modèle à partir de la base de données ou en utilisant un repository - le modèle n'avait rien à voir avec l'accès aux données. Où stocker l'état lié à la vue est un peu une zone grise, et dépend du type d'application que vous utilisez - pour les applications de bureau, il est beaucoup plus facile que vous pouvez le garder dans le présentateur, pour le web les choses des applications deviennent un peu plus compliquées. Vous pouvez envisager un modèle distinct pour la vue, qui peut ou non recouvrir le modèle principal (comme dans le ViewModel du modèle MVVM, populaire dans le développement WPF .Net).

Source

2010-08-17 17:10:58

Oui, j'utilise un modèle séparé pour la vue. J'applique MVP strictement pour le client. Le back-end est juste un service sans état et n'a aucune relation avec l'interface utilisateur. –

Mais est-ce un modèle de la vue (par exemple expose les mêmes champs que vous avez sur la vue), ou juste une copie du modèle de domaine qui est utilisé sur la couche de présentation? Si c'est purement un modèle de la vue, je dirais que MVVM était plus MVP que MVP - alors que je n'ai pas entendu parler de cette utilisation en dehors de WPF, je suppose qu'il n'y a aucune raison de ne pas le faire. Dans ce cas, oui, semble un endroit juste pour garder des données de vue d'état. Si c'est une copie du modèle de domaine qui est utilisé pour la vue, alors je dirais que le présentateur devrait le gérer (en quelque sorte ..). (Je suppose ici que les données ne sont pas ce que vous stockez normalement dans le modèle). –

Je pense que ce que j'essaie de faire ressemble plus à MVVM parce que le "état" dont je parle est purement pour l'état actuel de la vue. Vous avez soulevé quelques bons points qui m'ont fait réaliser cela. Je vous remercie! –

Si l'état est directement lié à la vue, le présentateur est l'emplacement approprié. Si ce n'est pas le cas, le modèle est probablement l'endroit approprié, mais le présentateur peut être approprié dans certains cas. La clé ici est que la vue et le présentateur sont couplés conceptuellement - alors que le présentateur peut ne pas être au courant de la vue spécifique, il devra généralement exposer des données spécifiques pour la vue qu'il traite.

Source

2010-08-17 16:57:04 kyoryu

Où stocker l'état dans une architecture MVP

Répondre

Questions connexes