Forma más correcta de redirigir la página con Model-View-Presenter Patrón

Question

¿Cuál es la mejor manera de llamar a Response.Redirect en el patrón Model-View-Presenter mientras se adhiere a la separación de niveles correcta?

Answer 1

Una forma en que manejé esto es que el presentador genere un evento (como Succeeded o algo similar) al que la vista se suscribiría. Cuando el presentador finaliza su procesamiento, se levanta el evento, que será manejado por la Vista. En ese controlador, la vista se redirigiría a la página siguiente.

De esta forma, el presentador no necesita saber nada sobre páginas o URL ni nada. Simplemente sabe cuándo ha completado su tarea y le permite conocer la vista al plantear un evento. Puede plantear diferentes eventos si el presentador tuvo éxito o falló, en caso de que necesite redirigir a diferentes lugares.

Answer 2

La forma en que lo hacemos funciona bien una vez que se establece un poco de terreno. Sin embargo, estoy seguro de que hay varias maneras de despellejar a un gato. (Quien los gatos de todos modos. Los gatos son lindos y tierno!)

Primero, esto solo funcionará en los proyectos web compilados de ASP.Net, no en los sitios web.

Cada página debe heredar de una clase base abstracta costumbre que se ve algo como esto:

public abstract class PageBase : Page 
{ 
    private static string _baseUrl = "/"; 

    public static string BaseUrl 
    { 
    get { return _baseUrl; } 
    set { _baseUrl = value; } 
    } 

    protected static string BuildUrl(string basePath) 
    { 
    if(!string.IsNullOrEmpty(basePath) && basePath.StartsWith("~/")) 
    { 
     basePath = basePath.replace("~/", BaseUrl); 
    } 
    return basePath; 
    } 

    protected static string LoadView(string path) 
    { 
    Response.Redirect(path); 
    } 
} 

Cada página también implementa una interfaz específica de la página. Cada interfaz específica de la página también se hereda de una interfaz base:

public interface IPageBase() 
{ 
    void LoadView(string path); 
} 

entonces es una cuestión de cada página que define su propia versión de BaseUrl. Es posible que desee contabilizar querystrings/encriptación de ruta/etc.

Finalmente, cualquiera de sus presentadores (que debería estar haciendo referencia a las interfaces específicas de la página) puede tomar BuildUrl estática() en una página deseada para ver y luego llamar a LoadView() con la ruta devuelta.

Answer 3

Depende de cuán genéricos sean sus presentadores. Si sus presentadores son totalmente independientes de la interfaz de usuario (se pueden reutilizar entre WinForms y WebForms), tendrá que abstraer la operación de redirección. En WebForms, la operación de redirección se implementaría en la vista mediante un Response.Redirect. En WinForms, (niego mucha experiencia con WinForms), creo que sería implementado por SomeForm.Show.

Una opción simple y fuera de lo común sería incluir en la interfaz de la vista un método ShowViewX(). Puede tener uno para cada formulario al que la vista podría redirigirse lógicamente. Alternativamente, la vista puede implementar un método de interfaz como Show (ConnectedViews) donde ConnectedViews es una enumeración que incluye un valor para cada una de las vistas a las que se puede "redireccionar" desde una vista particular. Esta enumeración viviría en el nivel del presentador.

Los enfoques anteriores son específicos para los pares de visualizador y presentador. En su lugar, podría implementarlo como una cuestión de todo el sistema. La lógica sería similar a la anterior, implementada en la vista base y el presentador. Habría un ShowView __() para cada formulario, o un método Show (Vistas) donde Views es una enumeración de todos los formularios.

Es un lanzamiento entre encapsulación y DRY-ness.

Answer 4

No sé si es la forma más correcta, conceptualmente. Pero lo que hice en mis últimas aplicaciones MVP, es crear un contenedor alrededor de HttpContext.Current que llamé HttpRedirector. También creé un redirector ficticio para fines de prueba.Ambos hacen un seguimiento de la última URL redirigida, de modo que puedo verificar en mis pruebas de unidad que la redirección realmente sucedió cuando llamé a un método en mi controlador/presentador. Con un contenedor IOC, puedo cambiar la implementación de IRedirector según el entorno (producción/prueba).