CoreData - NSManagedObject 子类的好处

Question

我试图在不创建 NSManagedObject 子类的情况下插入 CoreData。但我的应用程序因 NSManagedObject setValue:forUndefinedKey "name" 在 Category 中崩溃。

    let managedObjectContext = (UIApplication.sharedApplication().delegate as! AppDelegate).managedObjectContext
    let entitiyDesc = NSEntityDescription()
    entitiyDesc.name = "Category"
    guard let data = model.data else { return }
    for d in data {
        let managedObject = NSManagedObject.init(entity: entitiyDesc, insertIntoManagedObjectContext: managedObjectContext)
        managedObject.setValue(d.name, forKey: "name")
    }
    try! managedObjectContext.save()

继承 NSManagedObjects 有什么好处

Answer 1

您使用 Core Data 的方式没有任何问题。通常，您在以下情况下开始想要子类化：

• 您希望在NSManagedObject 上使用方便的方法
• 您正在使用模型中根本没有的瞬态值
• 想要对NSManagedObject 的创建或插入做出反应
• 希望向您的 UI 开发人员展示一个更易于使用的对象
• 希望在访问属性时避免使用“魔术字符串”

我确信该列表中还有更多内容。

您永远不需要子类化 NSManagedObject，但在许多情况下，它确实使您的代码更清晰，更易于维护。

您的代码中有几个 cmets：

• NSEntityDescription 和 NSManagedObject 不应以这种方式创建。您应该改用便捷方法NSEntityDescription.insertNewObjectForEntityForName(_:)
• 使用这样的强制尝试对错误处理非常不利。你FAR最好使用do/catch，这样你就可以完全询问错误。这对于会向您发送子错误的 Core Data 尤其重要。
• 像这样通过AppDelegate 访问NSManagedObjectContext 是一个糟糕的设计（是的，我知道它在Apple 模板中）。最好使用Core Data Programming Guide 中讨论的依赖注入，并避免访问AppDelegate 所固有的紧密耦合

Answer 2

继承 NSManagedObject 确实让您作为开发人员的生活更轻松。

• 无需麻烦setValue:forUndefinedKey。
• 每个实体的简单初始化器
• 使用 Xcode 自动生成的模型更容易管理您的实体

您应该查看official documentation 或this tutorial 以开始使用。

Answer 3

Marcus Zarra 的回答是 100% 正确的，但我想强调的是，考虑到“未定义键”和类型转换错误的风险，以及在脑海中记住哪些实体具有哪些属性键时的调试成本，是否子类化甚至不应该是一个选择。

强烈键入您的NSManagedObjects（即通过子类化）也会打开大量编译时检查和实用程序，尤其是在 Swift 中。

如果您是 Core Data 的新手，让我向您介绍我编写的库 CoreStore，它是围绕 Swift 的类型安全性进行大量设计的：

• 泛型允许零类型转换
• 实体感知NSFetchedResultsController-like 观察者
• 基于协议的数据导入

您还可以获得强大的功能，例如事务、渐进式迁移等。这就像训练轮上的核心数据；如果在 Core Data 中有不好的做法，CoreStore 很可能一开始就不会让你编写该代码。