您正在构建一个 Web 应用程序。您需要在用户会话期间存储类似购物车的对象的状态。
一些注意事项：
你在哪里存储有状态的对象？又如何？
更新：有人建议我列出我们的目标平台——虽然我不确定它是否完全必要……但可以说前端是使用 ASP.NET MVC 构建的。
根据我对 Commerce Starter Kit 和 MVC Storefront（以及我建立的其他网站）的经验，无论您现在怎么想，关于用户与您的“产品”交互的信息对于业务人员来说都是最重要的。有太多的指标需要捕捉——这太疯狂了。
我会为您保存我经历过的所有内容 - 到目前为止，对我来说最成功的只是创建一个具有“NotCheckedOut”状态的 Order 对象，然后向其中添加项目并且用户添加项目。这使用户可以拥有多个购物车，并允许您从 Orders 表中挖掘焦油。交易订单也很容易 - 只需更改状态即可。
坚持“随用随走”还允许用户在由于某种原因无法完成购物车的情况下返回并完成购物车。电子商务的宽恕是巨大的。
Cookies 很糟糕，会话很糟糕，Profile 与用户的概念相关联，它会影响 DB，因此您不妨使用 DB。
你可能认为你不想这样做——但你需要相信我，并且知道你以后确实需要向统计专家提供一些数据。我答应你。
我已经考虑过您的建议，但还没有客户项目可以尝试。最接近的实际上是您可以在此处找到的购物清单...
http://www.scottcommonsense.com/toolbox.aspx
单击杂货清单以打开窗口。它确实使用 ASPX，但仅用于管理放置在页面上的 JS 引用。其余的通过 AJAX 使用 Web 服务完成。
以前，我为一个自动使用匿名/身份验证 cookie 的商业站点构建了一个 ASP.NET 2.0 站点。每个都为您提供了一个 GUID 值，您可以使用该值来识别用户，然后将其与数据库中的数据相关联。我想要 auth cookie，以便用户可以移动到不同的计算机；工作、家庭等。我避免使用 Profile 字段来保存复杂的 ShoppingBasket 对象，该对象在所有 ASP.NET 2.0 书籍中都很流行。我不想处理“神奇”的序列化问题，因为数据结构会随着时间而改变。我更喜欢使用与软件更改同步的更新/更改脚本来管理数据库架构更改。
使用匿名/身份验证 cookie 识别客户端上的用户，您可以使用 ASP.NET AJAX 客户端使用作为 ASP.NET 的一部分为您提供的 JS 代理调用身份验证 Web 服务。您需要实现 Membership API 以至少对用户进行身份验证。提供者实现的其余部分可以安全地抛出 NotImplementedException。然后，您可以通过 AJAX 使用您自己的自定义 ASMX Web 服务（请参阅 ScriptReference 属性）并使用服务器端数据更新页面。如果您愿意，您可以完全取消 ASPX 页面，而只使用静态 HTML/CSS/JS。
一大警告是 JS 中的内存泄漏。长时间停留在同一页面上会增加内存泄漏的潜在问题。通过测试长时间会话并使用 Firebug 等工具来查找内存泄漏，您可以将风险降至最低。使用 JS Lint 工具，它可以帮助您随时发现主要问题。
我倾向于将其存储为会话对象。这是因为您不关心废弃的购物车，因此可以消除将其存储在数据库中的开销，因为这不是必需的（更不用说您还需要某种清理例程来从数据库中删除废弃的购物车）。
但是，如果您希望用户能够持久保存他们的购物车，那么数据库选项会更好。这样，登录的用户将在会话中保存他们的购物车（因此当他们返回站点并登录时，他们的购物车将被恢复）。
您也可以将两者结合使用。来到站点的用户默认使用基于会话的购物车。当他们登录时，所有项目都从基于会话的购物车移动到基于数据库的购物车，并且任何后续购物车活动都直接应用于数据库。
在与您用于会话的任何内容（db/memcache 会话、签名的 cookie）或经过身份验证的用户相关联的数据库中。
将其存储在数据库中。
在不了解平台的情况下，我无法直接给出答案。但是，既然您不关心废弃的推车，那么我会与这里的同事有所不同，并建议将其存储在客户端上。如果您不在乎它是否被遗弃，为什么要将它存储在数据库中？
再说一次，它确实取决于您存储的对象的大小——cookie 毕竟有其局限性。
编辑：啊，asp.net MVC？为什么不使用档案系统？如果您不想让他们登录，您可以启用匿名个人资料
您是否设想人们需要能够在一台机器（例如他们的工作 PC）上启动但从另一台机器（例如家用 PC）继续/完成？如果是这样，答案是显而易见的。
如果您不关心废弃的购物车并且为有人在客户端弄乱数据做好准备......我认为 cookie 会很好 - 特别是如果它只是 JSON 数据的 cookie。
我会在保存用户购物篮 ID 的客户端上使用（加密的）cookie。除非它是一个非常繁忙的站点，否则废弃的购物篮不会过多地填满数据库，如果您非常在意，可以运行常规管理任务来清除废弃的订单。同样这样做，如果用户关闭浏览器并离开，用户将保留他们的订单，此时会话中的购物篮将被清除..
最后，这意味着您不必担心编写代码来处理来自客户端 cookie 的数据的反序列化，同时担心在将数据转换为订单时将其实际放入数据库（太多我喜欢的失败点）..
我会说将状态存储在服务器上的某个位置并将其与用户的会话相关联。虽然 cookie 表面上可能是存储东西的平等地方，但如果您考虑安全性和数据大小，那么在服务器上保留尽可能多的数据是一件好事。
例如，在公共终端设置中，是否可以让某人查看 cookie 的内容并查看列表？如果是这样，cookie 很好；如果没有，您只需要一个将用户链接到数据的 ID。这样做还可以让您确保用户通过站点身份验证以获取该数据，而不是将所有内容存储在机器上 - 他们需要某种形式的凭据以及会话标识符。
从大小的角度来看，当然，您不会太担心 4K cookie 或浏览器/宽带用户的东西，但如果您的目标之一是允许手机或黑莓（不在 3G 上）连接并且拥有快速的体验（并且不会为数据付费），最大限度地减少传递给客户端的数据量将是关键。
服务器存储还为您提供了其他一些答案中提到的一些灵活性 - 用户可以将他们的购物车保存在一台机器上并在另一台机器上继续使用它；您可以将购物车绑定到某种形式的凭据（而不是临时会话），并在用户清除其 cookie 后很长时间保留购物车；您可以在容错方面获得更多信息 - 如果用户的浏览器崩溃，该站点仍然拥有安全可靠的数据。
如果容错很重要，您将需要某种持久性存储，例如数据库。如果没有，在应用程序内存中可能没问题，但如果应用程序重新启动，您将丢失数据。如果您在农场环境中，商店必须可以集中访问，因此您再次查看数据库。
您是选择通过临时会话还是通过凭据进行密钥，将取决于用户是否可以保存他们的数据并稍后再回来获取它。瞬态会话最终将被清理为“被遗弃”，也许没关系。绑定到用户配置文件将使用户保留他们的数据并明确放弃它。无论哪种方式，我都会使用某种后备存储，例如数据库，以实现容错和中央可访问性。（或者也许我过度设计了解决方案？）
如果您关心支持未启用 Javascript 的用户，那么服务器端会话将允许您使用 URL 重写。
如果相对较短的超时（大约 2 小时，取决于您的服务器配置）对于购物车来说是可以的，那么我会说服务器端会话。它比访问数据库更快、更高效。
如果您需要更长的持久性（例如，某些用户喜欢离开并在第二天回来），则将其存储在防篡改的 cookie 中（使用加密或哈希）。