关于典型使用的核心数据问题

现在人们对待管理者吗 将nsmanagedObject扩展为的对象 域对象,还是创建 严格分类存放 并创建助手方法来创建 它们进入域对象?我有时 查找使所有持久性逻辑远离 域名是一件好事。

如果您创建了完全独立的域对象,那么您就有成本使它们与核心数据模型保持同步,并保持核心数据和这些对象之间的转换正常工作——另外,内存中有重复的对象,这取决于您拥有多少对象,这可能是一个问题。

但是,使用单独的域对象的好处在于,您不再与托管对象上下文相关联。一种情况是,如果维护对托管对象的引用,然后执行一些后台操作,则会导致主托管对象上下文删除对象-现在,如果访问已删除托管对象中的任何属性,则会触发错误异常(即使已显式加载对象但未出现错误)数据)。

我尝试过的一件中等成功的事情是,为特定用途偶尔会有非常轻量的独立数据对象——我所做的就是定义一个协议来表示数据对象访问器,其名称与核心数据访问器相同。然后,我让核心数据对象和一个自定义的独立数据对象实现了这个协议,并有一个机制自动将属性从一个复制到另一个。因此,我并没有将每个对象都作为自定义对象,并且可以将来自本地存储区或独立存储区的对象互换处理。

我对这个还没有明确的偏好,但是由于缺少重复,我倾向于直接使用托管对象。您可以通过监听更改或使用核心数据控制器类来减轻不良的副作用。

有一件事可以帮助保持域对象和数据对象的排序不变,那就是使用mogenerator生成数据对象。它为核心数据存储中的对象生成非常好的对象表示,以及要编辑的前端对象——添加自定义访问器或复杂方法。更改数据存储时,mogenerator会重新生成数据对象,但只保留自定义代码。

http://rentzsch.github.com/mogenerator/

打扫一下怎么样?如何做 当 应用程序关闭,或可能使中的数据过期 本地存储?我当然不会 希望保留用户的数据 随时打电话。

数据通常足够小,我就把它放在那里,有一个过期时间戳供使用,这样您就可以知道何时数据太旧而不能直接使用。由于用户频繁地关闭和重新打开应用程序,因此保留数据非常有价值,而且在数据已经存在的情况下,您可以在获取内容更新的同时立即显示结果。

有什么原子性与 核心数据?我的实施将 之前先在本地检查数据 我想访问网络服务 确保永远不会有一半 正在提交到本地的数据集 存储并获得有趣的结果。

原子性是指在上下文中执行操作,然后告诉上下文保存。因此,真正的原子性意味着在准备好之前避免其他组件发出保存,这通常意味着在自己的上下文中做一些事情,并重新合并到主上下文中。

我想经营一些 获取数据的后台线程 背景,我有什么事吗? 坚持时需要考虑 后台线程上的对象?

每个后台线程都需要自己的上下文,您应该监听保存通知,并在那时合并到主上下文中。

您应该尽力避免重复的请求,这些请求可能同时保存到相同的对象中,这有时会导致合并时的核心数据错误。与此相关-在主上下文上设置合并策略,默认策略是引发异常。

这也意味着在进行建模时,尽可能多地选择独立的对象,而不是一个从许多不同源聚合数据的大型对象。

有关保存和合并到其他上下文的详细信息,请参见以下问题:

CoreData and mergeChangesFromContextDidSaveNotification

关于上述问题, 创建一个 “后台提取”循环?在应用程序中 代表?每个视图,取决于 视野?等。。。?

我喜欢从一个单独的singleton类(毕竟,AppDelegate本身是singleton…)中完成这项工作,除了线程特定的上下文之外,我还可以请求主托管对象上下文。

这在启动新的核心数据项目时也很有用,您不必使用核心数据模板,只需重新使用这个核心数据管理器。