What would be considered best practice for implementing a persistent shopping cart in an ASP.net Web Forms(*) based application? The only built-in way seems to be involving the Session state, which is not ideal because once you close the browser... it's gone. One way seems to be involving the localStorage via Javascript, but that creates awkward client/server mixups, as the data processing is meant to be done server side.

(* please pay attention to that part - MVC or Blazor based solutions will not work for this particular case)

CodePudding user response：

Well, I can't imagine any practical application that involves database operations having ANY kind of suggesting that some kind of session, or view state will have ANY kind of relevance to database operations?

Be it a person filling out an invoice, or making orders or anything?

Not at all different then if you were writing a desktop application.

If a user is building up a list of items or "things" for/in an order?

Then as they build up such an order, then a database "order" record and structure will be built up. No different than say even building an invoice system say for the desktop with ms-access.

The only "use" of say session in most cases allows you to pass information from one page to another. (In place of say using parameters in the URL).

So, person might have a shopping basket of items (in your database, right!!!!).

They browse/search for more things to add to that shopping cart.

So say while on some items page, they choose to buy/select. When they make that choice, then you might say shove the ProductID into session, and then jump back into the current basket of items page, check session for a new product, and then insert/add that new item to the basket (which was being saved in the database).

If they log off, then fine. When they log back on, then you can load the current basket of items for display, and then allow them to continue shopping.

the only thing you going to use session for (or viewstate) is to allow the person to jump around looking at items, and then upon selection, you get/grab that particular product ID into session, jump back to the basket page, and add this new item from session, and then display their list of selected items.

So, in your database you have their current active order/basket, and thus when the user logs on, you can jump to that most recent or only "active order" page, and pull that order from the database. And then display all the details etc.

No session or viewstate would be required nor used at that point in time.

Not really any different than building up a invoice in a accounting package, then closing the program, and then next day, you launch the accounting package, load up the invoice, and thus can continue working on that invoice until you are done.

So, they look at the order, and go, "hum", I want to browse some more. So, they go look at/buy/choose/select another product. When they do, then you can now jump back to the current orders/basket page, and check session for the value just passed, add to order/basket, and now display the items in the basket, and that one "product id" in session can be pulled out, and is no longer required.

so session is not some kind of "magic" database system but is really only a feature to allow you to persist some values for a very short time, and only a simple "id" or simple variable in code for a rather short time. So session is ideal for passing a few values for use in code behind variables from one page to another.

Thus things like an address, name, products selected? That goes in the database, and not session.

For the most part, such software really not much different then desktop software.

You save and build up the list of items attached to a given order, and that order going to exist in the database.

So no real development approach here suggests saving their name, billing address, their past orders, the current new basket/order they have? That all going to be saved in a database.

So, session() is only relevant in most cases to "pass" some values, or "hold" some values for code behind.

So, if they select some product from a grid, you would shove productID into session, jump to the basket, add the new item in code behind to that order, and then let the page pull the information from the database to display items in that order.

So "session" persisting of data? That really only for a few variables that your code might need for some data operations, but your data for that order is not persisted in session - it goes into the database.

Session has VERY little to do with using a database system to "manage" and "hold" and "have" the order saved in the database system.

Session is not some kind of database - only a "active" storage of some variables you might need during program operation.

CodePudding user response：

Easy, store it in database for logged in user.

use local storage or cookies for guess.