所以我有一个过程让用户可以拍摄照片添加信息并上传到我的数据库。我的问题是我应该如何存储这些数据,以便可以通过我的所有控制器访问它们,当他们点击上传按钮时,它会将最终对象发送到服务器以添加到数据库中。我会使用核心数据吗?或者像结构?我只是想确保我正确地做到这一点。
答案 0 :(得分:5)
这是一个以意见为导向的答案,它也受到开发人员对各种基本概念的熟悉/舒适的影响。因此,虽然我不认为这是一个答案,这是我的意见。
我应该使用核心数据吗,所以我的所有控制器都可以访问它?
绝对没有!你不需要核心数据,只是为了创建一个同时由多个ViewController使用的共享数据源。您显然可以创建一个Singleton数据源对象,并且可以被所有VC访问。
但是,核心数据不只是共享数据源吗?
核心数据是持久数据存储,而您的结构不是。
假设用户拍摄照片,在上传之前退出应用程序,或者您想为用户提供离线功能,用户可以在没有互联网的情况下拍摄照片并将其排队上传,每当互联网回来时您的应用程序加载它对于服务器,如果你使用结构并将数据源保存在内存中,如果用户退出应用程序,用户所做的所有努力都会浪费,显然用户不会欣赏它。另一方面,如果您使用核心数据,您显然可以在sqlite文件中使用它,然后在您需要时随时访问它,即使用户在其间退出应用程序:)
托管对象上下文提供performBlock和performBlockAndWait以在多线程环境中同步对核心数据的访问,但是使用简单的struct数组,你必须自己编写它。
现在重新发明轮子没有意义吗?我们都知道像数组这样的数据类型不是线程安全的:)所以是托管对象上下文,但是iOS 5以后的托管对象上下文提供了令人惊奇的方便方法,如performBlock和performBlockAndWait,它们在处理多个共享数据源(managedObject)时简化了开发人员的生活。线程环境。
托管对象上下文提供有关实时发生的更改的通知,其工作方式类似于NSFetchedResultsController提供了一种机制来监视和更新数据源
我不认为这是一件大事,但为了与阵列达到同样的目的,我必须使用KVO。但是因为KVO不能使用快速对象,所以当数据源发生变化时,你必须覆盖didSet
方法并手动向所有VC发送通知。不那么优雅的解决方案不是:)
可扩展性和稳健性:
最后,你处理的记录数量也很重要。我是一家公司的一员,该公司在用户设备上/从用户设备上传和恢复数千张图像。在处理1000个图像的场景中,维护阵列总是令人痛苦并且内存打印也很昂贵,因为整个阵列将一直被加载。另一方面,NSFetchedResultsController
适用于页面错误机制。它仅在需要时才有效地加载数据。
可扩展性只是向管理对象实体添加新字段的问题,而稳健性与您相信的处理核心数据的技能集成正比。
一撮建议:
无论您使用结构数组还是核心数据,始终将图像存储在本地文件系统中,并在数据源中保留本地路径相对引用。在内存中保存整个图像是一个非常糟糕的主意:D
希望它有所帮助。