Cocoa / Cocoa Touch应用程序中的“核心数据栈”的放置位置

在iPhone Core Data模板中，Apple将Core Data Stack放置在App Delegate中。

但是，我的初衷是将这段代码移到其自己的类中，该类负责处理核心数据栈的管理。

您通常将此功能封装在其自己的类中还是将其保留在App Delegate中？

简介：无需创建一个单一实例即可管理核心数据堆栈。确实这样做可能适得其反。

核心数据堆栈恰巧是由应用程序委托创建的。但是，重要的是，如所有示例所示，并不是直接从stack（*）检索堆栈（主要是托管对象上下文）。而是将上下文传递到第一个视图控制器，并将上下文或托管对象从上下文将它们从一个视图控制器传递到下一个视图控制器（如访问核心数据栈中所述）。这遵循iPhone所有应用程序的基本模式：将数据或模型控制器从一个视图控制器传递到下一个视图控制器。

如此处所述，单例的典型角色是作为模型控制器。对于Core Data，托管对象上下文已经是模型控制器。如果需要，它还使您能够访问堆栈的其他部分。此外，在某些情况下（如文档中所述），您可能希望使用其他上下文来执行一组离散操作。因此，视图控制器的适当货币单位通常是托管对象上下文，否则是托管对象。使用和传递管理堆栈（并从中检索上下文）的单例对象通常最多会引入不必要的间接级别，最坏的情况会带来不必要的应用程序僵化。

（*）没有示例使用以下方法检索上下文：

[[UIApplication delegate] managedObjectContext];

我有一个单例课程，可以让我做我的核心数据管理，而且我不把它留在应用程序委托中。我宁愿不要使用我可能需要说服性的方法（例如，获取某些对象等）来使应用程序委托类混乱

由于以下原因，我将核心数据逻辑留在了App委托中：

1）在其他类别中移动此代码时，我看不出任何真正的优势：委派的概念完全由App委托处理的核心数据逻辑实现，因为核心数据模型实际上是应用程序的基础部分；

2）在我看到的所有示例代码中，包括Apple示例，核心数据都是由App委托处理的；

3）即使在Core Data书籍中，让App委托人处理与核心数据相关的代码也是一种惯例；

4）就个人而言，我不认为通过为核心数据设置临时类实际上可以提高可读性或其他任何功能，但这是个人喜好的问题，在这里我不会争论哪种方法是最佳方法。对我来说，保持功能的简单性很重要。

在您的情况下，我会问自己一个问题：“核心数据堆栈属于谁？” 数据本身确实是应用程序的一部分，不是吗？（在Mac上，CF Core Data可能具有一个可以同时处理多个文档的应用程序，因此Core Data堆栈属于每个文档。）

在任何Cocoa / Cocoa Touch应用程序中，“应用程序委托”通常是自定义应用程序行为的首选方法，因此，这是“核心数据”堆栈的自然位置。

现在，我怀疑您遇到的问题是不断写类似的东西是错误的：

NSManagedObjectContext *context = [(MyAppDelegate *)[[UIApplication sharedApplication] delegate] managedObjectContext];

在这些情况下，我通常要做的是这样的写函数（而不是方法）：

NSManagedObjectContext *UIAppManagedObjectContext() {
    return [*(MyAppDelegate *)[[UIApplication sharedApplication] delegate] managedObjectContext];
}

我为NSPersistentStoreCoordinator和编写了类似的函数NSManagedObjectModel。我将所有这些都放在App Delegate的.h / .m文件中，因为它们也是应用程序级对象。

我将在新答案中列出。（我为此废弃了以前的FJSCoreDataStack类）

我处理此问题的新方法是在NSManagedObjectContext上使用类别。Ive添加了以下类方法：

+ (NSManagedObjectContext *)defaultManagedObjectContext;
+ (NSManagedObjectContext *)scratchpadManagedObjectContext;
+ (NSManagedObjectModel *)managedObjectModel;
+ (NSPersistentStoreCoordinator *)persistentStoreCoordinator;
+ (NSString *)applicationDocumentsDirectory;

这将所有内容排除在我的应用程序委托之外，并在我选择使用它时提供单例访问。但是，我仍然使用来自App Delegate的依赖项注入（如mmalc所说，它在我的代码中引入了不灵活性）。我只是将所有“核心数据栈”代码移到了NSManagedObjectCOntext类别中。

我喜欢传递参考，尤其是因为我有一个不错的“便签本上下文”方法。因为我没有将它们提交给“ defaultManagedObjectContext”，所以这使我的视图控制器保持灵活。

也与iPhone世界中的对话有关（可能与您的体系结构有关）： NSFetchedResultsController和构造NSFetchRequests

我赞成让应用程序委托知道模型从哪里开始，并让模型知道托管对象上下文在哪里。模型的核心数据“感觉”对我来说似乎是模型的实现细节，控制器类（如应用程序委托）应该问“向我提供有关模型的信息”，并且模型应该知道如何回答这个问题。因此，通过控制器对象可以使用Core Data对象似乎是一种泄漏抽象。