我刚刚开始使用 CoreData 制作应用程序,但我熟悉 MVC 概念,因为我曾经使用(和开发)MVC 框架在 Web 开发方面做了大量工作。
根据我的收集,CoreData 会自动生成继承自 NSManagedObject 的类。对象是通过对上下文的获取请求或通过将新对象插入上下文来创建的。在我见过的应用程序中,除了与其在数据库中的属性相对应的属性之外,这些对象都是空的,本质上使它们成为模仿实体表中一行的对象。
这些自动生成的类和 CoreData 本身构成了应用程序模型,这是有道理的。在我传统上制作的应用程序中,有一个Model
类负责处理所有数据。这通常是一个 Singleton 类,每个需要模型的控制器都可以简单地使用self.model = [Model sharedInstance];
. 对于更大的应用程序,可能有多个模型而不是一个巨大的模型。你得到图片。我想我的第一个问题是:我说的对吗?CoreData 及其关联的 NSManagedObject 构成了应用程序的整个模型?
我猜这是错误的,因为应用程序可能需要其他功能来处理没有分配 CoreData 对象的数据。例如:如果 CoreData 应用程序需要使用通过 foo.com/test 的 HTTP 请求检索到的数据(假设它是 JSON 数据)来填充表视图,该怎么办。这些数据不需要存储在 CoreData 中,但同时,我不认为检索和解析数据是控制器的工作。是否应该有一个对象FooDataManager
(或类似的东西)来处理 HTTP 请求以管理来自 foo.com 的数据(它可以扩展 AFHTTPClient)。然后处理 foo.com 的控制器有一个属性 for fooDataManager
,它充当该控制器的模型?然后控制器会调用[self.fooDataManager retrieveAndParseData];
?
我想在开始开发 CoreData 应用程序之前验证这些信息,以便从一开始就正确地完成它。在 Web 开发中,我习惯于每个控制器都有一个模型,但在 iOS 上,似乎可以有很多模型都做自己的事情,许多控制器使用这些模型,所有这些模型都是附加的到 CoreData 和 NSManagedObjects。