In our E-Commerce app, we have a page that customer service uses to place orders. Customers call and place orders. Customers can also place orders thru the main website.

Either way, we save the items in a "Basket" object. Users can remove items from it, add to it. This Basket object is NOT saved in the database. It's kept in ViewState. Anyway, when user clicks submit, we transfer the Basket object into Order object and we save that Order Object.

Basket object is like a dumb down version of Order object. When Order is saved, we have all the data in the database. Order object and tables have lots of Foriegn Key and non-nullable fields.

My question is, should we even have this Basket object? Do ecommerce sites even need a Basket object that they convert to an actual object?

It is a general feature of ecommerce sites. Ecommerce basket should be the same to ecommerce shopping carts. London people like to call ecommerce basket. Americans call ecommerce shopping cart.

We certainly use shopping carts (baskets) at my job. As you point out, carts are malleable and transient, while orders are hard data. It only takes a couple of SQL statements and a foreign key to transform the former into part of the latter.

The shopping cart can let us know the statistics and the number of user that using our online shop. So, this stuff is pretty useful ...