为什么我要使用瞬态属性来表示核心数据中的派生只读属性？
如果派生属性是只读的，是否有任何理由为它建模瞬态属性？在我的自定义类中声明一个属性，然后动态计算 getter 中的值似乎要容易得多。我会将其与 keyPathsForValuesAffecting 结合起来，以通知观察者有关更改的信息。 如果我需要缓存，我只需为该属性添加一个 ivar，并在基础值之一发生更改时重置它（如 这个问题）。
将其建模为瞬态属性是否有任何优点？
Is there any reason at all to model a transient attribute for a derived property if it is read only? It seems like a lot easier to just declare a property in my customized class and then calculate the value in the getter on fly. I'd combine this with keyPathsForValuesAffecting to inform observers about changes.
If I needed caching I'd just add an ivar for the property and reset it whenever one of the underlying values changes (as suggested in the answer to this question).
Would there be any advantages in modeling this as a transient attribute?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
事实上，我正在做这件事，因为核心数据编程指南中的这句话，“考虑一个应用程序，其中有一个具有属性firstName和lastName的Person实体，以及一个缓存的瞬态派生属性fullName”。我相信这就是我想到这将是一件好事的想法的地方。
但是，它接着说，“（实际上不太可能缓存 fullName 属性，但这个示例很容易理解）。”，让我知道这确实只是例如他们所描述的内容，但可能没有很好的实现。
因此，在阅读了有关瞬态属性及其预期用途的更多信息后，我意识到这可能是使用它们的坏方式。我没有从为我的实现缓存它中获得任何好处。我确实喜欢使用“点”表示法（因为它是一个属性）的能力，而不必向对象发送消息，但我不相信使用它会带来任何性能提升。
更重要的是，我相信使其成为托管对象上下文必须跟踪的属性的开销实际上使它成为一件坏事。
因此，我将重构我的应用程序，现在在我的 ManagedObject 实体的子类上创建这些简单的实例方法，并仅返回结果，因为我认为使它们成为瞬态属性没有任何真正的好处。
使用其中之一的原因是当您实际上需要保留不适合托管对象类型之一的内容时。但是，您基本上创建了两个属性。一种是瞬态的，是对象的真实表示，您可以为其编写 getter 和 setter，另一种很可能是二进制数据类型，仅由核心数据实体子类在内部使用，用于保存其他对象值(s) 在存储对象中。
至少这是我对这一切如何运作的理解。如果我有任何错误，非常欢迎评论，因为这也让我感到非常困惑。
I was in fact doing this very thing, because of this quote from the Core Data Programming Guide, "Consider an application in which you have a Person entity with attributes firstName and lastName, and a cached transient derived property, fullName". Which is where I believe I came up with the idea that this would be a good thing.
However, it goes on to say, "(in practice it might be unlikely that a fullName attribute would be cached, but the example is easy to understand).", letting me know that this really was just for example of what they were describing but probably not good implementation.
So, after reading more about transient properties and their intended use, I realized that this is probably a bad way of using them. I am gaining no benefit from having it cached for my implementation. I did like the ability of using 'dot' notation (because it's a property) instead of having to send a message to the object, but I don't believe there is any performance gain by using it.
More importantly, I believe the overhead of making it a property that your managed object context must track, actually makes it a bad thing.
So, I will be refactoring my app to now make these simple instance methods on the sub-class for my managedObject entity and just return the results as I can see no real benefit to making them transient properties.
The reason to use one of these, is when you actually need to persist something that does not fit one of the managedObject types. But, you then basically create two properties. One that is transient and is the true representation of your object, for which you write getters and setters, and another that is most likely a Binary Data type that is only used internally by the core data entity sub-class for persisting the other objects value(s) in a storage object.
At least this is my understanding of how this all works. Comments are very welcome if I got any of this wrong as it's been very confusing to me as well.