核心数据谓词——有什么好处？答案

【问题标题】：Core data predicates - what’s the benefit?核心数据谓词——有什么好处？
【发布时间】：2021-01-24 09:05:37
【问题描述】：

我最近开始学习 Core Data，我完全明白为什么托管可观察对象会带来巨大的好处。

我不清楚的部分是为什么谓词在我看来只是 sqlishy sn-ps 时被认为如此强大。这根本不是问题，因为它也使代码可读。但是 sn-ps 包含字符串形式的对象属性，如

„myProperty == @d“

如果我重构我的实体以便重命名属性，我现在必须检查每个 FetchRequest 并修复谓词字符串。如果没有，错误不会在构建时发现，而是在运行时发现。

这至少是我的理解（这可能是一种误解），这让我非常恼火，以至于我想就这个话题寻求见解或建议。

【问题讨论】：

现在有了%K + #keyPath() 你很好，不清楚你是否也在问这个问题，但真正的优势是过滤器在查询中，所以你不要获取所有（对于“无”）而只获取需要的。
谢谢，是的，这是一个明显的好处，我已经有了使用一堆谓词的沙盒实现（目前都在一个字符串中）。我一开始就假设谓词用于 Core Data，就像 CriteriaAPI 用于 JPA 一样，在任何地方实际上都没有字符串，我可以有条件地添加或删除条件（因为它全部用代码表示）。我已经偶然发现 NSCompoundPredicate 可能是获取核心数据条件标准的方法。

【解决方案1】：

“sn-ps”，正如您所说的，可以包含属性名称，但您不必将属性名称用作文字字符串。您可以改为使用 %K 占位符替换相关的属性名称，并使用 #keyPath 功能从（编译器验证的）属性名称创建字符串：

NSPredicate(format:"%K == %@",#keyPath(MyEntityClass.myProperty),...)

有关%K 占位符的更多信息，请参阅here，有关使用#keyPath 的讨论，请参阅here。

所以不必烦恼 - 您可以确保您的谓词在编译时得到验证并且更容易休眠。

【讨论】：

谢谢，感谢！我偶然发现了 %K 占位符，但示例代码也使用字符串作为替换。 #keypath 是我想要的！还要感谢您的链接，我已经对前面的第一篇文章感到非常困惑：D