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