Web Dev: ¿dónde almacenar el estado de un objeto similar al carrito de compras?

Estás construyendo una aplicación web. Debe almacenar el estado de un carro de compras como objeto durante la sesión de un usuario.

Algunas notas:

  • Esto no es exactamente un carrito de compras, sino más bien un itinerario que el usuario está construyendo ... pero usaremos el carro de palabras por ahora b/c ppl relacionado con él.
  • No te importan los carritos "abandonados"
  • Una vez que se completa un carrito, lo conservaremos en algún almacén de datos del lado del servidor para su posterior recuperación.

Where do you store that stateful object? And how?

  • servidor (sesión, db, etc.)
  • cliente (cookies key-vals, cookie JSON object, hidden form-field, etc.)
  • otro ...

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
agregado editado
Puntos de vista: 1

11 Respuestas

Guárdelo en la base de datos.

0
agregado

He considerado lo que sugiere, pero aún no he tenido un proyecto de cliente para probarlo. Lo más parecido en realidad es una lista de compras que puedes encontrar aquí ...

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

Haga clic en Lista de verificación de comestibles para abrir la ventana. Utiliza ASPX, pero solo para administrar las referencias JS colocadas en la página. El resto se realiza a través de AJAX utilizando servicios web.

Anteriormente, construí un sitio ASP.NET 2.0 para un sitio de comercio que utilizaba cookies anon/auth automáticamente. Cada uno le proporciona un valor GUID que puede usar para identificar a un usuario que luego se asocia con datos en su base de datos. Quería las cookies de autenticación para que un usuario pudiera moverse a diferentes computadoras; trabajo, hogar, etc. Evité el uso de los campos Perfil para mantener un objeto complejo ShoppingBasket que era popular durante el tiempo en todos los libros ASP.NET 2.0. No quería lidiar con problemas de serialización "mágicos" ya que la estructura de datos cambió con el tiempo. Prefiero administrar los cambios al esquema de db con las secuencias de comandos de actualización/modificación sincronizadas con los cambios de software.

Con las cookies anon/auth que identifican al usuario en el cliente, puede usar el lado del cliente ASP.NET AJAX para llamar a los servicios web de autenticación utilizando los proxies JS que se le proporcionan como parte de ASP.NET. Debe implementar la API de membresía para, al menos, autenticar al usuario. El resto de la implementación del proveedor puede arrojar una NotImplementedException de manera segura. A continuación, puede usar sus propios servicios web ASMX personalizados a través de AJAX (consulte el atributo ScriptReference) y actualizar las páginas con datos del lado del servidor. Puede eliminar por completo las páginas ASPX y simplemente usar HTML/CSS/JS estático si lo desea.

La única gran advertencia es la pérdida de memoria en JS. Permanecer en la misma página durante mucho tiempo aumenta su problema potencial con pérdidas de memoria. Es un riesgo que puede minimizar probando sesiones largas y usando herramientas como Firebug y otros para buscar fugas de memoria. Utilice la herramienta JS Lint y le ayudará a identificar problemas importantes a medida que avanza.

0
agregado
Me gusta este enfoque, excepto que probablemente usaré llamadas MVC y RESTful AJAX (devolviendo JSON o marcado) para no tener que preocuparme por ASMX ni ASPX.
agregado el autor stevenharman, fuente

Si no te importan los carritos abandonados y tienes las cosas en su lugar para que alguien se meta con los datos del lado del cliente ... creo que una cookie sería buena, especialmente si se trata de una cookie de datos JSON.

0
agregado
Sí, estoy de acuerdo, realmente depende de los requisitos de la aplicación en cuanto a si esta sería o no la mejor ruta.
agregado el autor Ryan Lanciaux, fuente
Las cookies están limitadas a 4K. Puede que no sea suficiente información, dependiendo del tamaño del carrito de compras.
agregado el autor 64BitBob, fuente

Yo diría almacenar el estado en algún lugar del servidor y correlacionarlo con la sesión del usuario. Si bien una cookie podría ser aparentemente un lugar igual para almacenar cosas, si se considera la seguridad y el tamaño de los datos, mantener tantos datos en el servidor como sea posible se convierte en algo bueno.

Por ejemplo, en una configuración de terminal pública, ¿estaría bien que alguien mire los contenidos de la cookie y vea la lista? Si es así, la cookie está bien; de lo contrario, solo querrá una ID que vincule al usuario con los datos. Hacer eso también te permitiría asegurarte de que el usuario está autenticado en el sitio para poder acceder a esos datos en lugar de almacenar todo en la máquina; necesitarían alguna forma de credenciales así como también la sesión. identificador.

Desde una perspectiva de tamaño, seguro que no te preocuparán demasiado las cookies 4K o algo así como un navegador/usuario de banda ancha, pero si uno de tus objetivos es permitir que un teléfono móvil o BlackBerry (no con 3G) se conecte y tener una experiencia ágil (y que no se le facturen los datos), minimizar la cantidad de datos que se pasan al cliente será la clave.

El almacenamiento en el servidor también le da cierta flexibilidad mencionada en algunas de las otras respuestas: el usuario puede guardar su carrito en una máquina y reanudar el trabajo en otra; puede vincular el carrito a alguna forma de credenciales (en lugar de una sesión transitoria) y persistir en el carrito mucho después de que el usuario haya borrado sus cookies; obtienes un poco más de tolerancia a fallas: si el navegador del usuario falla, el sitio aún tiene los datos sanos y salvos.

Si la tolerancia a fallas es importante, necesitará algún tipo de tienda persistente como una base de datos. De lo contrario, en la memoria de la aplicación probablemente esté bien, pero perderá datos si la aplicación se reinicia. Si se encuentra en un entorno de granja de servidores, la tienda tiene que ser accesible de forma centralizada, por lo que vuelve a consultar una base de datos.

Ya sea que elija clave por sesión transitoria o por credenciales va a depender de si los usuarios pueden guardar sus datos y volver más tarde para obtenerlos. La sesión transitoria finalmente se limpiará como "abandonada" y tal vez eso esté bien. Al vincularse a un perfil de usuario, el usuario conservará sus datos y lo abandonará explícitamente. De cualquier manera, utilizaría algún tipo de almacén de respaldo, como una base de datos para tolerancia a fallas y accesibilidad central. (¿O tal vez estoy sobreinnovando la solución?)

0
agregado

Me inclinaría a almacenarlo como un objeto de sesión. Esto se debe a que no le preocupan los carros abandonados y, por lo tanto, puede eliminar la carga de almacenamiento en la base de datos ya que no es necesario (sin mencionar que también necesitaría algún tipo de rutina de limpieza para eliminar los carros abandonados de la base de datos )

Sin embargo, si desea que los usuarios puedan conservar sus carritos, la opción de base de datos es mejor. De esta forma, un usuario que haya iniciado sesión tendrá su carrito guardado en todas las sesiones (de modo que cuando vuelvan al sitio e inicien sesión, su carro se restaurará).

También podrías usar una combinación de los dos. Los usuarios que acceden al sitio usan el carro basado en la sesión de forma predeterminada. Cuando inician sesión, todos los artículos se mueven desde el carro basado en la sesión a un carrito basado en la base de datos, y cualquier actividad posterior del carro se aplica directamente a la base de datos.

0
agregado
Creo que esta es una sugerencia válida, excepto que probablemente usaría cookies del lado del cliente con datos JSON en lugar de la sesión ...
agregado el autor stevenharman, fuente
¿Qué pasa con los límites de tamaño de las cookies? ¿Qué hay de la manipulación de cookies? Podría estar bien para una lista, pero para un carro, ¿parece realmente crudo? ¿Qué sucede si cambias el esquema de datos?
agregado el autor Andrew Rimmer, fuente

Si un tiempo de espera relativamente corto (alrededor de 2 horas, dependiendo de la configuración de su servidor) es correcto para el carro, entonces diría la sesión del lado del servidor. Es más rápido y más eficiente que acceder a la base de datos.

Si necesita una persistencia más larga (digamos que a algunos usuarios les gusta irse y volver al día siguiente), guárdelo en una cookie que sea invulnerable (use cifrado o hashes).

0
agregado

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
agregado

En el DB se relaciona con lo que esté usando para las sesiones (sesiones de db/memcache, cookies firmadas) o para un usuario autenticado.

0
agregado
Puede que ni siquiera haya un DB (al menos no uno relacional) ... :)
agregado el autor stevenharman, fuente
Guárdelo en su almacén de datos "del lado del servidor" :). ¿Por qué tener 2 tiendas de datos diferentes? El almacenamiento del lado del servidor agrega más flexibilidad y seguridad.
agregado el autor Andrew Rimmer, fuente

Si te preocupa apoyar a los usuarios que no tienen Javascript habilitado, entonces las sesiones del lado del servidor te permitirán usar la reescritura de URL.

0
agregado

¿Prevé que las personas necesiten comenzar en una máquina (por ejemplo, su PC de trabajo) pero continúen/finsih desde una máquina diferente (por ejemplo, una PC doméstica)? Si es así, la respuesta es obvia.

0
agregado
No es un escenario que planeamos apoyar para usuarios anónimos, aunque podemos admitirlo para usuarios autenticados.
agregado el autor stevenharman, fuente

Yo usaría una cookie (encriptada) en el cliente que contiene el ID de la cesta de los usuarios. A menos que sea un sitio realmente ocupado, las cestas abandonadas no llenarán demasiado la base de datos demasiado , y puede ejecutar una tarea administrativa habitual para borrar las órdenes abandonadas si le importa tanto. También al hacerlo de esta manera el usuario mantendrá su orden si cierra su navegador y se va, una canasta en la sesión se borrará en este punto.

Finalmente, esto significa que no tiene que preocuparse por escribir código para tratar con la serialización de los datos de una cookie del lado del cliente, y luego preocuparse por poner esos datos en la base de datos cuando se convierte en un pedido (demasiados puntos de falla para mi gusto) ..

0
agregado