2.4 Commerce Order 模块：提供了订单处理任务的相关功能
2.4 Commerce Order 模块：提供了订单处理任务的相关功能
Commerce Order 即订单模块，它可以说是 Drupal Commerce 的核心。 后续介绍的几个重要模块，它们的功能都是以订单模块为基础的，它们包括：
- Commerce Cart 购物车模块
- Commerce Checkout 结账模块
- Commerce Promotion 促销模块
- Commerce Payment 支付模块
- Commerce Tax 税务模块
在前面的一节中，我们知道，只要是实现了 PurchasableEntityInterface 接口的实体， 都可以放到订单中构成订单项，进而创建订单进行购买。
因此 Commerce Order 是一个通用的订单系统，它不单止可以购买ProductVariation, 它被设计成可以购买任意东西，只要开发者为Entity实现 PurchasableEntityInterface 接口即可。
在下文中，我们将使用 商品一词来指代可购买对象， 即实现了 PurchasableEntityInterface 接口的Entity对象。
Entity 数据结构
本模块中只有两个 Content Entity，同时它们都有Bundle:
OrderOrderItemOrderType: Bundle ofOrderOrderItemType: Bundle ofOrderItem
Order Entity用于存放订单的整体信息。比如订单所属用户、店铺、总金额等。
OrderItem Entity用于存放订单明细项，也就具体购买的商品列表， 包含商品单价、购买数量等信息。
特别值得注意的是，他们的Bundle的作用。
OrderType即订单类型，不同的商品类型可能有着不同的订单处理过程，因此需要不同的订单类型。 比如，实物商品需要邮寄给顾客，有发货，运送，收货等过程，但是软件商品只需要提供一个下载连接即可。 Commerce Checkout模块通过此特性使用每一种订单类型，都可以关联不同的结账流程Checkout Flow， Checkout Flow是一个很重要的东西，后面Commerce Checkout模块章节再详细对其讲解。
OrderItemType，订单中的订单项，也使用了类型的概念，它与OrderType出现差不多的相同目的， OrderType通过与OrderItemType的关联，间接使得每种 PurchasableEntity 都有特定的 OrderType。也就是说，一个订单中，只能包含同一类型的 PurchasableEntity。如果你希望网站的 所有商品都可以放进同一个订单中结账，那么这些商品你应该通过同一个 Entity类型来实现， 比如 ProductVariation，或者你自己实现的Entity类型。
Order Adjustment 订单调整
当我们要实现促销功能、运费功能时，实际上是对订单的金额做调整，但如果只是把金额这个数字做一下调整， 我们会发现在数据上会分不清这些金额调整都是什么原因，因此有了Order Adjustment这个设计。
一般来说，我们会觉得应该做个单独的 Entity 类型来存放订单调整项，但是，Drupal Commerce 的设计者并没有这么做，这些调整数据目前是通过一个自定义字段commerce_adjustment来保存的。
在代码中，每一个调整项，都用一个php对象来表示，这些对象数据被直接序列化保存到commerce_adjustment 字段中。
订单调整项是分订单调整和 订单项调整的。前者是针对整个订单金额的整体调整，比如"订单满100减20"这种 促销，邮费的附加等。后者是针对单个订单项的调整，比如"商品A限时打8折"。我们去查看Order和 OrderItem 两个实体类型的字段时，会发现它们都有一个commerce_adjustment字段。
Commerce Order模块本身已经定义了几种常用调整类型，调整类型是通过模块根目录下的配置文件来定义的， 如果我们查看Commerce Order模块下的 commerce_order.commerce_adjustment_types.yml文件， 可以看到里面已经定义的调整类型。 如果我们在做开发的时候，需要做一些自定义的调整项，我们可以在自己的模块目录下添加YUOR_MODULE_NAME.commerce_adjustment_types.yml文件。
如何为订单或订单项添加调整或删除调整？
直接操作 commerce_adjustment 字段即可。具体可以参考Commerce Promotion模块的代码。
Order refresh and processing 订单刷新处理
在讲述订单刷新处理的概念前，我们先来考虑一个情景：
商品A的价格是100元，某用户把它放进了购物车（草案订单），但是随后商家把商品的价格修改为80元，这时购物车的商品 单价和实时单价就不一样了，所以我们需要在特定的时机，把购物车的单价更新为实时单价。
如果认为这个情景很勉强，我们再来看看另一个情景：
商品A的价格是100元，某用户把它放进了购物车（草案订单），但是随后商家发布了一个限时促销，商品A可以打8折， 那么还没结账的购物车商品必然是要可以参与促销，所以在特写时机为购物车订单添加价格调整项是一个需要处理的问题。
Order refresh and processing 就是要解决此类问题的一个机制。以上两个情景，均是Drupal Commerce 本身已经实现好的功能，前者是Commerce Cart 模块的内容，而后者是 Commerce Promotion模块的内容。
如果我们在开发中需要对订单添加刷新处理逻辑，可以实现一个 Drupal 服务，然后把该服务打上commerce_order.order_processor 标签。具体可以参考 Commerce Promotion模块的代码。
Order Workflow 订单的状态流
每一个订单都需要有一个状态流，比如待支付 -> 待发货 -> 待收货 -> 已收货。 很显示不同类型的订单，很可能需要不同的状态流。
Commerce Order模块使用了一个叫 state_machine 的社区模块来实现这个需求。 此模块实现了一个字段类型 state，在字段设置中可以指定所使用的状态流。状态流是通过yml文件定义的。
在Commerce Order模块目录下，有 commerce_order.workflow_groups.yml 和 commerce_order.workflows.yml 两个文件，前者定义了一个状态分组，后者在这个分组下定义了4个状态流。
具体如何使用，可以参考commerce_order Entity的state字段配置。
对文章内容有疑问题的朋友可以加QQ群讨论：747120338
本书共11小节。
评论 (1)
-
edwinkent