web applications - spa - MVP: ¿Debería el presentador usar Session?

https tag manager

Question

Estoy usando el patrón Model-View-Presenter para una página web. ¿Debería el presentador estar al tanto de la Sesión o debería solo la vista estar al tanto?

Supongo que lo que quiero decir es que los conceptos como Session están muy relacionados con la arquitectura de la vista, así que ¿deberían estar limitados a la vista? De lo contrario, ¿qué pasaría si quisiera reutilizar el presentador en una página similar en una arquitectura diferente (o no tengo que preocuparme por eso a menos que tenga planes para hacerlo)?

Answer 1

Depende del objeto que intente reutilizar o contenga la mayor parte de la lógica comercial.

Supongo que solo el presentador debería saber de la sesión, ya que ese objeto es lo más parecido a un controlador en MVP.

Answer 2

Estoy haciendo algo como esto en mi implementación de MVP. Inyecto ICookieManager, ISessionManager, ICacheManager, IConfigurationManager, IRedirector en mi presentador, que son implementados por las clases que envuelven la funcionalidad para esto.

Esto permite un presentador en el que puede inyectar versiones burladas de estos y no tiene dependencias directas en el tiempo de ejecución de asp.net en su presentador, por lo que facilita las pruebas.

Aclamaciones

Answer 3

Gracias por sus respuestas a todos, así que para resumir ...

¿Estamos diciendo que, en realidad, el Presentador debería poder acceder a los datos de la sesión (preferiblemente a través de una interfaz) y es la vista que no debería tener acceso a ella (quedando mudo)?

Answer 4

Incluso podría ser un módulo compartido que actúa como un contenedor en cualquier sesión que esté utilizando. De esta forma, estaría disponible para todos sus controladores y podría cambiar la implementación física de la sesión simplemente.

Su presentador llenará la vista con cualquier cosa que el controlador haya extraído de la sesión.

Answer 5

Sí, como dice la paloma, envuelva lo que tenga acceso a la sesión en otra clase.

Esto significa que puede inyectar una clase falsa de este tipo para simular diferentes valores para la Sesión.

Para responder a su pregunta más específicamente, tiendo a ir para el patrón Supervising-Presenter ( http://martinfowler.com/eaaDev/SupervisingPresenter.html ), que mantiene las vistas como MUY tontas. Entonces, solo el presentador tendría acceso a la sesión (aunque no directamente como dije antes) y le dirá a la vista qué hacer.

Answer 6

Estoy investigando enfoques MVP pasivos, también. He visto un par de cosas hechas en la web, y ambas dejan la persistencia de la sesión a la vista, ya sea por inyección, como se mencionó en la paloma, o administración explícita.

Los ejemplos de Dependency Injection se pueden ver aquí: http://www.codeproject.com/KB/aspnet/Advanced_MVP.aspx y aquí: http://geekswithblogs.net/opiesblog/archive/2006/06/30/83743.aspx . El truco aquí es administrar todas las instancias de sesión en una variable estática e impedir que se sobrescriban entre sí. (No estoy seguro de que el primer ejemplo lo consiga correctamente).

El segundo enfoque está aquí: http://codebetter.com/blogs/jeffrey.palermo/archive/2005/03/28/128592.aspx . En este ejemplo, la vista sabe cómo almacenar su estado. El inconveniente es que cada vez que el presentador ingresa datos en la vista, debe llamar a un método de Actualización en la vista para forzar la reenlace. Esto no es necesario en los ejemplos anteriores, pero no es necesario administrar una tabla de sesiones. No estoy seguro de cómo este enfoque complica las pruebas con herramientas de burla.

Answer 7

La sugerencia es interactuar con cada entidad consumible. Hace que el presentador y el modelo sean más fáciles de probar con burlas y enfoca las pruebas en el comportamiento.