适用于Mac / iPhone混合应用程序的数据存储

时间:2009-01-14 14:49:12

标签: iphone cocoa macos core-data

过去5个月左右我一直在进行iPhone开发,并且一直在使用Gus Mueller的FMDB进行数据库交互。我的下一个项目将同时拥有Mac和iPhone应用程序,他们将在它们之间共享数据,尽管最终,iPhone将主要是一个查看器应用程序,具有一些小的编辑功能。

我的问题是:Core Data能让我的生活在Mac方面足够轻松,使用Mac上的Core Data和iPhone上的FMDB编写我的数据模型两次是值得的吗?或者我应该只使用FMDB,以便我可以为Mac和iPhone重复使用相同的代码?

我在核心数据上略微探讨了一点,但并不多(主要是Hillegas书中的例子),所以任何支持核心数据的具体例子都会受到高度赞赏。为了记录,我真的很喜欢FMDB,我只是想知道在这种情况下Core Data会让我的生活变得更轻松。

编辑: 我理解FMDB和核心数据之间的核心差异,我主要想知道Core Data提供的“免费”是否值得对我的数据模型进行两次编码。

7 个答案:

答案 0 :(得分:13)

主要区别在于FMDB是SQLite的Obj-C包装器,而CoreData是碰巧在SQLite中存储数据的对象模型(您不是在编辑数据库而是编辑对象)。这意味着它的级别更高,并提供更多的抽象,但如果你知道你在使用数据库做什么,那么你应该没问题。就个人而言,我错误地分享代码,因为它可以减少错误,更容易开发和更快的发布。

答案 1 :(得分:4)

您可能还想调查OmniGroup中的OmniDataObjects框架。它在OS X和iPhone OS上的SQLite上实现了CoreData功能的子集。我相信他们在OS X和iPhone版本的OmniFocus中都使用过它。

答案 2 :(得分:3)

所以,现在可能已经彻底解决了这个问题,但是对于后人我想提一下,iPhone OS 3.0上的核心数据,如果你想使用它在Mac应用程序中,您可以与iPhone应用程序共享大量工作。

答案 3 :(得分:1)

我同意马丁的观点。如果您编写桌面应用程序,我会说使用Core Data。既然你正在做这两件事,那么尝试在存储模型之间进行转换时出现问题的可能性确实指向将FMDB用于桌面和手机。

答案 4 :(得分:1)

代码共享很好,但根据您的模型和模型控制器类的相似程度,您可能不希望完全折扣核心数据。例如,除了对象持久性之外,您还可以“免费”获得非常好的撤消/重做支持。你可能想要做一个快速的原型来判断你可能最终在两个应用程序之间重写的代码量。

答案 5 :(得分:1)

Core Data的优势在于它是一个对象图管理框架,它恰好持久存在于SQLite(或二进制或XML或自定义)数据存储中。因此,它管理单个对象实例的错误和对象之间的双向(包括多对)关系(包括基于这些关系传播或拒绝删除的几个选项)以及验证对单个对象属性和关系的约束(包括必需/可选,基数,范围等)。在OS X 10.5中,它还包括用于在模型架构之间半自动迁移数据存储的工具。

当然,缺点是它在iPhone上无法使用。如果FMDB满足您的需求,您可以更轻松地管理单个代码库而不是两个代码库。

最后一个选项,如果您可以为桌面应用程序要求Leopard,则使用FMDB编写NSAtomicStore子类。 NSAtomicStore必须将整个商店读入内存 - 因此你会在桌面客户端上放弃SQLite的一些好处 - 但由于数据将在iPhone上共享,我猜你不会有那么多的数据无论如何。使用这种方法,您可以在客户端使用Core Data,在iPhone上使用FMDB,并在两者之间使用通用数据模型/数据存储。

答案 6 :(得分:1)

我不知道您的项目涉及哪种类型的数据,但如果它以任何方式处理人员记录,并且记录数量相当小,您也可以使用内置地址簿( ABAddressBook类)作为数据库。

它允许您添加应用程序独有的属性(在其他不使用它们的应用程序中不可见),并且您可以免费在iPhone和Mac之间进行同步。