我一直在做iPhone过去5个月左右的开发，并且一直在使用Gus Mueller的FMDB进行数据库交互。我的下一个项目将同时拥有Mac和iPhone应用程序，并且他们将在它们之间共享数据，但最终，iPhone将主要是一个查看器应用程序，并具有一些较小的编辑功能。Mac/iPhone混合应用程序的数据存储
我的问题是：核心数据会让Mac在我的生活中变得足够简单，那么使用Mac上的Core Data和iPhone上的FMDB来写两次数据模型是值得的？或者我应该只为两者使用FMDB，以便我可以在Mac和iPhone上重复使用相同的代码？
我已经在Core Data上挖了一点，但并不多（大多只是Hillegas书中的例子），所以任何有利于Core Data的具体示例都将不胜感激。为了记录，我非常喜欢FMDB，我只是想知道Core Data是否会让我的生活在这种情况下变得更容易。
编辑： 我了解FMDB和Core Data之间的核心区别，我主要是想知道Core Data提供的“免费”是否值得我的数据模型编码两次。
主要区别在于FMDB是SQLite的Obj-C包装器，而CoreData是碰巧在SQLite中存储数据的对象模型（不是编辑数据库而是编辑对象）。这意味着它有更高的层次并提供更多的抽象，但如果你知道你在用数据库做什么，那么你应该没问题。就我个人而言，我会在共享代码方面犯错，因为它会减少错误，简化开发并加快发布速度。
我同意马丁。如果你是只有写一个桌面应用程序，我会说与核心数据。既然你在做这两件事情，试图在存储模型之间进行转换时出现问题的可能性实际上是指向桌面和手机使用FMDB。
代码共享是好的，但取决于模型和模型控制器类的相似程度，您可能不想完全折扣核心数据。例如，除了对象持久化之外，您还可以“免费”获得非常好的撤消/重做支持。你可能想要做一个快速的原型来判断你可能最终在两个应用程序之间重写的代码。
您可能还想调查OmniGroup中的OmniDataObjects框架。它在OS X和iPhone OS上的SQLite之上实现了CoreData功能的一个子集。我相信他们在OmniFocus的OS X和iPhone版本中都使用它。
核心数据的优点是它是一个持久存在于SQLite（或二进制或XML或自定义）数据存储的对象图管理框架。因此，它管理对象之间的单个对象实例和双向（包括对多）关系的错误（包括根据这些关系传播或拒绝删除的几个选项），以及验证对单个对象属性和关系的约束（包括必需/可选，基数，范围等）。在OS X 10.5中，它还包含用于在模型模式之间半自动迁移数据存储的工具。
不利的一面是，它在iPhone上不可用。如果FMDB满足您的需求，您可能更容易管理单个代码库而不是两个代码库。
如果您的桌面应用程序需要Leopard，最后一个选择是使用FMDB编写NSAtomicStore子类。一个NSAtomicStore必须读取整个存储里，这样你会宽松一些的SQLite的桌面上的好处的客户，但由于数据将在iPhone共享，我猜你不会有那么多的数据无论如何。通过这种方法，您可以在客户端使用Core Data，在iPhone上使用通用数据模型/数据存储的FMDB。
我不知道你的项目涉及的是什么类型的数据，但是如果它以任何方式处理人的记录，并且记录的数量相当小，那么你也可以使用内置的地址簿（ABAddressBook类）作为数据库。
它让你添加所独有的应用程式资源（这是不是在不使用它们的其他应用程序可见），你会得到iPhone和Mac之间同步absoutely是免费的。
因此，现在可能已经完全解决了这个问题，但是对于后代，我想提一下，在iPhone OS 3.0上，核心数据在iPhone上是，如果您打算在Mac应用程序中使用它，你可以分享你的iPhone应用程序的许多工作。