购物车的实现原理

购物车相当于现实中超市的购物车，不同的是一个是实体车，一个是虚拟车而已。用户可以在购物网站的不同页面之间跳转，以选购自己喜爱的商品，点击购买时，该商品就自动保存到你的购物车中，重复选购后，最后将选中的所有商品放在购物车中统一到付款台结账，这也是尽量让客户体验到现实生活中购物的感觉。服务器通过追踪每个用户的行动，以保证在结账时每件商品都物有其主。

购物车的功能包括以下几项：

1. 把商品添加到购物车，即订购
2. 删除购物车中已定购的商品
3. 修改购物车中某一本图书的订购数量
4. 清空购物车
5. 显示购物车中商品清单及数量、价格

实现购物车的关键在于服务器识别每一个用户并维持与他们的联系。但是HTTP协议是一种“无状态(Stateless)”的协议，因而服务器不能记住是谁在购买商品，当把商品加入购物车时，服务器也不知道购物车里原先有些什么，使得用户在不同页面间跳转时购物车无法“随身携带”，这都给购物车的实现造成了一定的困难。

目前购物车的实现主要是通过cookie、session或结合数据库的方式。下面分析一下它们的机制及作用。

1. cookie

cookie是由服务器产生，存储在客户端的一段信息。它定义了一种Web服务器在客户端存储和返回信息的机制，cookie文件它包含域、路径、生存期、和由服务器设置的变量值等内容。

当用户以后访问同一个Web服务器时，浏览器会把cookie原样发送给服务器。通过让服务器读取原先保存到客户端的信息，网站能够为浏览者提供一系列的方便，例如在线交易过程中标识用户身份、安全要求不高的场合避免用户重复输入名字和密码、门户网站的主页定制、有针对性地投放广告等等。利用cookie的特性，大大扩展了WEB应用程序的功能，不仅可以建立服务器与客户机的联系，因为cookie可以由服务器定制，因此还可以将购物信息生成cookie值存放在客户端，从而实现购物车的功能。

用基于cookie的方式实现服务器与浏览器之间的会话或购物车，有以下特点：

1. cookie存储在客户端，且占用很少的资源，浏览器允许存放300个cookie，每个cookie的大小为4KB，足以满足购物车的要求，同时也减轻了服务器的负荷；
2. cookie为浏览器所内置，使用方便。即使用户不小心关闭了浏览器窗口，只要在cookie定义的有效期内，购物车中的信息也不会丢失；
3. cookie不是可执行文件，所以不会以任何方式执行，因此也不会带来病毒或攻击用户的系统；
4. 基于cookie的购物车要求用户浏览器必须支持并设置为启用cookie，否则购物车则失效；
5. 存在着关于cookie侵犯访问者隐私权的争论，因此有些用户会禁止本机的cookie功能。

2. session

session是实现购物车的另一种方法。session提供了可以保存和跟踪用户的状态信息的功能，使当前用户在session中定义的变量和对象能在页面之间共享，但是不能为应用中其他用户所访问，它与cookie最重大的区别是，session将用户在会话期间的私有信息存储在服务器端，提高了安全性。在服务器生成session后，客户端会生成一个sessionid识别号保存在客户端，以保持和服务器的同步。这个sessionid是只读的，如果客户端禁止cookie功能，session会通过在URL中附加参数，或隐含在表单中提交等其他方式在页面间传送。因此利用session实施对用户的管理则更为安全、有效。

同样，利用session也能实现购物车，这种方式的特点是：

1. session用新的机制保持与客户端的同步，不依赖于客户端设置；
2. 与cookie相比，session是存储在服务器端的信息，因此显得更为安全，因此可将身份标示，购物等信息存储在session中；
3. session会占用服务器资源，加大服务器端的负载，尤其当并发用户很多时，会生成大量的session，影响服务器的性能；
4. 因为session存储的信息更敏感，而且是以文件形式保存在服务器中，因此仍然存在着安全隐患。

3. 结合数据库的方式

这也是目前较普遍的模式，在这种方式中，数据库承担着存储购物信息的作用，session或cookie则用来跟踪用户。这种方式具有以下特点：

1. 数据库与cookie分别负责记录数据和维持会话，能发挥各自的优势，使安全性和服务器性能都得到了提高；

2. 每一个购物的行为，都要直接建立与数据库的连接，直至对表的操作完成后，连接才释放。当并发用户很多时，会影响数据库的性能，因此，这对数据库的性能提出了更高的要求；

3. 使cookie维持会话有赖客户端的支持。

各种方式的选择：

虽然cookie可用来实现购物车，但必须获得浏览器的支持，再加上它是存储在客户端的信息，极易被获取，所以这也限制了它存储更多，更重要的信息。所以一般cookie只用来维持与服务器的会话，例如国内最大的当当网络书店就是用cookie保持与客户的联系，但是这种方式最大的缺点是如果客户端不支持cookie就会使购物车失效。

session 能很好地与交易双方保持会话，可以忽视客户端的设置。在购物车技术中得到了广泛的应用。但session的文件属性使其仍然留有安全隐患。

结合数据库的方式虽然在一定程度上解决了上述的问题，但从上面的例子可以看出：在这种购物流程中涉及到对数据库表的频繁操作，尤其是用户每选购一次商品，都要与数据库进行连接，当用户很多的时候就加大了服务器与数据库的负荷

电子商务网站购物车处理

1. 不过不提倡使用session，这货占用服务器资源，还有过期时间，客户关掉浏览器时session即消失，下次再上来，又得重新选产品。
2. cookie这东西不错，放在客户端的，给个一年的过期时间，只要客户不清掉，每次来都能记得上次的购物车信息。大家可以看看京东，
   在购物车cookie中存了不少东西，有产品编码和购买的数量等信息，如京东：yCartOrderLogic={&TheSkus&:[{&Id&:437741$&Num&:2}]}，
   原来凡客的cookie中也以JSON的形式存了很多信息。
   所以，我以学习的心态，将产品编码，价格，名称，类型和数量等购物信息做成一个对象，然后对象序列化成JSON，存在客户端的COOKIE中，
   在读取cookie时，在刚开始的时候很好用，反序列化cookie值成购物车条目对象就可以了，但是当产品类型多起来之后，而且有套装那种多件产品时，
   甚至产品不是来自同一个数据表时，比如普通首饰和钻石，表的结构都不一样了，还得到不同的表格中去取，当然首先你得判断产品类型
   这时候一个购物条目对象已经有多条子对象，往往一个查询中嵌套着两重以上的循环加上多个switch case，当购物车中有十个复杂的条目时，读取速度
   将超过十秒，不管怎么优化，速度就摆在那里，不快不慢。。。而且你不能保证客户不下100个或更多的复杂购物车记录，最重要的是cookie是有存储大小限制的，这种做法有产品很复杂时是不利的，果断放弃！
3. 数据库这东西好啊，不会像cookie那种容易丢失，也没有客户端的限制，你想怎么存，存多少都行。
   购物车数据存数据库好处有很多，可以分析购买行为，可以为客户保存购买信息（不会因为浏览器关闭而丢失）等。
   还需要考虑的一个问题是用户是否登录，淘宝使用的就是cookie记录，你可以试试，未登录时可以加20个商品，登录后可以加50个，这就是因为cookie客户端的限制。我这里因为产品线的复杂性，所有购物车条目都保存在数据库中。

购物车数据库设计成两个关联表

1. Basket，购物车主表
   基本字段有：BasketId, AddTime, UserId, AddressId, Payment, Status等，不解释了，看英文意思就行
2. BasketDetail，购物车条目表
   基本字段有：BasketDetailId, BasketId, Type, Code, Qty, ParentId等，ParentId用作子行标识，其它不解释
   两个表之间使用BasketId做为关联
   当用户登录状态时，添加产品到购物时，查看Basket中是否有Status为True的购物车，没有则添加一条新的Basket记录，并将产品信息相关数据添加至BasketDetail表中
   当用户未登录时，使用cookie记录一个BasketId值，不往Basket表中插入数据，只往BasketDetail插入数据，其中的BasketId值使用cookie中的BasketId值，当用户登录后，查看Basket中是否有Status为True的购物车记录，有则合并（更新cookie和BasketDetail中的BasketId为查询出来的Basket表中的BasketId值），无则添加一条新的Basket记录，并将BasketId值置为Cookie中记录的basketid值

购物车C#对象也设计两个（主要用于获取数据）

1. BasketModel，大体如下：

public class BasketModel: Basket {
   public decimal TotalPrice{get;set;}
   public int TotalMP{get;set;}
   public List<BasketDetailModel> BasketDetailModels{get;set;}
}

2. BasketDetailModel，大体如下：（这里的ViewBasketDetail是一个视图，上面BasketDetail设计中没有产品价格，用视图关联到相关的表，获取价格，为什么不设计价格字段，不解释。。。）

public class BasketDetailModel {
   public ViewBasketDetail Detail{get;set;}
   public List<ViewBasketDetail> SubDetails{get;set;}
}

购物车起源

对于大部分B2C网站来说，购物车是网站的咽喉之地，订单是白花花的银子，所有银子都必然流经购物车，购物车不能有失。

优秀的购物车设计至少需要完成两项使命：
一是方便用户多买货多掏银子;
二是帮用户保管好待购的货品，方便下次接着掏银子。

购物车是个较复杂的系统，一般会跟订单、商品、库存、会员和促销等模块有暧昧关系，也算是牵一发而动全身。所以，在不了解购物车前，不宜轻易的指挥你的程序员修改购物车。

传统的购物车一般指超市中顾客去结算前暂时存放所选商品的一种手推车。1937年6月美国人Sylvan Goldman 发明了第一辆购物车，随后购物车风行各国卖场。在中国，大家熟知的是以“沃尔玛“为代表的“美式购物车”和以“7-Eleven”为代表的“日式购物车”。

购物车存在的价值是：

1. 便于客户在选购商品到结算完成前存储商品，解放客户的手。实际上是让用户多购买商品，提高客单价。
2. 不仅可存放选购好的商品，还附带了婴儿车的功能，让带小孩的父母方便购物。
3. 沃尔玛在2007年率先于超市中采用无线射频技术(RFID)，每件商品打上电子标签，放入购物车中的商品能被追踪，结算时无需扫描每件商品，购物车经过特殊的扫描装置后即可计算出最终的总价格。

购物车被广泛用于分析用户的购买行为。

image.png

在线购物车，这里是指用户点击按钮“加入购物车(add to shopping cart)”到点击“去结算(check out)”按钮之间的过程。值得注意的是，购物车不仅仅指“shopping cart page”!

大概在传统购物车被发明60年后，1995年，美国人Mark Mumma (web site designer)发明了第一个Online Shopping Cart(这里指的是购物系统)，而至于本文提到的购物车的在线购物车的发明者，没有考证出来。1999年4月，又是美国人Juliette Harrington 发明了一项专利：虚拟购物车，该技术使在线用户能够用一个通用的虚拟购物车从不同的网站采购商品和服务，最后仅仅在一个地方付款(没记错的话，2008年亚马逊网站使用了该项专利，具体可以查看：https://payments.amazon.com/sdui/sdui/business/cba/shoppingcart#features)。

在线购物车主要作用在于：

1. 和传统卖场类似，方便用户一次选择多件商品去结算。
2. 充当临时收藏夹的功能。
3. 对于商家来说，购物车是向用户推销的最佳场所之一。

什么时候可以考虑不要购物车?

在传统的的小超市和商店是没有购物车(或购物篮)的，因为距离短、空间小等原因。电器城、电脑城也没购物车吧?因为代送货&顾客东西买得少吧? 和在线购物车对应的另一个功能是“立即购买”，也就是一次只能选择一件或一套商品去支付。理论上没有购物车是能走通流程的，现在的ebay和当年的淘宝是只有“立即购买”没有购物车的。

以下情况可以考虑用“立即购买”代替购物车：

1. SKU数少，当年的减肥产品“绿瘦”的官网很典型;
2. 商品结构单一，比如只卖杯子，不卖其它产品，你的用户大部分情况下也就只会买一个杯子(当然，你可以通过套装功能组合销售卖多件，但不需要购物车)。
3. 通过数据分析，发现用户订单平均商品数无限接近1(当然这有关联销售不力的可能)。
4. 你非常期望你的用户每次只买一件商品就滚蛋，不要磨蹭!

购物车入口有哪些?

购物车入口是指把商品加入购物车的途径。常见的有：在商品详情页把商品加入购物车、在收藏夹把商品加入购物车、在已购买成功的订单把商品加入购物车、在已取消的订单把商品加入购物车、把购物车页面的关联推荐商品直接加入购物车。

由于购物车直接跟库存和促销有关系，所以不同的入口，存在不同的处理逻辑。这里举2个例子，抛砖引玉，我不展开写：

1. 对已成功完成的订单，点击“重新购买”或“重新加入购物车”，若部分或全部商品没有库存该如何处理? 原来送赠品现在不送了，该如何处理?
2. 同理用在已取消的订单上，若有商品被删除或下架了，如何处理? 若目前可供购买的数量小于原订单，该如何处理?

同时，我们还需考虑不同的购物车入口的交互方式。如在商品详情页，商品加入购物车后，是直接进入购物车?迷你购物车下拉提示? 弹出层让用户选择去购物车or继续购买? 哪种做法适合你的网站?购物车的入口处理我暂时写到这里，提供一篇很精彩的文章供大家继续研究：http://blog.csdn.net/youshandeyang/article/details/5316568yixieshi

购物车的出口

有入口必然有出口，我把购物车的出口解释为：商品移除购物车的途径。常见的方式有三种。

1. 购物车商品被携带去结算，并成功提交订单; 这是最常见的方式这里需要重点考虑一个问题：若登录前商品A被加入购物车，实际上登录状态下用户的购物车保存了商品B和C。在购物车点击“去结算”，要求用户登录，登录后被携带去结算的商品是A，还是A+B+C? 或者让用户自己选择(shopex的做法)?
2. 购物车商品被删除;
3. 购物车商品被加入收藏夹。若购物车中商品能被加入收藏夹么?加入收藏夹后，购物车中该商品记录要被同时删除么?

下面进入解说具体功能的阶段，设计功能前得明白产品的核心功能是什么，扩展功能是什么? 核心功能上可以做哪些延展，扩展功能又能做哪些延伸。先理解购物车的主要作用：1、方便用户携带多件商品一起去结算;2、临时商品储存地。而购物车次要作用有：1、让用户多买东西，提高客单价(网站价值观不同，有的网站期望用户赶紧进入下一步去结算)。

购物车核心功能&延展功能

见下图，由用户需求推导出购物车核心功能需求。下图是一个购物车应该满足的功能需求，当然，根据自身网站情况可增减。

image.png

购物车扩展功能&延展功能 互联网的一些事

文字懒得写了，还是画图快。。

image.png

购物车的状态

这是一个较容易被忽略的点，一般情况，用户常见到的购物车状态是登录前或登录后购物车有商品。实际上还包括登录前或登录后购物车为空、登录前或登录后购物车有商品(部分或全部)被下架、库存为零等状态。

1. 登录前购物车有商品：这是一种很好理解的状态，对于有会员等级还享受会员折扣的站点，要考虑的问题是登录前和登录后商品的价格可能不一致，如果在购物车使用优惠券，登录前能否使用?
2. 登录后购物车有商品：这种状态是最常见的，就不说了
3. 登录前购物车为空：首先要考虑的一点是，如果购物车没有商品，是否允许用户点击进入购物车页面? 如果允许，购物车要做的工作有哪几件? 我总结了下，常见的提示有：
   1)告诉用户购物车为空，并给出返回首页继续购物的快捷链接
   2)告诉用户未登录可能导致购物车为空，提示用户登录;
   3)推荐商品给用户。
4. 登录后购物车为空：参照登录前为空的第2和第3点
   登录前或登录后购物车商品全部或部分被下架或库存为零：这是一种非常特殊的状态，至少得解决2个问题：
   1)告诉用户有商品被下架或库存为零;
   2)用户是否能继续去结算?如果阻止用户去结算，用户需要做什么?

购物车数据的保存方式

这段是稍偏技术的话题，但仔细看看也较好理解。在看这段文字前，你需要简单理解“cookie、session和数据库”三个概念。当然，这里我就不解释了，自己去google一下吧。购物车数据的保存是一个非常细节的体验，但同样非常重要，实际上数据的保存方式直接影响用户收藏商品的体验。用户常会有这么3个疑问：

1. 网站A，为什么我加入购物车的商品，第二次登陆该网站后，商品消失却消失了?
2. 网站B，为什么我换一台电脑，购物车中的商品却没了?
3. 网站C，我没有往购物车添加商品呀，谁用了我的电脑呀? 互联网的一些事

根据每个网站实际情况，一般需要考虑以下情况：

1. 登录前，往购物车添加了商品，商品数据该保存在哪?cookie or 会话方式?
2. 登录后，往购物车添加了商品，商品数据该保存在哪?cookie or 会话方式 or 数据库?保存多久?
3. 未登录状态下往购物车添加了商品，保存方式为A，后来登录了，保存方式为B。A和B应该是怎样一种关系。用户退出登录后A和B又怎样一种关系、怎样一种处理逻辑?
4. 如果在使用cookie保存数据，假设用户浏览器禁用了cookie，如何处理?
5. 假设用cookie保存数据，什么情况下cookie保存的数据会被系统清除(注意是系统而不是人为)?
6. 假设用数据库保存购物车数据，什么情况下数据库保存的数据会被系统清除?

再同时，可以结合数据的保存方式，考虑购物车数据营销：

1. 某A注册用户放弃购物车了，是否可以考虑一个星期后触发邮件提醒对方?
2. 如果购物车数据要被系统清除，在这之前，是否考虑邮件提醒用户?
3. 如果用户对你的邮件提醒无动于衷，是否考虑给点优惠勾引?如给优惠券，给折扣!

迷你购物车

较多的是考虑交互、信息组织和界面问题，此处略。
最后，送一副心智图，欢迎传播

image.png