cookies - motors - primer auto electrico

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

Estás construyendo una aplicación web. Necesita almacenar el estado de un carrito 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 término "carro" por el momento b / c ppl relacionado con él.
No te importan los carros "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.

¿Dónde guardas ese objeto con estado? ¿ Y cómo ?

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

Actualización : se sugirió que incluyera 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.

¿Visualizas personas que necesitan poder comenzar en una máquina (por ejemplo, su PC de trabajo) pero continuar / terminar desde una máquina diferente (por ejemplo, una PC doméstica)? Si es así, la respuesta es obvia.

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

Guárdelo en la base de datos.

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 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.

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

Las cookies son una mierda, 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.

Tal vez pienses que no quieres hacer esto, pero debes confiar en mí y saber que de verdad necesitarás alimentar los datos de algunos datos más tarde. Te prometo.

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.

Previamente, construí un sitio ASP.NET 2.0 para un sitio de comercio que usaba 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 completamente 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 mucho tiempo aumenta el 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.

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 (por lo tanto, cuando regrese al sitio e inicie 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.

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 solo de una cookie de datos JSON.

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.

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).

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 hacer que inicien sesión

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 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 credencial además del identificador de la sesión.

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 adelante para obtenerlos. La sesión transitoria eventualmente 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?)

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, y usted puede ejecutar una tarea administrativa habitual para borrar los pedidos abandonados 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) ..