代码片段:订单快照的属性结构

\application\api\service\Order.php中:

//订单快照:保存订单当前的状态。如,订单里商品价格、收货地址发生变化了,就成了快照。

private function snapOrder($status)

{

$snap = [

'orderPrice' => 0,

'totalCount' => 0,

//pStatus:保存订单里的某一个详细信息。

'pStatus' => [],

'snapAddress' => null,

'snapName' => '',

'snapImg' => ''

];

$snap['orderPrice'] = $status['orderPrice'];

$snap['totalCount'] = $status['totalCount'];

$snap['pStatus'] = $status['pStatusArray'];

//把数组存入数据库,把数组系列化成json字符串。把对象作为数据库某一个表的某一个字段,其实不是太好,维护困难。想存储一个对象,有两个常见办法:第一,把对象下面的每一个属性,拆开,再做一张表。第二(最好!),不选择关系型数据库,而是选择文档型数据库,如mongodb。中小型项目中,nosql数据库多半作为对关系型数据库的补充。

$snap['snapAddress'] = json_encode($this->getUserAddress());

$snap['snapName'] = $this->products[0]['name'];

$snap['snapImg'] = $this->products[0]['main_img_url'];

if (count($this->products) > 1)

{

$snap['snapName'] .= '等';

}

return $snap;

}

注记:

1、不要在一个方法里,一口气写完所有业务逻辑,应该巧妙地多封装成几个方法。这样可以简化主方法业务调用流程。方法是嵌套的。一般地,一个方法不建议超过50行。

2、当业务比较复杂时,可以提炼出几个主干和模型。模型是OOP思想的延伸,可以帮助理清业务思路。模型不仅仅是为了写代码,更是构建、拆分业务的思维方式。虽然现在做软件开发,基于时间关系,很少画UML建模。如,几个主要的模型:订单order、商品product、收货人address。

3、快照解决动态变化的问题,还有利于加快数据库的查询。一般地,写的速度远远是要大于读。为了加快数据库访问速度,会做读写分离。

4、结合业务,才能设计出较好的数据表结构。

  • 发表于:
  • 原文链接http://kuaibao.qq.com/s/20180401G0282000?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券