Data Guidelines — Choosing the Right Approach

嘿，同学们，我们来聊聊 Salesforce 里做数据访问时该怎么选技术。这个决策啊，其实有个很清晰的路径，咱们一步步来。 首先，最优先考虑的，永远是基本组件。比如 lightning-record-form、lightning-record-view-form 这些，它们是最简单的，能自动帮你处理元数据、页面布局、字段验证还有错误提示。你几乎不用写什么代码，就能搞定增删改查，性能也最好。所以，能用基本组件解决的需求，就别往下走了。 如果你需要多一点自定义，比如要自己控制 UI，但又想要数据自动更新，那就可以用 LDS 线适配器。线适配器是响应式的，数据变了 UI 自动刷新。这里面啊，要记住两点：一个是你如果需要一次查询多个不相关的记录，可以用 GraphQL 线适配器，它能把多个请求合并成一个，减少网络开销。另一个是如果你只是要取单条记录，而且希望它是响应式的，用 getRecord 适配器就好，它会自动缓存，反应很快。 接着，假设你只是想做一次性的操作，比如创建一条记录，然后拿到结果就完了，不需要响应式监听后续变化，那就用强制性函数，像是 createRecord、updateRecord、deleteRecord。这些是命令式的，你调用它们，它们就执行，不会自动响应数据变化。适合在按钮点击等明确动作里使用。 如果以上这些都不满足，比如你要访问的对象 LDS 根本不支持（像 Task、Event 这种），或者你需要写一个很复杂的 SOQL 查询，再或者你要在同一个事务里操作多条记录，做事务性控制，那才轮到 Apex。它是最灵活的最后手段，但也要你手动管理缓存、错误和性能，所以别轻易用。 最后给你几条性能指导，记在心里：能用 GraphQL 合并多个请求的，一定合并；在适配器里，能指定具体字段就不要返回整个布局，数据越少越快；还有，尽量选那个返回数据量最小的合适适配器。另外，LDS 的调用是不计入 API 使用次数的，但它们会受到一般的记录数量限制，所以设计的时候也要注意数据量。 总结一下，决策顺序就是：基本组件 -> LDS 线适配器（GraphQL 或 getRecord）-> 强制性函数 -> Apex。按这个来，你的代码会又简洁又好维护。