我喜欢直奔主题，直接来重点吧:
1、什么样的场景适合有购物车?
可能一直关注电子商务的人士注意到了：淘宝早期是没有购物车的，而象当当网，京东这类网站一开始就有购物车？什么原因呢？淘宝技术人员刚开始考虑不成熟么？显示不是，淘宝的技术人员可算是中国电子商务领域中最强的.
重点：
淘宝这类平台本质是多店铺的商城系统，上面的商家遍布全国，商家对应的仓库也遍布各地，用户在选购时，很有可能会把不同商家的货放到一个栏子里，如果直接生成订单，难道要快递员到北京取一个货，上海取一件货，广东取一件货...然后再打包在一起，统一送货么？显然不可能，所以，对于这类多店铺的系统，购物车可能并不适合。(注：不适合不代表不能实现) 而象当当，卓越，京东，1号店...这类平台上的所有产品都是运营商自己的，物流统一处理，当然用购物车会比较方便。
2、多个商家的产品同属一个购物车，这是一个问题?
不管怎么说，购物车确实是一个很方便的设计，所以在多店铺系统上，就算困难重重，也要想办法解决。那么问题1中的多商家的产品同属一个购物车时，如何生成订单？
答案：按商家拆分订单，即同属一个商家的产品，放在一张订单中。最终一个购物车结算时，有可能会同时生成多张订单。
附淘宝的处理截图：
这是淘宝的购物车
这是淘宝的购物车订单
3、支付方式/配送方式不同时怎么处理?
就算同一个购物车里的产品都是一个商家的，但是支付方式/配送方式也可能会不同，比如某件产品可货到付款，而其它产品必须先支付。或者某些产品因为体积比较大，运费很高，而某些产品的快递费用只要5块就能搞定。在拆分订单时，这些因素如何处理?
答案：取决于你的运营需求，我建议采用最大兼容处理。即：如果A产品的运费是5元，B产品的运费是10元，最终订单的运费用10元比较适合。(当然这不是绝对的，取决于你的设计倾向于卖家还是买家?) 如果C产品支持货到付款，而D产品必须款到发货，那么最终订单的支付方式统一用款到发货比较合适。(道理同上)
当然，如果您不嫌麻烦，理论上讲，可按支付方式进一步拆分订单。
4、噢，还有竞拍，秒杀，团购...这一堆烦人的东东?
竞拍，秒杀，团购等其它非常规销售的产品，一般来讲，下单后并不一定有效(比如限量秒杀，最终能不能秒到，还不一定呢？)，也不一定允许马上支持（比如竞拍，如果您的出价在竞拍有效期内并不是最高，应该不允许支付，否则你付了钱，最终没拍到，到头来还要处理退款，这样还不如不许付款--前提：如果您的出价并不是最高）。
所以，如果一个竞拍产品跟一个常规零售产品同时放在一个购物车中，那这个订单到底是允许支付？还是不允许支付呢？
我的建议：对于这类烦人的东西，在产品展示页面上，压根儿就别提供加入购物车的按钮。购物车只是给常规零售产品使用的。
5、打折，优惠，代销分成...等各种BT需求.
这些东西更难搞，但也不是没有解决办法，主要还是看业务需求，比如：如果优惠卷只是针对商家的，那么优惠卷可随商家一起拆分，在最终计算订单总金额时，减去相应的优惠金额即可。
但如果某些优惠卷，只能针对具体的某产品，那么就只能随产品一起处理了.
有些系统中，除了买、卖双方外，还可能会加入代理方，代理方卖出东西后，要根据代理价进行分成，这种要求，可能还要在订单明细上记录这些额外信息(比如代理方ID，对应的分成比例，以方便最终的结算)
当然，所有这类前提是必须逻辑上不冲突，如果逻辑上就自相矛盾，神仙也解不了.
6、最后一个问题，技术实现机制？
基本有三类方法:
A、基于数据库(在库中创建相应的购物车表，然后做CRUD处理)
B、基于Cookie(把购物车放在浏览器Cookie中，虽然不用存数据库，但是不能跨机器保存，这是该方式的缺点)
C、基于Profile(这个不多说，搞Asp.Net的都应该知道这玩意儿)
这三种方法，无所谓谁好谁坏，看个人喜欢和实际情况吧，哪个用着熟用哪个，我个人喜欢用Profile来处理，图个简单.
另外在用户体验上，尽量用JS在前端来处理类似总金额的计算（比如用户在购物车里更改订购数量时，购物车总金额应该实时更新，而不是搞个更新按钮，每次让用户提交表单，在服务端算好，再刷新html）
最后套一句广告词结尾：购物车，简约不简单！
