MVP: ¿el presentador debe usar la sesión?

Question

Estoy usando el patrón Model-View-Presenter para una página web. ¿Debería el presentador conocer la sesión o solo la vista debería conocerla?

Supongo que a lo que me refiero es que conceptos como Session están muy relacionados con la arquitectura de la vista, ¿deberían limitarse a su uso? 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 de eso a menos que tenga planes de hacerlo)?

Answer 1

Estoy haciendo algo como esto en mi implementación MVP. Inyecto un ICookieManager, ISessionManager, ICacheManager, IConfigurationManager, IRedirector en mi presentador, que se implementan mediante clases que envuelven la funcionalidad para esto.

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

Saludos

Answer 2

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

Su presentador llenaría la vista con lo que el controlador haya obtenido de la sesión.

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 la que no debería acceder a ella (permaneciendo tonto)?

Answer 4

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

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

Answer 5

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

Esto significa que podría inyectar una clase simulada de este tipo para simular diferentes valores para la sesión.

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

Answer 6

También estoy investigando enfoques pasivos de MVP. He visto un par de cosas que se hacen en la web, las cuales dejan la persistencia de la sesión a la vista, ya sea mediante inyección, como se mencionó en la paloma, o gestión explícita.

Ejemplos de inyección de dependencia 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 y evitar que se sobrescriban entre sí. (No estoy seguro de que el primer ejemplo logre esto 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. La desventaja es que cada vez que el presentador pone datos en la vista, debe llamar a un método de actualización en la vista para forzar el nuevo enlace. Esto no es necesario en los ejemplos anteriores, pero no necesita administrar una tabla de sesiones. No estoy seguro de cómo este enfoque complica las pruebas con herramientas de burla.

Answer 7

El consejo es interactuar con todas las entidades consumibles. Hace que el presentador y el modelo sean más fáciles de probar con burlas y centrar las pruebas en el comportamiento.