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