我有一组相关项目都将使用相同的核心数据模型。一个用于输入数据的OS X应用程序，将导出到另一个将充当服务器的OS X应用程序，以及将充当客户端的iOS应用程序。每个客户端都将维护自己的本地存储，服务器上的更改将通过MOCDidSave发送给客户端：通过本地网络上的TCP。
我想在所有项目/目标/应用程序的整个开发过程中共享一个模型和一组生成器生成的NSManagedObject子类。
我已经研究过使用Workspace并使用具有多个目标的单个项目。我还看了Marcus Zarra用来添加他的Core Data第二版中开发的iOS应用程序的桌面版本的解决方案。我确信还有其他方法可以实现这一点，但我不熟悉创建静态库或框架，我不确定这是解决这个问题的正确方法。
有关如何最好地完成此任务的任何建议？或者，至少有一些关于权衡取舍的想法？
感谢。
布拉德
答案 0 :(得分：0)
这并不困难。
基本上将所有与CoreData相关的类和模型保存在可以添加到CoreData项目的分离文件夹系统中。
我过去曾尝试过使用一个独立的数据堆栈对象层，即激活持久存储协调器，持久存储和托管对象上下文，可以在iOS或OS X上实例化，但它会粘一次你开始使用NSPersistentDocument，所以最后我只是构建堆栈，并以最有效的方式为每个平台指向公共模型和MOGenerated类。
编辑
OP提到这是一个B2B应用程序，并且他们不会使用'NSDocument'/'NSPersistentDocument'来处理OS X端的事情，所以Container Object可能是一个不错的选择。它的职责是管理和实例化CoreData堆栈。 它将以这样的方式编写，即它在OS X和iOS上编译。因此，要启动数据层，您只需要实例化对象并请求managedObjectContext。
查看this blog by Florien Kugler了解一些潜在的内部设置方法
<强>优点
您的应用使用公共数据层和CoreData附带的所有免费内容
<强>缺点
除非你使用包装文件，否则沙盒会让你在操作系统X上感到很痛苦，除非你不打算通过MAS进行操作
NSPersistentDocument不支持开箱即用的包装文件。有几个人制作了适配器。检查GitHub。但也许你不打算走那条路。
版本。确保您的模型在部署之前尽可能正确，因为任何数据模型更改都会强制对所有客户端进行强制升级。尽管托管对象模型的更改非常简单，但在部署到客户时，它们确实会有一定的交叉。添加额外未使用的字段以供将来扩展。
基本上确定你是否真的希望使用CoreData。之前已经说过但我会解释--CoreData不是关系型数据库，它是fopen（）的时髦版本。
一种可能的方法是在App中使用CoreData作为填充工作层，但是将存储保存为磁盘上的简单JSON层，因此如果模型需要在未来的某个时刻进行根本改变，那么您就不会冒着油炸的风险你的客户数据。
总结。想想CoreData是否适合您的应用及其长期前景。它可能现在很好，但是2年后你可能会发现自己陷入了地狱。