我目前正在开发一个从Web服务检索和更新数据的应用程序。该应用程序将能够存储多个身份的凭据,以便用户访问Web服务。
Web服务是数据记录系统,应用程序将能够通过Web服务创建,删除,更新和查看对象。核心数据对象仅用于反映服务器上的内容并为脱机查看提供一些持久性。我计划在通过Web服务或用户请求更新对象后通过刷新更新后台的核心数据实体。
我的问题是:
1)是适合这种用途的核心数据还是我要求麻烦?
2)是否有可能以这样的方式编写应用程序,以便当用户将配置文件切换到新标识时,应用程序会切换持久存储/托管对象上下文,以便新标识基本上是从旧标识的沙箱中进行的。数据条款。如果是这样,我会感谢一些指示,以帮助我了解如何做到这一点,因为到目前为止我还没有找到任何东西。我已经看到很多关于如何一起使用多个MOC和持久存储的参考,但不是如何完全切换到一个全新的“配置文件”......
答案 0 :(得分:0)
1)是适合这种用途的核心数据还是我要求麻烦?
这取决于数据的性质以及您打算如何使用它。涉及Web服务与此问题并不真正相关。你不太可能“惹麻烦”,但根据你想要做的具体而言,其他选择也可能是好主意。
2)是否有可能以这样的方式编写应用程序,以便当用户将配置文件切换到新标识时,应用程序会切换持久存储/托管对象上下文,以便新标识基本上是从旧标识的沙箱中进行的。数据条款。如果是这样,我会感谢一些指示,以帮助我了解如何做到这一点,因为到目前为止我还没有找到任何东西。我已经看到很多关于如何一起使用多个MOC和持久存储的参考,但不是如何完全切换到一个全新的“配置文件”......
当然,您可以拥有任意数量的不同持久性商店。切换时,您需要放弃对从一个商店加载的任何内容的所有引用,然后再切换到新商店。这意味着每NSManagedObject
,每NSManagedObjectContext
,每NSPersistentStoreCoordinator
。听起来您使用相同的数据模型,因此您可以保留现有的NSManagedObjectModel
。这可能意味着关闭整个UI,除了初始登录屏幕(尽管如果你真的很小心,你可能会做一些事情,比如用另一个替换NSManagedObjectContext
并更新UI)。你需要非常彻底地解决这个问题 - 如果你保持NSManagedObject
,例如,当它来自的NSPersistentStoreCoordinator
不可用时,那么然后你正在寻找麻烦。