Web Dev - Onde armazenar o estado de um objeto semelhante a um carrinho de compras?

Você está criando um aplicativo da web. Você precisa armazenar o estado para um objeto carrinho de compras como durante a sessão de um usuário.

Algumas notas:

  • Este não é exatamente um carrinho de compras, mas mais como um itinerário que o usuário está criando ... mas usaremos a palavra carrinho para agora b/c ppl relacionada a ele.
  • Você não se importa com carrinhos "abandonados"
  • Quando um carrinho for concluído, ele será mantido em algum armazenamento de dados do lado do servidor para recuperação posterior.

Where do you store that stateful object? And how?

  • servidor (sessão, db, etc?)
  • cliente (key-vals do cookie, objeto JSON do cookie, campo de formulário oculto, etc?)
  • outro ...

Update: It was suggested that I list the platform we're targeting - tho I'm not sure its totally necessary... but lets say the front-end is built w/ASP.NET MVC.

0
adicionado editado
Visualizações: 1

11 Respostas

Armazene no banco de dados.

0
adicionado

Eu considerei o que você está sugerindo, mas ainda não tive um projeto de cliente para experimentá-lo. O mais próximo, na verdade, é uma lista de compras que você pode encontrar aqui ...

http://www.scottcommonsense.com/toolbox.aspx

Clique em Lista de compras para abrir a janela. Ele usa ASPX, mas apenas para gerenciar as referências JS colocadas na página. O resto é feito via AJAX usando serviços da web.

Anteriormente, criei um site do ASP.NET 2.0 para um site de comércio que usava cookies anon/auth automaticamente. Cada um fornece um valor de GUID que você pode usar para identificar um usuário que é associado aos dados em seu banco de dados. Eu queria os cookies de autenticação para que um usuário pudesse mudar para computadores diferentes; trabalho, casa, etc. Evitei usar os campos Perfil para manter um objeto ShoppingBasket complexo que era popular durante o tempo em todos os livros do ASP.NET 2.0. Eu não queria lidar com questões de serialização "mágica", pois a estrutura de dados mudava com o tempo. Eu prefiro gerenciar alterações de esquema do banco de dados com scripts de atualização/alteração sincronizados com alterações de software.

Com os cookies anon/auth identificando o usuário no cliente, você pode usar o lado do cliente ASP.NET AJAX para chamar os serviços da Web de autenticação usando os proxies JS fornecidos para você como parte do ASP.NET. Você precisa implementar a API de associação para, pelo menos, autenticar o usuário. O restante da implementação do provedor pode lançar uma NotImplementedException com segurança. Você pode então usar seus próprios serviços da Web ASMX personalizados via AJAX (consulte o atributo ScriptReference) e atualizar as páginas com dados do lado do servidor. Você pode eliminar completamente as páginas ASPX e usar HTML/CSS/JS estático, se desejar.

A única grande advertência é vazamentos de memória no JS. Permanecer na mesma página há muito tempo aumenta o seu potencial problema com vazamentos de memória. É um risco que você pode minimizar testando sessões longas e usando ferramentas como Firebug e outras para procurar vazamentos de memória. Use a ferramenta JS Lint e ela ajudará a identificar os principais problemas.

0
adicionado
Eu gosto dessa abordagem, exceto que provavelmente usarei chamadas MVC e RESTful AJAX (retornando JSON ou marcação), portanto não precisarei me preocupar com o ASMX nem com o ASPX cruft.
adicionado o autor stevenharman, fonte

Se você não se importa com carrinhos abandonados e tem coisas em funcionamento para alguém mexendo com os dados no lado do cliente ... Eu acho que um cookie seria bom - especialmente se for apenas um cookie de dados JSON.

0
adicionado
Sim, eu concordo que realmente depende dos requisitos do aplicativo para saber se esta seria ou não a melhor rota.
adicionado o autor Ryan Lanciaux, fonte
Os cookies estão limitados a 4K. Isso pode não ser dados suficientes, dependendo do tamanho do carrinho de compras.
adicionado o autor 64BitBob, fonte

Eu diria armazenar o estado em algum lugar no servidor e correlacioná-lo à sessão do usuário. Embora um cookie possa ostensivamente ser um local igual para armazenar as coisas, se você considerar a segurança e o tamanho dos dados, manter o máximo possível de dados no servidor torna-se uma coisa boa.

Por exemplo, em um terminal público, seria bom alguém olhar o conteúdo do cookie e ver a lista? Se assim for, o cookie é bom; se não, você só vai querer um ID que vincule o usuário aos dados. Fazer isso também permitiria garantir que o usuário fosse autenticado no site para obter esses dados, em vez de armazenar tudo na máquina. Eles precisariam de alguma forma de credenciais, bem como da sessão. identificador.

Do ponto de vista do tamanho, você não ficará muito preocupado com um cookie 4K ou algo para um usuário de navegador/banda larga, mas se um dos seus alvos for permitir que um celular ou BlackBerry (não em 3G) se conecte e ter uma experiência rápida (e não ser cobrado pelos dados), minimizar a quantidade de dados passados ​​para o cliente será a chave.

O armazenamento do servidor também oferece alguma flexibilidade mencionada em algumas das outras respostas - o usuário pode salvar seu carrinho em uma máquina e retomar o trabalho com ela em outra; você pode vincular o carrinho a alguma forma de credencial (em vez de uma sessão transitória) e manter o carrinho por muito tempo após o usuário ter limpado seus cookies; você obtém um pouco mais de tolerância a falhas - se o navegador do usuário falhar, o site ainda terá os dados seguros e protegidos.

Se a tolerância a falhas for importante, você precisará de algum tipo de armazenamento persistente, como um banco de dados. Se não, na memória do aplicativo é provavelmente bem, mas você perderá dados se o aplicativo for reiniciado. Se você estiver em um ambiente de farm, a loja precisa ser acessível centralmente, então você está novamente procurando em um banco de dados.

Se você optar por chave por sessão transitória ou por credenciais vai depender se os usuários podem salvar seus dados e voltar mais tarde para obtê-lo. A sessão transitória eventualmente será limpa como "abandonada" e talvez esteja tudo bem. Vincular-se a um perfil de usuário permitirá que o usuário mantenha seus dados e os abandone explicitamente. De qualquer forma, eu faria uso de algum tipo de loja de apoio como um banco de dados para tolerância a falhas e acessibilidade central. (Ou talvez eu estou overengineering a solução?)

0
adicionado

Eu estaria inclinado a armazená-lo como um objeto de sessão. Isso ocorre porque você não está preocupado com carrinhos abandonados e pode, portanto, remover a sobrecarga de armazená-lo no banco de dados, já que não é necessário (sem mencionar que também seria necessário algum tipo de rotina de limpeza para remover carrinhos abandonados do banco de dados). ).

No entanto, se você quiser que os usuários mantenham seus carrinhos, a opção de banco de dados é melhor. Dessa forma, um usuário que está logado terá seu carrinho salvo em todas as sessões (assim, quando eles voltarem para o site e fizerem o login, o carrinho será restaurado).

Você também pode usar uma combinação dos dois. Os usuários que chegam ao site usam o carrinho baseado em sessão por padrão. Quando eles efetuam login, todos os itens são movidos do carrinho baseado em sessão para um carrinho baseado em banco de dados, e qualquer atividade de carrinho subseqüente é aplicada diretamente ao banco de dados.

0
adicionado
Acho que esta é uma sugestão válida - exceto que provavelmente usaria o cookie do lado do cliente com dados JSON em vez da sessão ...
adicionado o autor stevenharman, fonte
E quanto aos limites de tamanho dos cookies? E quanto a adulteração de cookies? Pode ser bom para uma lista, mas para um carrinho parece realmente grosseiro? O que acontece se você alterar o esquema de dados?
adicionado o autor Andrew Rimmer, fonte

Se um tempo relativamente curto (cerca de 2 horas, dependendo da configuração do seu servidor) é bom para o carrinho, então eu diria que a sessão do lado do servidor. É mais rápido e mais eficiente do que acessar o banco de dados.

Se você precisar de uma persistência maior (digamos que alguns usuários gostem de sair e voltar no dia seguinte), armazene-a em um cookie que seja inviolável (use criptografia ou hashes).

0
adicionado

Without knowing the platform I can't give a direct answer. However, since you don't care about abandoned carts, then I would differ from my colleagues here and suggest storing it on the client. Why store it in the database if you don't care if it's abandoned?
Then again, it does depend on the size of the object you're storing -- cookies have their limits after all.

Edit: Ahh, asp.net MVC? Why not use the profile system? You can enable an anonymous profile if you don't want to bother making them log in

0
adicionado

No banco de dados vinculado ao que quer que você esteja usando para sessões (sessões db/memcache, cookies assinados) ou para um usuário autenticado.

0
adicionado
Pode até não haver um db (pelo menos não um relacional) ... :)
adicionado o autor stevenharman, fonte
Guarde-o no seu armazenamento de dados "do lado do servidor" :). Por que ter dois armazenamentos de dados diferentes? O armazenamento do lado do servidor adiciona mais flexibilidade e segurança.
adicionado o autor Andrew Rimmer, fonte

Se você se preocupa com o suporte a usuários sem o Javascript ativado, as sessões do lado do servidor permitirão que você use a regravação de URL.

0
adicionado

Você imagina pessoas que precisam ser capazes de iniciar em uma máquina (por exemplo, seu PC de trabalho), mas continuar/terminar de uma máquina diferente (por exemplo, PC doméstico)? Se assim for, a resposta é óbvia.

0
adicionado
Esse não é um cenário que planejamos dar suporte a usuários anônimos - embora possamos apoiá-lo para usuários autenticados.
adicionado o autor stevenharman, fonte

Eu usaria um cookie (criptografado) no cliente que contém o ID da cesta de usuários. A menos que seja um site muito movimentado, então as cestas abandonadas não preencherão o banco de dados muito , e você poderá executar uma tarefa administrativa regular para limpar os pedidos abandonados se você se importar muito. Também fazendo desta forma o usuário irá manter o seu pedido se eles fecharem o navegador e forem embora, uma cesta na sessão será limpa neste momento.

Finalmente, isso significa que você não precisa se preocupar em escrever código para lidar com a serialização dos dados de um cookie do lado do cliente, enquanto depois se preocupa em realmente colocar esses dados no banco de dados quando ele é convertido em um pedido (muitos pontos de falha para o meu gosto) ..

0
adicionado