我们正在构建一个Web应用程序。我们需要在用户会话期间存储类似对象的购物车的状态。

一些注意事项：

• 这不完全是一个购物车，而更像是用户正在建立的行程...但是我们现在将使用"购物车"一词与之相关。
• 我们不在乎"废弃"的购物车
• 购物车完成后，我们会将其保存到服务器端的一些数据存储区中，以便以后进行检索。

我们将状态对象存储在哪里？如何？

• 服务器(会话，数据库等？)
• 客户端(Cookie键值，Cookie JSON对象，隐藏的表单域等？)
• 其他...

更新：建议我列出我们要针对的平台，但不确定它是否完全必要...但是可以说前端是使用ASP.NET MVC构建的。

解决方案

在数据库中，与我们用于会话的任何内容(数据库/内存缓存会话，签名的Cookie)或者经过身份验证的用户相关联。

将其存储在数据库中。

如果我们希望支持未启用Javascript的用户，则服务器端会话将允许我们使用URL重写。

在不知道平台的情况下，我无法直接给出答案。但是，由于我们不关心废弃的购物车，因此我和这里的同事会有所不同，建议我们将其存储在客户端上。如果不在乎它是否被废弃，为什么还要将其存储在数据库中？
再说一次，它的确取决于要存储的对象的大小-cookie终究有其局限性。
编辑：啊，asp.net MVC？为什么不使用个人档案系统？如果我们不想让他们登录，可以启用匿名配置文件

我们是否设想人们需要能够在一台机器(例如，他们的工作PC)上启动但要从另一台机器(例如，家用PC)继续/结束？如果是这样，答案是显而易见的。

如果我们不关心废弃的购物车，并准备好在客户端处理数据的人……我认为cookie会很好-特别是如果它只是JSON数据cookie。

如果购物车的超时时间相对较短(大约2个小时，具体取决于服务器配置)，则可以说是服务器端会话。它比访问数据库更快，更高效。

如果我们需要更长的持久性(例如，某些用户喜欢离开并第二天回来)，则将其存储在防篡改的cookie中(使用加密或者哈希)。

我倾向于将其存储为会话对象。这是因为我们不必担心废弃的购物车，因此可以节省不必要的开销(因为不必这样做)(更不用说我们还需要某种清理例程从数据库中删除废弃的购物车)。

但是，如果我们希望用户能够保留其购物车，那么使用数据库选项会更好。这样，登录的用户将在各个会话中保存购物车(因此，当他们返回站点并登录时，他们的购物车将被还原)。

我们也可以将两者结合使用。默认情况下，访问该网站的用户使用基于会话的购物车。当他们登录时，所有项目都从基于会话的购物车移动到基于数据库的购物车，并且任何后续的购物车活动都直接应用于数据库。

我会在客户端上使用一个(加密的)cookie，其中包含用户篮子的ID。除非它是一个非常繁忙的站点，否则废弃的篮子不会填满过多的数据库，如果我们非常在意，我们可以运行常规的管理任务来清除废弃的订单。同样，这样做也可以使用户在关闭浏览器并离开后仍能保持订单状态，此时将清除会话中的所有内容。

最后，这意味着我们不必担心编写代码来处理来自客户端cookie的数据的反序列化/序列化，而后又不必担心在将数据转换为订单时将其实际放入数据库中(太多了)我喜欢的失败点)。

我想说的是将状态存储在服务器上的某个位置，并将其与用户会话相关联。尽管表面上cookie可以平等地存储事物，但是如果考虑安全性和数据大小，则在服务器上保留尽可能多的数据将成为一件好事。

例如，在公共终端设置中，有人可以查看cookie的内容并查看列表吗？如果是这样，cookie就可以了。如果不是，则只需要一个将用户链接到数据的ID。这样做还可以确保用户经过身份验证才能访问该数据，而不是将所有内容存储在计算机上，而他们需要某种形式的凭据以及会话标识符。

当然，从大小的角度来看，我们不会太担心4K Cookie或者浏览器/宽带用户的需求，但如果目标之一是允许手机或者BlackBerry(不在3G上)连接并且具有敏捷的体验(并且不会为数据付费)，因此最小化传递给客户端的数据量将是关键。

服务器存储还为我们提供了一些其他灵活性中提到的灵活性，用户可以将其购物车保存在一台机器上并在另一台机器上继续使用它。我们可以将购物车绑定到某种形式的凭据(而不是临时会话)，并在用户清除其cookie后很长时间保留购物车；如果用户的浏览器崩溃了，那么我们在容错方式上会获得更多一点，该站点仍然具有安全可靠的数据。

如果容错性很重要，则需要某种持久存储，例如数据库。如果不是，则应用程序内存可能没问题，但是如果应用程序重新启动，我们将丢失数据。如果我们在农场环境中，则必须可以集中访问商店，因此我们将再次查看数据库。

我们选择是通过临时会话还是通过凭据进行密钥取决于用户是否可以保存其数据并稍后再获取它。临时会话最终将被清除为"已放弃"，也许还可以。绑定到用户配置文件将使用户保留其数据并明确放弃它。无论哪种方式，我都会利用某种后备存储(例如数据库)来实现容错和中央可访问性。 (或者也许我过度设计了解决方案？)

我已经考虑了建议，但是还没有一个客户项目可以尝试。最接近的实际上是购物清单，我们可以在这里找到...

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

单击"杂货清单"以打开窗口。它确实使用ASPX，但仅用于管理放置在页面上的JS引用。其余的通过使用Web服务的AJAX完成。

以前，我为商务站点构建了一个ASP.NET 2.0站点，该站点自动使用anon / auth cookie。每一个都为我们提供一个GUID值，我们可以使用它来标识一个用户，然后将其与数据库中的数据相关联。我希望使用auth cookie，以便用户可以移动到其他计算机上。工作，家庭等。我避免使用Profile字段来保留复杂的ShoppingBasket对象，该对象在所有ASP.NET 2.0书籍中都很流行。我不想处理"魔术"序列化问题，因为数据结构会随着时间而变化。我更喜欢通过与软件更改同步的更新/更改脚本来管理数据库架构更改。

借助在客户端上标识用户的anon / auth cookie，我们可以使用ASP.NET AJAX客户端使用作为ASP.NET一部分提供给JS代理调用身份验证Web服务。我们需要实现成员资格API，以至少对用户进行身份验证。提供程序实现的其余部分可以安全地引发NotImplementedException。然后，我们可以通过AJAX使用自己的自定义ASMX Web服务(请参阅ScriptReference属性)，并使用服务器端数据更新页面。我们可以完全取消ASPX页面，并且可以根据需要使用静态HTML / CSS / JS。

一个最大的警告是JS中的内存泄漏。长时间停留在同一页面上会增加内存泄漏的潜在问题。通过测试长时间的会话并使用Firebug等工具来查找内存泄漏，可以将这种风险降到最低。使用JS Lint工具，它也将确定主要问题。

根据我对Commerce Starter Kit和MVC Storefront(以及我建立的其他站点)的经验，无论我们现在怎么想，与用户与"产品"交互的信息对于商务人士都是至关重要的。有很多指标可以说明问题。

我将为我们保存所有迄今为止最成功的工作，就是创建一个状态为" NotCheckedOut"的Order对象，然后向其中添加项目，然后用户添加项目。这样，用户可以拥有多个购物车，并允许我们从"订单"表中挖掘焦油。只需更改状态即可轻松执行订单。

坚持"随身携带"功能还允许用户出于某种原因返回并完成购物车(如果不能)。电子商务带来了宽恕。

Cookie很烂，会话很烂，Profile添加到用户的概念上，并且命中数据库，因此我们最好使用数据库。

我们可能会认为我们不想这样做，但是我们需要信任我，并且知道我们确实需要提供统计信息，以便以后获取一些数据。我答应你。