为什么一个子类NSManagedObject?

Ver*_*ous 14 cocoa core-data nsmanagedobject

我已经阅读了很多关于NSManagedObject,Apple文档以及更多内容的SO问题,但我仍然没有真正得到NSManagedObject的子类 - 它起什么作用?

在Apple文档中,它讨论了我如何不能覆盖一堆方法,不应该使用自定义实例变量,blah和blah(我还不了解其中的一些),等等 - 所以我该怎么做使用NSManagedObject?有哪些限制,必须遵循的指导方针,以及哪些不是限制?

我正在尝试制作一个小盒子绘图程序来学习Core Data,我正在考虑将"draw"方法添加到NSManagedObject的子类中,以便视图可以告诉它们为自己绘制 - 这是允许的吗?

所以,我的一句话中的问题是,子类化NSManagedObject和任何其他类之间的"真正"区别是什么 - Core Data用它做什么?

如果这太宽泛,我会尝试缩小我的问题或者其他什么.

Ste*_*eve 25

我仍然没有真正得到NSManagedObject的子类 - 它起什么作用?

开发人员的便利性 - 在CodeSense方面,更短的语法和一些编译时检查,有助于防止密钥拼写错误.

那么NSManagedObject怎么办?有哪些限制,必须遵循的指导方针,以及哪些不是限制?

Xcode中内置的UI将为您创建NSManagedObject子类 - 您实际上不需要手动执行它 - 但是,基本上,它们只是添加NSManagedObject了一些属性.而不是使用@synthesize或者使用@dynamic,而是Apple 使用和Apple为你完成剩下的工作 - 将这些属性连接到模拟你通常用"裸"做什么的getter/setter NSManagedObject.

我正在尝试制作一个小盒子绘图程序来学习Core Data,我正在考虑将"draw"方法添加到NSManagedObject的子类中,以便视图可以告诉它们为自己绘制 - 这是允许的吗?

你可以....但我不会.这听起来像是糟糕的设计 - 尽量让你的模型控制器分开.

模型对象不应包含业务逻辑/绘图代码.将模型简单地用作应用程序的"状态".让其他东西对绘图负责.另外,虽然我不能用绝对的权威来说这个,但我相信如果你正在处理更新/检索信息,那么会有一些开销NSManagedObject.

(基本上,它就像处理NSDictionary...... sorta.从字典中获取项目的效率低于访问字典的效率ivar.)

对于执行绘图之类的应用程序 - 您可能希望通过为内存中的内容创建结构来避免这种开销,并且可能是第二种类似的持久性/序列化结构(如CoreData).

所以,我的一句话中的问题是,子类化NSManagedObject和任何其他类之间的"真正"区别是什么 - Core Data用它做什么?

我会说 - 不要手工创建NSManagedObject的子类 - 使用Xcode给你的东西.如果你想要更多(除了可能是自定义构造函数),那么你可能会咆哮错误的树.

编辑:

想当我说"根本不用手工创建NSManagedObject"时,我的意思可能会有些混乱.

详细说明,并纳入其中一个回复:

从Xcode中的数据模型设计器开始,创建模型,并使用以下菜单选项:

在此输入图像描述

然后,您可以修改生成的类以包含自定义:

  • 构造函数
  • 数据转换方法
  • 验证
  • 格式化
  • 排序描述符
  • 过滤器

如果您的用例不适合该列表,您应该认真考虑将其放在其他位置(如使用"Draw"方法的示例).

上面提到的所有这些内容都可以添加到由Xcode为我们创建的NSManagedObject子类(我们没有"手工创建") - 它们都围绕着直接处理数据(格式/转换/等)和/或将数据从核心数据中提取出来(过滤/排序).

它们不添加iVar,它们不执行数据存储和检索范围之外的任何复杂操作.

  • 大多数答案都很好,但我不同意"不要手工创建NSManagedObject" - 我还没有一个最终没有NSManagedObject子类的Core Data项目.处理瞬态变量和数据转换非常常见.它还提供更好的类型安全性.实际上,为了保持一致性,我几乎总是为每个实体创建一个子类.当一些是子类而一些不是子类时,它会变得混乱. (2认同)