English 中文(简体)
Mac/iPhone混合应用的数据存储库
原标题:
  • 时间:2009-01-14 14:49:12
  •  标签:

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

我的问题是这样的:Core Data会让我在Mac端的生活变得足够容易,以至于值得我在Mac上使用Core Data,而在iPhone上使用FMDB来两次编写我的数据模型吗?还是我应该只使用FMDB,这样我就可以在Mac和iPhone上重复使用相同的代码?

我有过一点对Core Data的尝试,但并不多(主要只是Hillegas书中的例子),因此任何有利于Core Data的具体示例都将不胜感激。记录一下,我真的很喜欢FMDB,只是想知道在这种情况下,Core Data是否会让我的生活更轻松。

Edit: I understand the core differences between FMDB and Core Data, I m mostly looking to find out if what Core Data provides "for free" makes it worth coding my data model twice.

最佳回答

主要区别在于FMDB是SQLite的Obj-C包装器,而CoreData是一个对象模型,恰好将数据存储在SQLite中(您不是在编辑数据库,而是在编辑对象)。这意味着它更高级,提供了更多的抽象,但如果您知道如何处理数据库,那么任何一个都应该没问题。个人而言,我会倾向于共享代码,因为这会导致更少的错误,更容易的开发和更快的发布。

问题回答

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

因此,这个问题可能已经彻底解决了,但为了纪念,我想提到iPhone OS 3.0 中Core Data已经可以在iPhone上使用,如果您想在Mac应用程序中使用它,您可以与您的iPhone应用程序共享很多工作。

我同意Martin的观点。如果您只是编写桌面应用程序,我会建议使用Core Data。但由于您同时在为桌面和电话编写应用程序,将在尝试在存储模型之间转换时可能会出现问题,真正的解决方案是使用FMDB。

代码共享很好,但取决于你的模型和模型控制器类有多相似,你可能不想完全放弃核心数据。例如,除了对象持久性外,你还可以免费获得真正好的撤消/重做支持。你可能想做一个快速的原型来判断两个应用程序之间可能需要重写多少代码。

我不知道您的项目涉及哪种类型的数据,但如果涉及任何人员记录,并且记录数相对较少,您也可以使用内置的通讯录(ABAddressBook类)作为数据库。

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

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

当然,缺点是它不能在iPhone上使用。如果FMDB能满足您的需求,您可能会更容易地管理单个代码库,而不是两个。

如果你的桌面应用程序可以使用Leopard,则最后一种选项是使用FMDB编写NSAtomicStore子类。 NSAtomicStore必须将整个存储库读入内存中-因此,你将失去一些在桌面客户端上使用SQLite的好处-但是由于数据将在iPhone上共享,我想你不会有那么多数据。采用这种方法,您可以在客户端上使用Core Data,在iPhone上使用FMDB,同时跨两者使用相同的数据模型/数据存储。





相关问题
热门标签