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