是否有人想要以编程方式创建Core Data模型？

Question

我想知道在哪些情况下使用NSEntityDescription实例和所有这些东西完全以编程方式创建NSManagedObjectModel会很好。

我是那种喜欢以编程方式编码，拒绝接口生成器的人。但是当谈到Core Data时，我很难搞清楚为什么我不应该使用漂亮的Xcode Data Modeler工具来消磨我的时间。

由于数据模型停留在给定状态（除非你想做一些丑陋的迁移操作，认为可能出错并且用户生气，真的很生气），我认为在以编程方式制作的数据模型中没有什么大意义为了一直改变它。

我错过了什么吗？

Answer 1

我不认为你错过了什么。我可以看到以编程方式创建模型的唯一原因是，如果您正在建模的对象本身是动态的：您可以构建一个coredata实体（或实体图）以响应随时间变化的Web服务，或者由用户选择。但是，我认为如果你有这个或类似的用例，你就不需要写这个问题（你可能会以不同的方式解决它）

Answer 2

因此，如果您的应用程序正在处理动态资源，正如@Andiih所提到的那样，那么这种编程是唯一的方法。我不知道我的核心数据实体在运行时是什么，我不知道属性是什么，或者数据是什么样的。所以，我要求服务器给我我应该支持的各种资源以及它们的属性。我在运行时构建模型，实体，属性，关系。我仍然想使用Core Data，因为我正在处理大量数据，我需要使用NSFetchedResultsController等进行高效的内存管理。我只能以编程方式执行此操作。

问题是如何处理迁移以尽可能多地保留持久存储，以减少模型更改后网络数据有效负载的大小。现在我爆炸整个模型和持久性商店，如果有冲突。我还没有想出一种从程序生成的模型创建.xcdatamodel的方法，因此我还无法创建版本映射来进行迁移。

Answer 3

一切都是权衡。基本上，我认为如果你正在构建一个简单的应用程序，IB和可视化核心数据建模器是正确的工具。当您的应用程序变得足够大/复杂以至于您希望直接控制代码的所有方面时，您需要做出决定。

关于Interface Builder，如果您的应用程序在视图控制器和多个自定义控件之间有各种复杂的交互，我会发现代码更合适。

对于核心数据，问题几乎相同。您的项目是否有明确的范围？您是否可以预见在视觉建模器内完成该范围内的所有事情？如果是这样，它可能很好。对于其他项目，可能会要求您不断添加功能，也许最好花一点时间将其写出来，以便以后获得更多灵活性。

另外还要考虑的另一件事是，提到IB或任何混合视觉设计/代码系统的帮助要困难得多。当出现问题或需要帮助时，发布代码会比尝试解释可视化建模器中的内容更容易。

Answer 4

通常，没有理由在代码中构建托管对象模型。在代码中无法在模型编辑器中完成任何操作。但是，您可以在代码中使用一些花哨的技巧来处理多个模型。例如，您可以合并两个模型，在加载时在这些模型中的实体之间建立跨模型关系（请参阅Cross-model relationships in NSManagedObjectModel from merged models?）。

关于编码或使用图形编辑器是否是一个好主意，我认为在这种情况下，平衡会对图形编辑器产生很大影响。能够通过视觉检查而不是（相当复杂的）代码来验证模型是一种胜利。如果您愿意，该模型仍可通过单元测试进行验证。

Answer 5

我有一个可能有效的用例，如果你从互联网加载一些数据，无论它是来自RSS Feed还是WSDL响应的XML，然后将这些响应压缩成表格，从生成内存数据表，最后将所有内容混合到一个连贯的数据模型中，然后您可以为内存数据表中的实体创建实体并创建主/明细关系。这就是我认为以编程方式生成的核心数据数据模型可以变得方便且功能强大的一种情况。

Answer 6

我在单元测试中以编程方式更改了模型。例如，我编写了一个类，用于处理附加了特定协议的Core Data模型。我没有对随机实现进行测试，而是通过以编程方式在单元测试中添加一个来改变默认模型，并针对该仅测试模型进行测试。