多用户商城开发逻辑总结

第一次接触多用户商城的开发，总结一下一些经验，梳理一下自己的逻辑。

入口

微信服务号和APP，需要接入微信和支付宝的APP支付接口，这块和之前用的网页支付的实现逻辑不同。APP接口用RESTful API来实现，做好良好的代码注释，还有就是这种一百多个表的项目，数据表和字段也要记得加上注释。

缓存

多商户加上用户浏览，在QPS比较高的情况下要及时做好缓存，本项目用的是文件缓存，Redis还不太会，流畅的体验会比较好。

购物车

关于购物车，这些数据要在数据库中，还是放在本地缓存中呢，之前做了一个小程序的单用户商城，购物车的数据我直接存储在了本地的localStorage，好处是处理起来非常快，坏处是存储在本地，换个环境之前的购物车数据就没了，当然这个项目的购物车是放在了MySQL中。

主订单

下单要检测库存，支付回调的时候再次检测库存，没问题进行减库存操作。

因为订单涉及到多商户，消费者购买的时候，可以会同时选择不同商家的产品，那么在生成订单的时候，采用的是条订单数据同时存放主订单号和子订单号这种模式，用户支付的时候，安装主订单的金额支付，在商家后台，按照子订单发货。创建订单的时候，做一下防止灌水处理，限定每个用户一天只能创建多少订单。

同一个商品，不同的规格价格不同，创建的订单商品表要把当时用户选择的规格和价格写入，商品的价格可以会发生调整，所以在创建订单商品表的时候，要把当时用户选择的商品的各种属性写入到表中，不要之写入商品id动态查询。分销金额也要这时候计算出来，这个每个项目不一样就不多说了。

还有一点是项目是有余额这个概念的，那么在进行订单支付的时候，如果采用余额支付，记录在了一条额外的主订单表中。创建订单涉及到的操作比较多，最好把这些处理放在同一个事务当中，以防止出现异常。

逻辑分层

• 为了项目的可扩展性，方法要尽可能小，最好是每个方法只处理一件事；

• 逻辑处理最少分三层，与view交互的控制层，处理数据的model层，处理业务逻辑的逻辑层；

• 做好方法注释，并且如果方法修改了，要对注释进行维护，可能自己写的代码两个月后就忘完了；

商家结算

在用户收货后，要给商家进行订单结算，如果用户没有点收货，做一个定时任务，或者某种条件触发满多少天自动收货，任何涉及到钱的问题，都要做日志，所以在本项目中存在大量的日志表。对于日志表，最好按照时间范围做一下分区，防止一个表数据量过大。

报表统计

报表统计这块，我们做项目经常容易忽视，可能报的开发工期中就没有包含这块，不过对于客户来说，整个系统最直观的体现就在各种统计，对于领导来说可能只是看个最终的统计数字就够了。

提示

系统中的各种提示，现在用的比较多的是layer这个插件，各种提示样式挺漂亮的，而且还有专门用户手机端的版本。