cocoa - 为什么要子类化 NSManagedObject 呢？

Question

我已经阅读了许多关于 NSManagedObject、Apple 文档等的问题，但我仍然不明白 NSManagedObject 子类化的用途是什么 - 它扮演什么角色？

在苹果文档中，它谈到了我如何不能重写一堆方法，不应该使用自定义实例变量，等等(我还不明白其中的一些)，等等 - 那又怎样我可以用 NSManagedObject 做什么？有哪些限制、必须遵循的准则以及哪些不是限制？

我正在尝试制作一个小方框绘制程序来学习核心数据，并且我正在考虑向 NSManagedObject 的子类添加“绘制”方法，以便 View 可以告诉它们为自己绘制 - 是这样吗允许吗？

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

如果这太宽泛，我会尝试缩小我的问题范围或其他内容。

Answer 1

I still don't really get what subclassing NSManagedObject is for - what role does it play?

为开发人员带来便利 - 在 CodeSense、更短的语法和一些有助于防止按键拼写错误的编译时检查方面。

so what can I do with NSManagedObject? What are the restrictions, must-follow guidelines, and what aren't restrictions?

Xcode 中内置的 UI 将为您创建 NSManagedObject 子类 - 您实际上不需要手动完成 - 但基本上，它们只是附加了一些属性的 NSManagedObject 。您可以使用 @dynamic，而不是使用 @synthesize 等，Apple 会为您处理剩下的事情 - 将这些属性连接到模仿您通常使用的 getter/setter 方法使用“裸”NSManagedObject 进行操作。

I'm trying to make a little box drawing program to learn Core Data, and I'm thinking of adding "draw" methods to a subclass of NSManagedObject so that a view can just tell them to draw for itself - is this permitted?

你可以......但我不会。这听起来像是糟糕的设计 - 尝试将您的模型和 Controller 分开。

模型对象不应包含业务逻辑/绘图代码。简单地使用模型作为应用程序的“状态”。让其他人负责绘图。另外，虽然我不能以绝对权威的方式这么说，但我相信如果您正在处理从 NSManagedObject 更新/检索信息，则会产生一些开销。

(基本上，这就像处理 NSDictionary...有点。从字典中获取项目的效率低于访问 ivar >.)

对于执行绘图等操作的应用程序 - 您可能希望通过为内存中的事物创建一个结构来避免这种开销，并可能为持久性/序列化创建第二个类似的结构(如 CoreData)。

So, my question in one sentence would be, what's the "real" difference between subclassing NSManagedObject and any other class - what does Core Data do with it?

我想说 - 根本不要手动子类化 NSManagedObject - 使用 Xcode 提供的东西。如果您想要更多(除了自定义构造函数之外)，那么您可能找错了树。

编辑:

我认为当我说“根本不要手动子类化 NSManagedObject”时，我的意思可能有些困惑

详细说明并纳入其中一项回应:

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

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

• 构造函数
• 数据转换方法
• 验证
• 格式设置
• 对描述符进行排序
• 过滤器

如果您的用例不适合该列表，您应该认真考虑将其放在其他地方(例如使用“Draw”方法的示例)。

上面提到的所有这些东西都可以添加到由 Xcode 为我们创建的 NSManagedObject 子类中(我们没有“手动”创建) - 它们都围绕着直接处理数据(格式/转换)/等)和/或从核心数据中提取数据(过滤器/排序)。

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