Como salvar estado entre as solicitações de uma entidade no ASP.NET sem salvar no banco de dados usando EntityFramework?

Eu estou trabalhando em um aplicativo web CRUD ASP.NET WebForms composto por um par de páginas em que o usuário preenche os dados. Meu cliente não quer armazenar as entidades no banco de dados entre as páginas até que o usuário clique em Concluir na última página (por vários motivos). Quais opções existem para propagar os dados preenchidos entre as páginas e qual é o menos ruim? De minhas leituras eu vi que ViewState e Server.Transfer podem ser usados. Quaisquer outras opções, de preferência usando menos seqüências de caracteres mágicas e mais tipos de vinculação de dados seguros a objetos de entidade?

 Steffe11 de dez de 2012 10:58
Todas as opções nomeadas nesta discussão se resumem às técnicas do lado do cliente ou do servidor. As técnicas do lado do cliente aumentam o uso da sua largura de banda. Das técnicas do servidor, é claro que você precisa incluir alguns recursos do servidor. Se eu fizer uma escolha em quais recursos do servidor colocar em funcionamento, prefiro persistir no banco de dados. A maioria dos DB gerencia recursos de servidor de maneira muito responsável e escalável. Também pode haver um motivo específico para não persistir em um banco de dados. Pode ser que eles queiram manter a fonte de dados "limpa" desses dados. Uma nova instância db pode ser um bom contra-argumento.
 Chad10 de dez de 2012 21:32
@StevenVandeWeyer - Tenho certeza que existem melhores opções
 Steffe10 de dez de 2012 16:12
A melhor opção seria persistir esses dados temporários em um banco de dados. Não há realmente nenhum valor em fazê-lo de outra forma, pelo contrário. Armazená-lo na memória pode reduzir a escalabilidade do aplicativo.

questionAnswers(3)


Há toneladas de exemplos na internet.
Tente isto:
Implementando o cache distribuído usando o Memcached

 Rui Jarimba10 de dez de 2012 16:16
Não vejo como o cache ajudaria nesse cenário.
 Chad10 de dez de 2012 16:18
Lendo o link Eu não entendo o que o MemCached funciona ou como ele trabalharia para armazenar um objeto de contexto de entidade.
 Liam10 de dez de 2012 16:21
O Memcache é uma alternativa perfeitamente aceitável para a sessão. Rápido armazenamento de dados na memória, como mencionado, você não pode armazenar o contexto da entidade, portanto, isso é irrelevante.
QuestionSolution

ViewState vai aumentar significativamente a quantidade de dados que você está enviando, como todosViewstate os dados são serializados em uma entrada oculta no formulário, assim, à medida que você adiciona objetos, sua solicitação-resposta HTTP vai crescer significativamente.

Não há mágica na verdade. Se seus dados não forem muito complexos, armazenarei os valores na string de consulta. Se seus objetos estão ficando complexos e grandes e você deseja manter a segurança do tipo eu usariaSession, mas lembre-se de limpar depois de si mesmo!

Uma outra opção é usar o paradigma MVC e armazenar os valores no formulário usando entradas ocultas. Isso significa que você não precisa se preocupar com a limpeza da sua sessão, se o usuário estiver com problemas na metade do caminho, mas também mantém sua querystring limpa.

acho que todas as suas opçõesquerystring, viewstate (não faça isso), sessão ouvariáveis ​​ocultas.

Ok, então você tem que serializar seus dados, então você não pode persistir no contexto. isso não é serializável, então as opções acima são suas:

cada um tem positivo e negativo,

Viewstate (ineficiente, mas fácil de usar)Querystring (eficiente, mas impraticável para grandes conjuntos de dados e editável)Sessão (adiciona carga do servidor e precisa de limpeza, mas permite persistir apenas os dados no servidor)as variáveis ​​ocultas (ocultas do usuário, mas mais eficientes que o viewstate, exigem muitas entradas ocultas para cada propriedade)

Faça sua escolha!

 Chad10 de dez de 2012 16:02
Não, o OP está pedindo para persistir o contexto da entidade sem uma chamada .savechanges ().
 Liam10 de dez de 2012 16:15
Bem-vindo a 2005, os formulários da Web são o futuro, o REST está morto ....
 Liam10 de dez de 2012 15:54
Também dizer "isto é uma intranet, então vamos ignorar todas as medidas de desempenho" é muito estúpido. Só porque o seu em uma ethernet Gb não significa que você não deve otimizar seu código, tanto quanto possível.
 Liam10 de dez de 2012 16:22
finalmente uma voz da razão!
 Liam10 de dez de 2012 16:01
Você não pode seralizar o ponto final do contexto da entidade! Então, se você quiser armazenar dados em um estado serilado, que você precisa para persistir em um formulário da web, o acima são apenas opções. edição para explicar cada positivo e negativo
 Chad10 de dez de 2012 16:08
Em seguida, explique por que você não pode fazer isso em sua resposta e como suas alternativas podem ser implementadas. BTW eu não vou inverter o meu voto para baixo, desde que você inclua a string de consulta como um lugar válido para armazenar dados de formulário.
 Liam10 de dez de 2012 15:47
O viewState serializa o estado do objeto em um formato binário, codificando os tipos, etc, na entrada oculta. Isso, então, precisa ser serializado e depois desealizado em cada lado da solicitação / resposta, adicionando assim sobrecarga baseada apenas em entradas ocultas. Eu nunca sugeri que a querystring não pudesse ser manipulada. Observe que você me marcou sem sugerir alternativas melhores ???
 Chad10 de dez de 2012 15:57
É irrelevante para essa questão porque você não pode serializar o contexto Entity para que ele não possa ser armazenado no estado de exibição. Nem pode ser armazenado na string de consulta ou em um campo de formulário oculto.
 Liam10 de dez de 2012 16:04
o que você quer fazer !!!!!!
 Liam10 de dez de 2012 16:33
Sim concordou, não vou adicionar à minha resposta como alguém já postou sobre o Memcache.
 Chad10 de dez de 2012 15:38
O estado de exibição pode ser bom para formulários, especialmente se o aplicativo for apenas para intranet. A string de consulta, por outro lado, tem o potencial de ser manipulada. Passar qualquer coisa na string de consulta que será usada como dados de entrada do formulário é perigoso. Os campos ocultos usarão a mesma quantidade de sobrecarga que o estado da sessão. Tudo isso realmente não resolve o problema de salvar o objeto Entity nas alterações da página sem salvá-lo no banco de dados.
 jrummell10 de dez de 2012 16:20
Onde o OP está perguntando especificamente sobre a persistência do Contexto de Entidade? Enquanto elemaio seja possível, é altamente perigoso.
 jrummell10 de dez de 2012 16:25
Todas as opções desta resposta são válidas, mas você também pode adicionarCache estar completo.

Session e quando o usuário clica em terminar, você envia esses objetos para um serviço / método no qual é possível convertê-los em entidades e enviá-los ao banco de dados.

 Chad10 de dez de 2012 16:18
O op está pedindo especificamente para ter as mudanças de dados no contexto da entidade sem uma chamada savechanges (). Você sugeriu usar a sessão para armazenar objetos. Você pode armazenar o Contexto na sessão, mas é melhor ter algum código para lidar com os problemas que surgirem dele.
 Rui Jarimba10 de dez de 2012 16:13
@Chad: Eu nunca disse para armazenar o contexto na sessão. Eu estava me referindo apenas aos objetos que contêm os dados - idealmente, um contrato de dados ou algo semelhante que seria então convertido para as entidades.
 Rui Jarimba10 de dez de 2012 16:15
@Chad: Eu mudei minha resposta para evitar qualquer mal-entendido, espero que esteja claro o suficiente agora
 Chad10 de dez de 2012 16:27
@RuiJarimba - A coisa é que você pode armazenar o Objeto de Contexto na sessão. E quando você faz isso, cria problemas que podem ser resolvidos, mas não trivialmente. Meu comentário foi simplesmente apontando isso para não dizer que sua resposta está errada.
 Rui Jarimba10 de dez de 2012 16:23
@Chad: deixe-me dizer isso novamente: nunca mencionei armazenar o contexto na sessão, você é quem está dizendo isso de novo e de novo. Talvez eu não tenha entendido bem a questão, mas meu entendimento é que ele quer que todos os dados sejam comprometidos com o banco de dados somente quando o usuário pressiona o botão "Concluir": "Meu cliente não quer armazenar as entidades no banco de dados entre as páginas até que o usuário clique em Concluir na última página (por vários motivos)"
 Chad10 de dez de 2012 15:42
Usar sessão para armazenar o Entity-Context pode ser perigoso.

yourAnswerToTheQuestion