Etat de session avec des modèles MVP et Contrôleur d'application

Question

J'ai créé un framework MVP (vue passive) pour le développement et j'ai décidé d'utiliser un modèle de contrôleur d'application pour gérer la navigation entre les vues. Ceci est destiné aux interfaces WinForms, ASP.NET et WPF. Bien que je ne sois pas convaincu à 100% que ces technologies sont vraiment permutables, c'est mon objectif pour le moment, mon framework MVP est assez léger. Ce que je n'arrive pas à intégrer est le concept de «Business Conversation» qui nécessite que les informations d'état soient (a) maintenues pendant la durée de vie de la vue ou, plus probablement, (b) maintenues sur plusieurs vues pour la durée de vie d'un cas d'utilisation (conversation d'affaires). Je veux que la gestion d'état fasse partie du cadre car je ne veux pas que les développeurs s'en préoccupent. Tout ce qu'ils doivent faire est de "démarrer" une conversation, "Enregistrer" des objets et le cadre fait le reste jusqu'à la "fin" d'une conversation.

Est-ce que quelqu'un a des idées (modèles) sur la façon de l'adapter à MVP? Je pensais que cela pouvait faire partie de la responsabilité du contrôleur d'application (déléguer à un objet gestionnaire de conversation) car il sait à propos de l'état actuel afin d'envoyer l'utilisateur à la vue suivante .... mais je pensais que cela pouvait être à la hauteur Présentateur pour commencer et terminer la conversation, alors il descend les présentateurs pour gérer les conversations et les objets enregistrés pour cette conversation. Malheureusement, cela signifie que les présentateurs ne peuvent pas être utilisés dans différentes conversations ... alors cette idée ne semble pas correcte.

Comme vous pouvez le voir, je ne pense pas qu'il y ait une réponse facile (et j'ai cherché pendant un moment). Alors quelqu'un d'autre a des pensées?

Answer 1

Les classes nécessaires à la prise en charge d'une conversation métier doivent résider dans un présentateur s'il s'agit uniquement de l'interface utilisateur. Sinon, il devrait être dans le modèle et le contrôleur de la vue au présentateur au modèle. Avec des informations sur les conversations d'affaires qui circulent dans l'autre sens. Je suspecte quelque chose qui peut résider juste dans le Présentateur.

Étant donné que toutes les vues ont accès au présentateur, vous avez la possibilité de structurer les objets prenant en charge la conversation afin qu'ils puissent être conservés sur plusieurs vues.

Rappelez-vous Les vues sont une fenêtre sur les données qui résident dans votre logiciel. Ils ont fait peu d'autres données d'affichage et de transmettre les interactions de l'utilisateur dans le présentateur qui fait la logique.