Web Dev - Wo soll der Zustand eines Einkaufswagen-ähnlichen Objekts gespeichert werden?

Sie erstellen eine Webanwendung. Sie müssen den Status für ein Einkaufswagen ähnliches Objekt während einer Benutzersitzung speichern.

Einige Notizen:

  • Dies ist nicht genau ein Einkaufswagen, sondern eher wie eine Route, die der Benutzer baut ... aber wir werden das Wort Warenkorb für jetzt verwenden b/c ppl beziehen sich darauf.
  • Sie interessieren sich nicht für "verlassene" Wagen
  • Sobald ein Warenkorb fertig ist, werden wir ihn für einen späteren Abruf an einem serverseitigen Datenspeicher aufbewahren.

Where do you store that stateful object? And how?

  • Server (Sitzung, Datenbank usw.?)
  • client (Cookie-Schlüsselwerte, Cookie-JSON-Objekt, verstecktes Formularfeld usw.?)
  • andere ...

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
hinzugefügt bearbeitet
Ansichten: 15

11 Antworten

Speichern Sie es in der Datenbank.

0
hinzugefügt

Ich habe überlegt, was Sie vorschlagen, aber noch kein Kundenprojekt, um es zu versuchen. Der nächste ist eigentlich eine Einkaufsliste, die Sie hier finden können ...

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

Klicken Sie auf Lebensmittel-Checkliste, um das Fenster zu öffnen. Es verwendet ASPX, aber nur, um die auf der Seite platzierten JS-Referenzen zu verwalten. Der Rest erfolgt über AJAX über Web-Services.

Zuvor erstellte ich eine ASP.NET 2.0-Site für eine Commerce-Site, die automatisch anon/auth-Cookies verwendete. Jeder stellt Ihnen einen GUID-Wert zur Verfügung, mit dem Sie einen Benutzer identifizieren können, der dann mit Daten in Ihrer Datenbank verknüpft wird. Ich wollte die Authentifizierungs-Cookies, damit ein Benutzer zu verschiedenen Computern wechseln kann; Ich habe es vermieden, die Profile-Felder zu verwenden, um ein komplexes ShoppingBasket-Objekt zu halten, das während der Zeit in allen ASP.NET 2.0-Büchern beliebt war. Ich wollte nicht mit "magischen" Serialisierungsproblemen umgehen, da sich die Datenstruktur im Laufe der Zeit verändert hat. Ich bevorzuge es, Änderungen des Datenbankschemas mit Aktualisierungs-/Änderungsskripten zu verwalten, die mit Softwareänderungen synchronisiert sind.

Mit den anon/auth-Cookies, die den Benutzer auf dem Client identifizieren, können Sie die ASP.NET AJAX-Clientseite verwenden, um die Authentifizierungswebdienste unter Verwendung der JS-Proxys aufzurufen, die für Sie als Teil von ASP.NET bereitgestellt werden. Sie müssen die Membership-API implementieren, um den Benutzer mindestens zu authentifizieren. Der Rest der Provider-Implementierung kann eine NotImplementedException sicher auslösen. Sie können dann Ihre eigenen benutzerdefinierten ASMX-Webdienste über AJAX verwenden (siehe Attribut ScriptReference) und die Seiten mit serverseitigen Daten aktualisieren. Sie können komplett auf ASPX-Seiten verzichten und einfach nur statisches HTML/CSS/JS verwenden.

Der eine große Vorbehalt ist Speicherlecks in JS. Ein längerer Aufenthalt auf derselben Seite erhöht Ihr potenzielles Problem mit Speicherlecks. Dieses Risiko können Sie minimieren, indem Sie lange Sitzungen testen und Tools wie Firebug und andere verwenden, um nach Speicherlecks zu suchen. Verwenden Sie das JS Lint-Tool sowie es wird helfen, größere Probleme zu identifizieren, wie Sie gehen.

0
hinzugefügt
Ich mag diesen Ansatz, außer dass ich wahrscheinlich MVC- und REST-konforme AJAX-Aufrufe verwende (die JSON oder Markup zurückgeben), so dass ich mir keine Sorgen über ASMX oder ASPX machen muss.
hinzugefügt der Autor stevenharman, Quelle

Wenn Sie sich nicht um verlassene Wagen kümmern und Dinge für jemanden haben, der sich mit den Daten auf der Client-Seite herumschlägt ... Ich denke, ein Cookie wäre gut - vor allem, wenn es nur ein Cookie von JSON-Daten ist.

0
hinzugefügt
Ja, ich stimme zu, es hängt wirklich von den Anforderungen der App ab, ob dies der beste Weg wäre oder nicht.
hinzugefügt der Autor Ryan Lanciaux, Quelle
Cookies sind auf 4K beschränkt. Je nach Größe des Einkaufswagens sind das möglicherweise nicht genügend Daten.
hinzugefügt der Autor 64BitBob, Quelle

Ich würde sagen, speichern Sie den Zustand irgendwo auf dem Server und korrelieren Sie es mit der Sitzung des Benutzers. Während ein Cookie scheinbar ein gleichwertiger Ort zum Speichern von Dingen sein könnte, wenn Sie die Sicherheit und die Datengröße in Betracht ziehen, wird es so eine gute Sache, so viele Daten wie möglich auf dem Server zu behalten.

Wäre es zum Beispiel in einer öffentlichen Terminal-Einstellung für jemanden OK, den Inhalt des Cookies zu betrachten und die Liste zu sehen? Wenn dem so ist, ist Cookie in Ordnung; Wenn nicht, möchten Sie nur eine ID, die den Benutzer mit den Daten verbindet. Dadurch können Sie auch sicherstellen, dass der Benutzer für die Website authentifiziert wird, um zu diesen Daten zu gelangen, anstatt alles auf dem Computer zu speichern - sie benötigen eine bestimmte Form von Anmeldeinformationen sowie die Sitzung Kennung.

Was die Größe betrifft, werden Sie sich nicht zu sehr Gedanken über einen 4K-Cookie oder etwas für einen Browser/Breitband-Benutzer machen, aber eines Ihrer Ziele ist es, ein Mobiltelefon oder BlackBerry (nicht über 3G) zu verbinden und haben eine bissige Erfahrung (und nicht für die Daten in Rechnung gestellt), Minimierung der Menge der Daten, die an den Client weitergegeben wird Schlüssel sein.

Der Serverspeicher gibt Ihnen auch eine gewisse Flexibilität, die in einigen der anderen Antworten erwähnt wird - der Benutzer kann seinen Einkaufswagen auf einer Maschine speichern und mit der Arbeit an einer anderen fortsetzen; Sie können den Warenkorb mit einer Form von Anmeldeinformationen verknüpfen (und nicht mit einer vorübergehenden Sitzung) und den Warenkorb lange anhalten, nachdem der Benutzer seine Cookies gelöscht hat. Sie erhalten ein wenig mehr in der Art der Fehlertoleranz - wenn der Browser des Benutzers abstürzt, hat die Website immer noch die Daten sicher und Ton.

Wenn Fehlertoleranz wichtig ist, benötigen Sie eine Art persistenten Speicher wie eine Datenbank. Wenn dies nicht der Fall ist, ist es wahrscheinlich in Ordnung, aber Sie verlieren Daten, wenn die App neu gestartet wird. Wenn Sie sich in einer Farmumgebung befinden, muss der Store zentral zugänglich sein, sodass Sie sich erneut eine Datenbank ansehen.

Ob Sie eine vorübergehende Sitzung oder Anmeldeinformationen auswählen, hängt davon ab, ob die Benutzer ihre Daten speichern und später zurückkehren können, um sie zu erhalten. Transiente Sitzungen werden schließlich als "aufgegeben" bereinigt und vielleicht ist das in Ordnung. Durch das Verknüpfen mit einem Benutzerprofil kann der Benutzer seine Daten behalten und explizit ablehnen. In jedem Fall würde ich eine Art Back-Store wie eine Datenbank für Fehlertoleranz und zentrale Zugänglichkeit verwenden. (Oder vielleicht überbeansprucht ich die Lösung?)

0
hinzugefügt

Ich würde geneigt sein, es als ein Sitzungsobjekt zu speichern. Dies liegt daran, dass Sie sich nicht mit abgebrochenen Wagen beschäftigen und daher den Aufwand für das Speichern in der Datenbank beseitigen können (ganz zu schweigen davon, dass Sie auch eine Aufräumroutine benötigen, um abgebrochene Wagen aus der Datenbank zu entfernen ).

Wenn Sie jedoch möchten, dass Benutzer ihre Einkaufswagen beibehalten können, ist die Datenbankoption besser. Auf diese Weise wird ein Benutzer, der angemeldet ist, seinen Warenkorb über mehrere Sitzungen hinweg speichern lassen (wenn er also zur Seite zurückkehrt und sich anmeldet, wird sein Warenkorb wiederhergestellt).

Sie können auch eine Kombination der beiden verwenden. Benutzer, die auf die Website kommen, verwenden standardmäßig den sitzungsbasierten Warenkorb. Wenn sie sich anmelden, werden alle Artikel aus dem sitzungsbasierten Warenkorb in einen datenbankbasierten Einkaufswagen verschoben und alle nachfolgenden Einkaufswagenaktivitäten werden direkt auf die Datenbank angewendet.

0
hinzugefügt
Ich denke, das ist ein guter Vorschlag - außer dass ich wahrscheinlich clientseitige Cookies mit JSON-Daten anstelle von Sitzungen verwende ...
hinzugefügt der Autor stevenharman, Quelle
Was ist mit den Größenbeschränkungen von Cookies? Was ist mit Cookie-Manipulation? Es könnte für eine Liste in Ordnung sein, aber für einen Wagen scheint es wirklich grob. Was passiert, wenn Sie das Datenschema ändern?
hinzugefügt der Autor Andrew Rimmer, Quelle

Wenn ein relativ kurzer Timeout (ungefähr 2 Stunden, abhängig von Ihrer Serverkonfiguration) für den Warenkorb in Ordnung ist, würde ich die serverseitige Sitzung sagen. Es ist schneller und effizienter als der Zugriff auf die Datenbank.

Wenn Sie eine längere Persistenz benötigen (sagen Sie, dass einige Benutzer gerne gehen und am nächsten Tag wiederkommen), dann speichern Sie sie in einem Cookie, das manipulationssicher ist (verwenden Sie Verschlüsselung oder Hashes).

0
hinzugefügt

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
hinzugefügt

In der DB gebunden an was auch immer Sie für Sitzungen (db/memcache Sitzungen, signierte Cookies) oder für einen authentifizierten Benutzer verwenden.

0
hinzugefügt
Es gibt vielleicht nicht einmal eine db (zumindest keine relationale) ... :)
hinzugefügt der Autor stevenharman, Quelle
Speichern Sie es in Ihrem "serverseitigen" Datenspeicher :). Warum haben Sie zwei verschiedene Datenspeicher? Das Speichern der Serverseite bietet mehr Flexibilität und Sicherheit.
hinzugefügt der Autor Andrew Rimmer, Quelle

Wenn Sie Benutzer ohne aktiviertes JavaScript unterstützen möchten, können Sie in den serverseitigen Sitzungen das Umschreiben von URLs verwenden.

0
hinzugefügt

Stellen Sie sich vor, dass die Leute in der Lage sein müssen, auf einer Maschine (z. B. ihrem Arbeits-PC) zu beginnen, aber von einer anderen Maschine (z. B. Heim-PC) fortfahren? Wenn ja, ist die Antwort offensichtlich.

0
hinzugefügt
Das ist kein Szenario, das wir für anonyme Benutzer unterstützen möchten - wir können es für authentifizierte Benutzer unterstützen.
hinzugefügt der Autor stevenharman, Quelle

Ich würde einen (verschlüsselten) Cookie auf dem Client verwenden, der die ID des Benutzerkorbes enthält. Es sei denn, es ist eine sehr geschäftige Seite, dann verlassen die leeren Körbe die Datenbank nicht zu sehr, und Sie können eine reguläre Admin-Aufgabe ausführen, um die abgebrochenen Aufträge zu löschen, wenn Ihnen das so wichtig ist. Auf diese Weise behält der Benutzer seine Bestellung bei, wenn er den Browser schließt und weggeht. Ein Warenkorb in der Sitzung wird an dieser Stelle gelöscht.

Letztendlich bedeutet dies, dass Sie sich keine Gedanken darüber machen müssen, Code zu schreiben, um die Daten von einem clientseitigen Cookie zu de-/serialisieren, während Sie sich später Sorgen machen, diese Daten in die Datenbank zu übertragen, wenn sie in einen Auftrag konvertiert werden (zu viele) Punkte des Scheiterns für meinen Geschmack) ..

0
hinzugefügt