Hej!

Jag skulle behöva lite hjälp med mitt tänk här. Det är så att jag ska skapa en orderfunktion där man ska kunna beställa produkter. För varje produkt finns det en köpknapp en button sedan längst ner på sidan en dropdownlist där varje val av produkt ska hamna för att sedan på en annan sida hämta produkterna från dropdownlist och skicka iväg till databasen. Frågan är hur jag ska lösa detta är det vettigt att köra med sessions eller borde jag satsa mer på att skicka in det temporärt i en DB och sedan skicka över det till tabellen där beställda erbjudanden ska visas och ha en deletequery?

MVH

Nicklas

För att kunna knyta en beställning till en besökare måste du nog använda dig av sessioner. Jag skulle troligen göra så att jag har en tabell i databasen där alla beställda objekt hamnar, även om de inte är "verifierade" av användaren än. När användaren verifierar beställningen sätts en rad till i en annan tabell och knyts ihop med alla beställda objekt genom en relation.

Just när det gäller läget före en verifiering sparar man ett id av något slag i en session där varje objekt i databasen har samma identifierare (för att identifiera vilken kund som valt vad).

Om ett köp inte verifieras tar man bort alla dessa rader från databasen vid en session_onend i global.asax filen. I gammal ASP hände det att denna funktion ibland inte kördes, men jag tror att det har blivit bättre med det i och med ASP.NET.

Dock måste man också ha någon slags backup i fall att något oförutsett inträffar, spara till exempel datum och tid då objektet valdes och ta bort alla som inte verifierats efter en viss tid, till exempel en vecka.

Hoppas detta hjälper dig på traven.

Tack så mycket för ditt svar. Nu vet jag lite hur jag ska tänka. Ska spinna vidare på detta nu.

//Nicklas

Varför inte skapa ett varukorgsobjekt som sparas i sessionen istället? Att skriva massa info till db, som kanske inte kommer att användas låter lite onödigt. Varukorgsobjektet behöver inte vara så stort och då kräver det inte så mycket av servern. Och prestandamässigt borde det ju rent teoretiskt gå snabbare. Att förlita sig på session_onend skulle inte jag våga göra i detta läget.
Tänk om servern går ner? Säg att 10 kunder med 10 varor i korgen har öppna sessioner. Blir en del skit i db som aldrig kommer till användning. Ok en backuplösning som raderar detta kan man ju göra, men det låter som en massa extra jobb och fler saker som kan krångla.

Men att hela tiden föra data fram och tillbaka i ett sessionsobjekt är inte speciellt prestandavänligt. Dessutom kan man enligt mina tester lita på session_onend i ASP.NET, den har alltid körts i alla mina applikationer.
När det gäller data i databasen är det inte skräp, det skall ju ändå i slutskedet dit om man bestämmer sig för att köpa objekten, annars tas de bort vid session_onend. Och som sagt, ifall servern går ner kommer ju ändå backuplösningen att ta bort restena som hänger kvar.

Det är inte speciellt krävande av databasen att hantera data, det är ju det den är till för så det behöver man inte ha i åtanke tycker jag...