前言
在前一篇中介绍了关于行为定义中Business Events的使用介绍，本篇继续介绍关于行为定义中的保存选项Save Options，总体来说你可以在行为定义中选择不同的[1]保存选项，比如完全托管，或者附加保存，或者非托管。
正文
从大的开发类型上来说，主要分为managed托管和unmanaged非托管两种类型：
Managed 托管场景
-
• Managed Save： 默认情况下的处理模式，CUD操作完全由框架托管，无需自行处理，只需要关注业务处理逻辑即可。 -
• Additional Save： 你可以使用附加保存来添加额外的功能，此功能将在更改对象数据之后，事务提交之前的节点被触发，比如你可以在此节点进行记录操作日志等类似的处理。 -
• Unmanaged Save： 如果你不想使用标准的保存序列，想使用自己单独的逻辑保存业务数据，那可以选择此选项（仅保存序列需要自行处理，交互阶段的数据缓存，锁等逻辑仍然完全由框架处理）。
Unmanaged 非托管场景
非托管场景下，所有交互阶段的数据CRUD，数据缓存，锁管理，保存序列中的持久化[2]处理，都需要自定处理，尤其是具有多层级关系的BO，为了保证事务一致性，UI交互操作阶段的数据需要保存到事务缓冲区，也就是需要用Buffer类进行管理，直到调用SAVE方法时才持久化到数据库，所以完全unmanaged的场景维护成本较高，后面会单独创建一份示例应用来说明关于unmanaged场景的基本使用以及Buffer类的创建。
关于两种场景的保存序列运行时流程图如下所示：
本文将仅介绍managed场景中关于additional save和unmanaged save的使用介绍，关于additional save其实在上一篇Business Event中已经有一个应用场景了，但是是在云环境中进行实现的，本例将在之前OP版本的managed示例程序基础上继续进行，完全unmanaged场景的示例将在后续文章中单独写一篇。
Additional save
下图是托管场景中事务生命周期内的additional save说明图：
-
• 在至少成功执行一次修改（Create/Update/Delete）并且请求保存操作后，将触发保存序列，从FINALIZE步骤开始，该步骤可以在数据持久化之前进行最终计算和确定； -
• 如果随后的CHECK_BEFORE_SAVE调用的validations操作都正确通过，则到达不可逆点，从此时开始，必须保证所有相关的业务数据都能成功保存；如果validations没有正确通过，则中断保存序列，用户可以在重新修改数据之后再次触发保存序列； -
• 在到达不可逆点（point-of-no-return）之后，框架会将事务缓冲区中的所有数据持久化到数据库中； -
• 对于每个业务对象的实体，保存步骤将根据行为定义中的指定模式进行处理：SAVE Managed 或者 Additional SAVE 或者 SAVE Unmanaged。 -
• 当所有LUW的变更请求都提交之后，框架将执行COMMIT WORK进行提交； -
• 最终调用CLEANUP来清楚所有事务缓冲。
Ok，现在开始additional save的具体实现过程，本步骤出于演示，实现逻辑为记录指定字段的变更记录履历。