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

Question

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

Algunas notas:

• Esto no es exactamente un carrito de compras, sino más bien como un itinerario que el usuario está construyendo ... pero vamos a utilizar la palabra carrito de momento b/c se relacionan con PPL eso.
• No le importan los carros "abandonados"
• Una vez que se completa un carro lo llevaremos a algún almacén de datos del lado del servidor para su posterior recuperación.

Dónde Cómo se almacenan ese objeto con estado? Y cómo?

• servidor (sesión, db, etc?)
• cliente (galletas clave-vals, galleta objeto JSON, campos ocultos de formulario, etc?)
• otra ...

Actualización: Se sugirió que enumerara la plataforma a la que nos dirigimos, aunque no estoy seguro de que sea totalmente necesaria ... pero digamos que el front-end está construido con ASP.NET MVC.

Answer 1

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

Answer 2

Guárdelo en la base de datos.

Answer 3

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

Answer 4

Sin conocer la plataforma no puedo dar una respuesta directa. Sin embargo, como a usted no le importan los carros abandonados, difiero de mis colegas y sugiero que se guarden en el cliente. ¿Por qué almacenarlo en la base de datos si no le importa si está abandonado?
Por otra parte, depende del tamaño del objeto que está almacenando, las cookies tienen sus límites después de todo.

Editar: Ahh, asp.net MVC? ¿Por qué no usar el sistema de perfil? Puede habilitar un perfil anónimo si no desea molestarse en iniciar sesión en

Answer 5

¿Cree que las personas necesitan poder iniciarse en una máquina (por ejemplo, su PC de trabajo) pero continuar/finalizar desde una máquina diferente (por ejemplo, la PC de casa)? Si es así, la respuesta es obvia.

Answer 6

Si no te importan los carros abandonados y tienes 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.

Answer 7

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 algunos usuarios prefieren irse y volver al día siguiente), guárdelo en una cookie que sea invulnerable (use cifrado o hashes).

Answer 8

Me inclino 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ía usar una combinación de ambos. 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.

Answer 9

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 la base de datos por demasiado demasiado, y puede ejecutar una tarea de administración regular para borrar los pedidos abandonados si le importa tanto. También hacerlo de esta manera el usuario guardará su orden si cierra su navegador y se va, una canasta en la sesión se borrará en este punto ...

Por último, esto significa que no tiene que preocuparse por escribir código para tratar de/serializar los datos de una cookie del lado del cliente, y luego preocuparme por poner esos datos en la base de datos cuando se convierte en una orden (demasiados puntos de error para mi gusto) ..

Answer 10

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úblico, ¿estaría bien que alguien mire el contenido 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 le permitiría asegurarse 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 el identificador de la sesión.

Desde una perspectiva de tamaño, seguro que no te preocuparán demasiado las cookies 4K o algo así para un navegador/usuario de banda ancha, pero si uno de tus objetivos es permitir un teléfono móvil o BlackBerry (no 3G) para conectarse y tener una experiencia rápida (y no recibir una factura por 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 continuar trabajando con ella 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.

Si selecciona la tecla por sesión transitoria o por credenciales, dependerá de si los usuarios pueden guardar sus datos y volver más adelante 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?)

Answer 11

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

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

Haga clic en Grocery Lista de verificación 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 ASP.NET AJAX del lado del cliente 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 advertencia importante 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.

Answer 12

Ha sido mi experiencia con Commerce Starter Kit y MVC Storefront (y otros sitios que he creado) que no importa lo que piense ahora, la información sobre las interacciones de los usuarios con sus "productos" es primordial para los empresarios. Hay tantas métricas para capturar, es una locura.

Te ahorraré todo lo que he pasado, lo que de lejos ha sido lo más exitoso para mí es simplemente crear un objeto Order con estado "NotCheckedOut" y luego agregarle elementos y el usuario agrega elementos. Esto permite a los usuarios tener más de un carro y le permite extraer el alquitrán de la tabla Pedidos. También es bastante fácil realizar el pedido, simplemente cambie el estado.

Persistiendo "a medida que avanzan" también permite al usuario regresar y terminar el carrito si no pueden, por alguna razón. El perdón es masivo con el eCommerce.

Las cookies chupan, la sesión apesta, el perfil se adjunta a la noción de usuario y llega a la base de datos, por lo que también podría utilizar la base de datos.

Usted podría pensar usted no quiere hacer esto - pero hay que confianza mí y sabe que va a necesitar de hecho para alimentar a los expertos 'Estadísticas algunos datos más tarde. Te prometo.