2011-10-31 47 views
8

如果派生属性是只读的,那么是否有任何理由为派生属性建模?在我的自定义类中声明一个属性,然后在运行中计算getter中的值似乎更容易一些。我将它与keyPathsForValuesAffecting结合起来,通知观察者有关更改。 如果我需要缓存,我只需为该属性添加一个ivar,并在其中一个基础值发生变化时重置它(正如this问题的答案中所建议的那样)。为什么我会使用transient属性来表示核心数据中的派生只读属性?

将此建模为临时属性会有什么优势吗?

回答

7

我实际上是在做这件事情,因为这个引用来自核心数据编程指南,“考虑一个应用程序,其中你有一个具有属性firstName和lastName的Person实体和一个缓存的瞬态派生属性fullName” 。我相信我认为这将是一件好事。它会继续说:“(实际上它可能不会缓存fullName属性,但这个例子很容易理解)”,让我知道这真的只是为了他们正在描述的例子,但可能不是很好的实施。

因此,在阅读了更多关于瞬态属性及其预期用途之后,我意识到这可能是一种使用它们的不好的方式。我没有从我的实施缓存中获益。我确实喜欢使用'点'符号(因为它是一个属性)的能力,而不必向对象发送消息,但我不相信使用它会有任何性能增益。

更重要的是,我认为将其作为托管对象上下文必须跟踪的属性的开销实际上使其成为一件坏事。

所以,我将重构我的应用程序,现在在我的managedObject实体的子类上创建这些简单的实例方法,并返回结果,因为我没有看到使它们成为瞬态属性的真正好处。

原因使用其中之一是,当你实际上需要坚持的东西,不适合一个managedObject类型。但是,你基本上创造了两个属性。一种是瞬态的,是对象的真实表示,为其编写getter和setter,另一种很可能是仅在核心数据实体子类内部用于保存其他对象值的二进制数据类型(s)存储在一个存储对象中。

至少这是我对这一切如何工作的理解。如果我有这个错误,评论是非常受欢迎的,因为它对我来说也很混乱。

+0

谢谢。我在四处搜寻关于“暂时性财产”和“派生财产”的解释。你帮我理解了这一点。我同意大多数情况下的用例是:“使用其中一种方法的原因是,您实际上需要坚持某些不适合某种managedObject类型的东西。” –