我想知道在哪些情况下，完全以编程方式创建一个 NSManagedObjectModel 会更好，包括 NSEntityDescription 实例和所有这些东西。
我是那种喜欢以编程方式编写代码，拒绝 Interface Builder 的人。但是当谈到 Core Data 时，我很难弄清楚为什么我应该消磨时间而不是使用漂亮的 Xcode Data Modeler 工具。
而且由于数据模型被固定在给定的状态（除非您想做一些丑陋的迁移操作，认为可能会出错并且用户会生气，真的很生气），我认为以编程方式制作的数据模型没有太大意义为了随时改变它。
我错过了什么吗？
【问题讨论】：
我不认为你错过了什么。我可以看到以编程方式创建模型的唯一原因是，如果您正在建模的对象本身是动态的：例如，您可以构建一个 coredata 实体（或实体图）以响应随时间变化的 Web 服务，或者由用户选择。但是，我认为如果你有那个或类似的用例，你就不需要写这个问题（而且你可能会以不同的方式解决它）
【讨论】：
因此，如果您的应用程序正在处理动态资源，正如@Andiih 所提到的，那么这种程序化是唯一的方法。直到运行时我才知道我的核心数据实体是什么，我不知道属性是什么，或者数据是什么样的。所以，我要求服务器给我我应该支持的资源种类以及它们的属性是什么样的。我在运行时构建模型、实体、属性、关系。我仍然想使用 Core Data，因为我正在处理大量数据，并且我需要使用 NSFetchedResultsController 等进行高效内存管理的好处。我只能以编程方式执行此操作。
问题在于如何处理迁移以尝试保留尽可能多的持久存储，以在模型更改后减少网络数据负载的大小。现在，如果有冲突，我会炸毁整个模型和持久存储。我还没有想出从编程生成的模型创建 .xcdatamodel 的方法，因此我还不能创建版本映射来进行迁移。
【讨论】：
一切都是权衡。基本上，如果您正在构建一个简单的应用程序，我认为 IB 和可视化核心数据建模器是正确的工具。当您的应用程序变得足够大/复杂到您希望直接控制代码的所有方面时，您需要做出决定。
关于Interface Builder，如果你有一个应用程序，视图控制器之间有各种复杂的交互，以及多个自定义控件，我觉得代码更合适。
对于 Core Data，问题几乎相同。您的项目是否有明确的范围？你能预见到该范围内的所有事情都在可视化建模器中完成吗？如果是这样，它可能没问题。对于其他项目，您可能会被要求持续添加功能，也许最好多花一点时间写出来，以便以后有更大的灵活性。
另一件需要考虑的事情，没有太多提及，那就是在 IB 或任何混合视觉设计/代码系统方面寻求帮助要困难得多。当出现问题或您需要帮助时，发布代码比尝试在可视化建模器中解释发生的情况要容易得多。
【讨论】：
一般来说，没有理由在代码中构建托管对象模型。您可以在代码中做任何无法在模型编辑器中完成的事情。但是，您可以在代码中使用一些花哨的技巧来处理多个模型。例如，您可以合并两个模型，在加载时在这些模型中的实体之间建立跨模型关系（请参阅Cross-model relationships in NSManagedObjectModel from merged models?）。
关于编写代码或使用图形编辑器是否是一个好主意，我认为在这种情况下，平衡很大程度上倾向于图形编辑器。能够通过视觉检查而不是（相当复杂的）代码来验证模型是一个胜利。如果您愿意，该模型仍然可以通过单元测试进行验证。
【讨论】：
我有一个可能有效的用例，如果您从 Internet 加载一些数据，无论是来自 RSS Feed 还是 WSDL 响应的 XML，然后通过生成内存数据表将这些响应扁平化为表格，最后将它们全部混合成一个连贯的数据模型，然后您可以为内存数据表中的实体创建实体并创建主/详细信息关系。这是我认为以编程方式生成的 Core Data 数据模型可能会变得方便且强大的一种情况。
【讨论】：
我在单元测试中以编程方式更改了模型。例如，我编写了一个类，该类旨在与附加了特定协议的 Core Data 模型一起使用。我没有针对随机实现进行测试，而是通过以编程方式仅在单元测试中添加一个来改变默认模型，并针对该仅测试模型进行测试。
【讨论】：