Maneira mais correta de redirecionar a página com padrão de assistência-visualização

Question

Qual é a melhor maneira de chamar um Response.Redirect No padrão do apresentador de modelo-visualização enquanto adere à separação de camadas corrigida?

Answer 1

Uma maneira de lidar com isso é para o apresentador levantar um evento (como Succeeded ou algo assim) que a visão se inscreveria. Quando o apresentador terminou seu processamento, ele aumentaria o evento, o que seria tratado pela vista. Nesse manipulador, a vista iria redirecionar para a próxima página.

Dessa forma, o apresentador não precisa saber nada sobre páginas ou URLs ou qualquer coisa. Ele apenas sabe quando concluiu sua tarefa e avisa a exibição ao levantar um evento. Você pode criar eventos diferentes se o apresentador tiver sucesso ou falhar, caso precise redirecionar para diferentes lugares.

Answer 2

Não sei se é a maneira mais correta, conceitualmente. Mas o que eu fiz nas minhas últimas aplicações MVPs é criar um invólucro ao redor HttpContext.Current que eu liguei para HttPredirector. Eu também criei um redirector dummy para fins de teste. Ambos acompanham o último URL redirecionado, para que eu possa verificar nos meus testes de unidade que o redirecionamento realmente aconteceu quando eu chamo um método no meu controlador/apresentador. Com um contador de COI, sou capaz de mudar a implementação de IRedirector com base no ambiente (produção/teste).

Answer 3

A maneira como fazemos isso funciona bem quando algum trabalho de terra é estabelecido. Tenho certeza de que existem várias maneiras de esfolar um gato. (Quem pega os gatos de qualquer maneira. Os gatos são fofos e fofinhos!)

Primeiro, isso funcionará apenas nos projetos da Web compilados do ASP.NET, não em sites.

Cada página deve herdar de uma classe base abstrata personalizada, que se parece mais com a seguinte:

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 também implementa uma interface específica da página. Cada interface específica da página também herda de uma interface base:

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

Então é uma questão de cada página que define sua própria versão do BaseUrl. Você pode querer contabilizar a criptografia de Querystrings/Path/etc.

Por fim, qualquer um dos seus apresentadores (que deve referenciar as interfaces específicos da página) pode pegar o estático BuildUrl () em uma página desejada para visualizar e depois chamar LoadView () com o caminho retornado.

Answer 4

Depende de quão genéricos são seus apresentadores. Se seus apresentadores forem totalmente agnósticos da interface do usuário (podem ser reutilizados entre WinForms e Webforms), você precisará abstrair a operação de redirecionamento. Nos WebForms, a operação de redirecionamento seria implementada na visualização por uma resposta.Redirect. Em Winforms, (eu negaria muita experiência com o WinForms), meu palpite é que ele seria implementado por algum formulário.show.

Uma opção simples e fora da minha cabeça seria incluir na interface da visualização um método showViewx (). Você pode ter um para cada formulário em que a exibição pode redirecionar logicamente. Como alternativa, a visualização pode implementar um método de interface como o show (ConnectedViews), onde o ConnectELViews é um enumeração que inclui um valor para cada uma das visualizações que podem ser "redirecionadas" para uma visualização específica. Este enumeração viveria no nível do apresentador.

As abordagens acima são específicas para os pares do apresentador de visualização. Em vez disso, você pode implementá-lo como uma coisa em todo o sistema. A lógica seria semelhante a acima, implementada na visualização e apresentador base. Haveria um showView __ () para cada formulário ou um método de show (visualizações) em que as visualizações são uma enumeração de todas as formas.

É um lançamento entre encapsulamento e seco.