iOS - 核心数据堆栈作为带有主 NSManagedObjectContext 的单例

Posted 2023-03-05

【中文标题】iOS - 核心数据堆栈作为带有主 NSManagedObjectContext 的单例

【英文标题】：iOS - Core Data Stack as singleton with main NSManagedObjectContext

【发布时间】：2015-06-04 08:40:43

【问题描述】：

我看过很多教程，它们确实帮助我理解了父子托管对象上下文以及与此相关的其他内容。我准备开始在我的应用程序中使用它，但我有一个问题。为什么没有人使用单例来保持主要的托管对象上下文。我想从 AppDelegate 中提取与核心数据相关的对象并将其设置为自己的类会更好吗？类似Tutorial at raywenderlich.com 的内容。但是他们仍然实例化 CoreDataStack 类（这没问题，单例也必须实例化），并且当需要时，他们在 prepareForSegue 中设置 managedObjectContext （并将其设置为 AppDelegate 中的第一个视图控制器）。为什么不消除这种需求而只使用单例 CoreDataStack 并且如果需要可以在每个控制器中使用 managedObjectContext 呢？

第二个和额外的问题：我认为控制器中的代码越少而其他类中的代码越多越好。我认为它有助于提高可读性。那么，如果我将这段代码从控制器中移出并将其设置为 CoreDataStack 类或其他有助于处理 Core Data 请求和响应的类：

  func surfJournalFetchRequest() -> NSFetchRequest 

    let fetchRequest =
      NSFetchRequest(entityName: "JournalEntry")
    fetchRequest.fetchBatchSize = 20

    let sortDescriptor =
      NSSortDescriptor(key: "date", ascending: false)

    fetchRequest.sortDescriptors = [sortDescriptor]

    return fetchRequest
  

我知道这是可能的，但它更好吗？如果您从我这里获得应用程序代码，如果在控制器中是一行 CoreDataStack.fetchRequest("JournalEntry", sortedKey: "date") 会更好吗？

如果我把这段代码插入单例并创建带有闭包的函数呢？我将在单例中创建子托管上下文并在其中执行所需的操作，在控制器中我只需更改 UI：

  func exportCSVFile() 

    navigationItem.leftBarButtonItem = activityIndicatorBarButtonItem()

    let privateContext = NSManagedObjectContext(concurrencyType: .PrivateQueueConcurrencyType)
    privateContext.persistentStoreCoordinator = coreDataStack.context.persistentStoreCoordinator

    privateContext.performBlock  () -> Void in

      var fetchRequestError:NSError? = nil
      let results = privateContext.executeFetchRequest(self.surfJournalFetchRequest(), error: &fetchRequestError)
      if results == nil 
        println("ERROR: \(fetchRequestError)")
      

      let exportFilePath = NSTemporaryDirectory() + "export.csv"
      let exportFileURL = NSURL(fileURLWithPath: exportFilePath)!
      NSFileManager.defaultManager().createFileAtPath(exportFilePath, contents: NSData(), attributes: nil)

      var fileHandleError: NSError? = nil
      let fileHandle = NSFileHandle(forWritingToURL: exportFileURL, error: &fileHandleError)
      if let fileHandle = fileHandle 

        for object in results! 
          let journalEntry = object as! JournalEntry

          fileHandle.seekToEndOfFile()
          let csvData = journalEntry.csv().dataUsingEncoding(NSUTF8StringEncoding, allowLossyConversion: false)
          fileHandle.writeData(csvData!)
        

        fileHandle.closeFile()

        dispatch_async(dispatch_get_main_queue(),  () -> Void in
          self.navigationItem.leftBarButtonItem =
            self.exportBarButtonItem()
          println("Export Path: \(exportFilePath)")
          self.showExportFinishedAlertView(exportFilePath)
        )

       else 
        dispatch_async(dispatch_get_main_queue(),  () -> Void in
          self.navigationItem.leftBarButtonItem = self.exportBarButtonItem()
          println("ERROR: \(fileHandleError)")
       )
      
    
  

我只是想确保我的方法可以，并且会比原来的更好。谢谢

【参考方案1】：

我使用单例模式构建了我的第一个核心数据应用程序。这对我来说似乎是合乎逻辑的，因为无论如何只有一个核心数据堆栈。我错了，单例模式很快就变成了一团糟。我添加了越来越多的代码来将单例堆栈弯曲成可以工作的东西。最后我放弃了，我花时间用依赖注入来替换单例的混乱。

以下是我在转储单例之前遇到的一些问题：

由于该应用保留了重要数据，因此我的用户要求提供备份功能。为了从备份中恢复，我切换了 sqlite 文件，然后我将创建一个新的 Core Data 堆栈。如果您使用拉模式从单例中获取 managedObjectContext，那么以干净的方式执行此操作几乎是不可能的。所以我切换核心数据堆栈的方法是告诉用户他们必须重新启动应用程序。随后是exit()。不是处理这个问题的最优雅的方式。

在 Apple 添加 childContexts 之后，我决定摆脱撤消管理器和上下文回滚，因为这对我来说从来没有 100% 有效。但是更改我的编辑 viewController 以便它们使用当用户点击 cancel 时被丢弃的子上下文，这是一个令人难以置信的痛苦行为，因为我现在在一个 viewController 中混合了单例上下文和 viewController 本地上下文。 为了编辑关系的目标，我在 editViewController 中有 editViewControllers。因为我在编辑视图控制器中创建了编辑上下文，所以我最终将数据保存到不应该保存的主上下文中。解释起来有点复杂，但是即使外部编辑 viewController 中的用户点击取消，第二个 viewController 也会将新对象之类的东西保存到主上下文中。这总是会导致孤立的对象。因此，我添加了更多代码来弯曲单例，使其不再是单例。

我还有一个 CSV 导入功能，我想在用户按下“导入”之前预览数据。我为此建立了一个全新的基础设施。首先，我将 CSV 解析为基本上复制了我的核心数据类的数据结构。然后我构建了一个 viewController 来显示这些非核心数据类，甚至更多的代码重复。我只会在用户按下导入时开始创建核心数据对象。 摆脱单例模式后，我可以重用现有的数据显示视图控制器。我只是给它一个不同的上下文，在本例中是一个包含将要导入的数据的内存上下文。更干净，更少重复的代码。

我想其中一些问题并不是单身人士的错。我只是非常缺乏经验。 但我仍然强烈建议不要使用单例核心数据。

---

会是一行CoreDataStack.fetchRequest("JournalEntry", sortedKey: "date")？

您不需要单例。像这样的东西应该在您为 JournalEntry 创建的 NSManagedObject 子类中。

---

如果我将这段代码插入单例并创建带有闭包的函数呢？我将在单例中创建子托管上下文并在其中执行所需的操作，在控制器中我只需更改 UI：

为什么不创建一个根本不需要内部状态的方法呢？

class func export(#context: NSManagedObjectContext, toCSVAtPath path: String, 
                  progress: ((current: Int, totalCount: Int) -> Void)?,
                completion: ((success: Bool, error: NSError?) -> Void)?) 

更加灵活。

【讨论】：

感谢您的全面回答。我放弃了单例的想法，我会为托管对象上下文使用强大的属性。 fetchRequest 是对的，它在 NSManagedObject 中更有意义。您建议的最后一种方法看起来不错，但是应该将什么上下文作为参数？私人的还是主要的？我发布的最后一个示例主要是因为我不确定将这些方法（更复杂，...）移动到其他类是否好（这对可读性和重用性更好）。如果搬家怎么处理私人MOC。如果创建外部方法或内部。 ARC 和线程哪个更好？