如果它是只读的，是否有任何理由为派生属性建模瞬态属性？在我的自定义类中声明一个属性，然后在运行中计算 getter 中的值似乎要容易得多。我会将其与 keyPathsForValuesAffecting 结合起来，以通知观察者有关更改。如果我需要缓存，我只需为该属性添加一个 ivar 并在其中一个基础值更改时重置它（如该问题的答案中所建议的那样）。
将其建模为瞬态属性会有什么优势吗？
问问题
1648 次
1 回答
7
事实上，我正在做这件事，因为核心数据编程指南中的这句话，“考虑一个应用程序，其中你有一个具有 firstName 和 lastName 属性的 Person 实体，以及一个缓存的瞬态派生属性 fullName”。这就是我相信我想出这将是一件好事的想法的地方。
但是，它继续说，“（实际上可能不太可能缓存 fullName 属性，但该示例很容易理解）。”，让我知道这实际上只是他们所描述的示例但可能不是很好的实施。
因此，在阅读了有关瞬态属性及其预期用途的更多信息后，我意识到这可能是一种不好的使用方式。为我的实现缓存它没有任何好处。我确实喜欢使用“点”表示法（因为它是一个属性）而不是向对象发送消息的能力，但我不相信使用它会带来任何性能提升。
更重要的是，我相信将其作为托管对象上下文必须跟踪的属性的开销实际上使它成为一件坏事。
因此，我将重构我的应用程序，现在在我的 managedObject 实体的子类上创建这些简单的实例方法，并且只返回结果，因为我看不出将它们设置为瞬态属性没有真正的好处。
使用其中之一的原因是，当您实际需要保留不适合其中一种 managedObject 类型的内容时。但是，您基本上会创建两个属性。一种是瞬态的，是您的对象的真实表示，您为此编写 getter 和 setter，另一种很可能是二进制数据类型，仅由核心数据实体子类在内部用于持久化其他对象的值(s) 在存储对象中。
至少这是我对这一切如何运作的理解。如果我有任何错误，欢迎发表评论，因为这对我来说也很困惑。
于 2012-01-19T00:44:22.070 回答