ASP.NET MVC - TempData - Boas ou más práticas

Estou usando o AcceptVerbsmétodo detalhado na postagem do blog da Visualização 5 de Scott Gu para lidar com entradas de formulário na ASP.NET MVC:

• O usuário obtém um formulário vazio via GET
• O usuário posta o formulário preenchido via POST na mesma ação
• A ação valida os dados, executa a ação apropriada e redireciona para uma nova visualização

Então eu não preciso usar TempData. Dito isso, agora tenho que adicionar uma etapa de 'confirmação' a ​​esse processo, e parece exigir o uso de TempData.

Por alguma razão, tenho aversão a usar TempData- que é algo para ser projetado.

Essa é uma preocupação válida ou estou inventando?

Eu acho que os dados temporários são um mecanismo disparar e esquecer para notificar o usuário. É ótimo lembrá-los de algo que fizeram recentemente, mas também hesitaria em torná-lo uma etapa obrigatória em algum processo do usuário. A razão é que se eles atualizassem a página, eu acredito que ela teria sumido. Bem, acho que também estou hesitante em usá-lo, pois não está muito bem definido como é confiável.

Eu me pergunto se o problema é que você está fazendo a ação redirecionar para outra página antes da etapa de confirmação. Gostaria de saber se, em vez disso, após o primeiro envio, você poderia fazer o processamento suficiente para gerar a caixa de diálogo de confirmação e, em seguida, retornar a página original com a pergunta de confirmação. Semelhante a como você pode fazer a validação, exceto que a regra de validação verifica se a etapa de confirmação foi realizada (com a IU de confirmação oculta até que outra validação seja aprovada).

Não há necessidade de ter aversão a TempData ... Mas se não for usado corretamente, pode certamente ser uma indicação de design ruim. Se você estiver usando URLs RESTful, TempData é uma prática recomendada para transferir mensagens de suas Ações POST para suas Ações GET. Considere isto:

Você tem um formulário em URL Products / New. O formulário Publica em Produtos / Criar, que valida o formulário e cria o Produto. Em caso de sucesso, o Controlador redireciona para a URL Produtos / 1 e em caso de erro redireciona de volta para produtos / Novo para exibir Mensagens de Erro.

Produtos / 1 é apenas a ação GET padrão para o produto, mas gostaríamos que fosse exibida uma mensagem indicando que a inserção foi um sucesso. TempData é perfeito para isso. Adicione a mensagem a TempData no Post Controller e coloque um pouco de lógica na visualização e pronto.

Em caso de falha, venho adicionando os valores inseridos no formulárioCollection e uma coleção de Mensagens de erro para TempData no Post Action, e redirecionando para o inicial Action Prodcuts / New. Eu adicionei lógica à exibição para preencher as entradas do formulário com os valores inseridos anteriormente junto com quaisquer mensagens de erro. Parece bom e limpo para mim!

Acho que você deve hesitar antes de usar TempData. TempData é armazenado na sessão e isso pode ter implicações para você se:

1. Você não usa sessões em seu site agora
2. Você tem um sistema que precisa ser escalado para um alto rendimento, ou seja, você prefere evitar o estado de sessão por completo
3. Você não quer usar cookies (não sei até que ponto o MVC suporta sessões sem cookies no momento)

Se o seu site precisa ter alta disponibilidade, há considerações adicionais sobre a aplicação do estado da sessão, mas todos esses são problemas solucionáveis.

Eu tenho um método GetModel que primeiro verifica TempData ["model"] e retorna isso. Caso contrário, GetModel carrega os dados apropriados do banco de dados.

Isso economiza uma carga extra do banco de dados quando eu tenho uma ação que precisa retornar uma exibição diferente que requer os mesmos dados do modelo.

Verifique os controladores sem sessão em MVC3. Descobriu-se que o uso de sessão impede a execução paralela de solicitações de um único usuário e, portanto, leva à degradação do desempenho.

Visto que tempdata usa sessão por padrão, você não seria capaz de usar este recurso. Você pode passar a usar cookies para tempdata, mas é um pouco estranho (pelo menos para mim). Ainda mais limpo do que viewstate, então talvez não seja um grande obstáculo.

Por que você tem essa aversão? Essa coisa é simplesmente fazer o seu trabalho e torná-lo bem :)

Se você não gosta dele por causa de sua tipagem não forte, você sempre pode fazer um invólucro que fornecerá uma interface de tipagem forte.

É como usar ViewData, o que significa que provavelmente não é um risco de segurança. Mas eu prefiro usar ViewData do que TempData. Verifique aqui uma comparação: http://www.squaredroot.com/2007/12/20/mvc-viewdata-vs-tempdata/

Dependendo do design, você sempre pode armazenar o usuário / cesta ou o que for necessário no tempdata no banco de dados e apenas ter um campo "IsReady" que indica se está completo ou não, tornando-o extensível para mais tarde se você quiser mente, que as pessoas podem fechar seus navegadores.

Todas boas respostas, você deu uma olhada nisto para passar mensagens adiante.

TempData e Session não são a melhor ideia para arquiteturas RESTful, pois a maioria das sessões é armazenada na memória. Portanto, quando você deseja usar um farm de servidores, a sessão do usuário existe em um servidor, enquanto a próxima solicitação pode ser enviada para outro servidor.

Dito isso, dê uma olhada neste uso de TempData para passar mensagens aqui.

http://jameschambers.com/2014/06/day-14-bootstrap-alerts-and-mvc-framework-tempdata/

Mabye isso poderia ser adaptado para usar uma abordagem de string de consulta se usado apenas para redirecionar para alertas de outra página.