MVP - Le présentateur doit-il utiliser Session?

Question

J'utilise le modèle Model-View-Presenter pour une page Web. Le présentateur doit-il connaître l'existence de Session ou seul le point de vue doit-il en être informé?

Je suppose que ce que je veux dire, c'est que les concepts tels que Session sont très liés à l'architecture de la vue; doivent-ils donc être limités à une utilisation par la vue? Sinon, que se passerait-il si je voulais réutiliser le présentateur sur une page similaire sur une architecture différente (ou n'ai-je pas besoin de m'en inquiéter à moins que je ne prévoie de le faire)?

Answer 1

Je fais quelque chose comme ceci dans mon implémentation MVP. J'injecte dans mon présentateur ICookieManager, ISessionManager, ICacheManager, IConfigurationManager, IRedirector.

Cela permet à un présentateur d’injecter des versions simulées de celui-ci et de ne pas avoir de dépendance directe sur le runtime asp.net dans votre présentateur, ce qui facilite les tests.

A bientôt

Answer 2

Il pourrait même s'agir d'un module partagé qui encapsule la session que vous utilisez. De cette manière, il serait disponible pour tous vos contrôleurs et vous pourriez changer simplement l’implémentation physique de la session.

Votre présentateur remplira la vue avec tout ce que le contrôleur ira chercher dans la session.

Answer 3

Merci pour vos réponses à tous, alors pour résumer ...

Sommes-nous en train de dire que le présentateur devrait pouvoir accéder aux données de la session (de préférence via une interface) et à la vue qui ne devrait pas y accéder (rester muet)?

Answer 4

Dépend de l'objet que vous essayez de réutiliser ou contient la majeure partie de la logique métier.

Je suppose que seul le présentateur devrait connaître la session car cet objet est ce qui se rapproche le plus d'un contrôleur dans MVP.

Answer 5

Oui, comme le dit la colombe, enveloppez tout ce qui accède à la session dans une autre classe.

Cela signifie que vous pouvez injecter une classe fictive de ce type pour simuler différentes valeurs pour Session.

Pour répondre plus précisément à votre question, j’ai tendance à choisir le modèle Supervising-Presenter ( http: / /martinfowler.com/eaaDev/SupervisingPresenter.html ), ce qui permet de garder les vues TRES TRES bêtes. Ainsi, seul le présentateur accèderait à la session (mais pas directement, comme je l'ai déjà dit) et indiquait à View ce qu'il fallait faire.

Answer 6

Je recherche également des approches de MVP passives. J'ai constaté plusieurs choses sur le Web, toutes deux laissant la persistance de session à la vue, soit par injection, comme mentionné dans la colombe, soit par une gestion explicite.

Vous trouverez des exemples d'injection de dépendance ici: http://www.codeproject.com /KB/aspnet/Advanced_MVP.aspx et ici: http : //geekswithblogs.net/opiesblog/archive/2006/06/30/83743.aspx . Le truc ici consiste à gérer toutes les instances de session dans une variable statique et à les empêcher de s’écraser. (Je ne suis pas sûr que le premier exemple réalise cela correctement.)

La deuxième approche est la suivante: http: / /codebetter.com/blogs/jeffrey.palermo/archive/2005/03/28/128592.aspx . Dans cet exemple, la vue sait comment stocker son état. L'inconvénient est que chaque fois que le présentateur place des données dans la vue, il doit appeler une méthode Update sur la vue pour forcer la ré-association. Ceci n'est pas nécessaire dans les exemples ci-dessus, mais vous n'avez pas besoin de gérer un tableau de sessions. Je ne sais pas comment cette approche complique les tests avec des outils moqueurs.

Answer 7

Le conseil est d’interfacer chaque entité consommable. Cela rend le présentateur et le modèle plus faciles à tester en se moquant et en centrant les tests sur le comportement.