5、Salesforce开发：触发器架构与执行控制

Salesforce开发：触发器架构与执行控制

1. 技术债务与自动化工具使用

在开发过程中，技术债务偿还的概念较为常见，但在Salesforce领域相对较少。部分大型组织会在每个开发周期专门安排时间审查现有代码，确保更新时消除技术债务。这对于支持Salesforce提供的API版本尤为重要，应尽量减少代码库中不同API版本代码的差异。

使用自动化工具和代码时，需谨慎预估 governor 限制的使用并尽量减少。例如，当对象上同时有触发器和流程进行更新时，应考虑合并二者以避免重复的DML操作或更新。因为在“after update”触发器和流程中更新记录会使保存执行顺序触发两次，这不仅可能不必要地消耗 governor 资源，还会因执行顺序的重复运行而降低终端用户的体验。

因此，在使用多个自动化工具时，建议为每个对象合并为单一工具，若使用Apex触发器，很可能是因为存在 Process Builder 或 Flow 无法满足的需求。重要的是针对每个对象进行处理。若在账户对象上运行的代码会更改相关联系人，可考虑用代码管理两个对象的自动化；若没有代码，则继续使用点选式自动化工具。

2. 触发器架构

• 单触发器原则 ：与每个对象仅使用一个 Process Builder 流程一样，每个对象仅使用一个触发器也是最佳实践。多个触发器无法保证执行顺序，可能导致意外后果；而单个触发器可控制更新顺序，因为代码会在触发器内顺序执行。
• 单触发器与单上下文触发器对比 ：有人会问为何是每个对象一个触发器，而非每个对象每个上下文一个触发器。例如，是使用