为什么有人想要以编程方式创建核心数据模型？

Question

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

我是那种喜欢以编程方式编写代码的人，拒绝使用Interface Builder。但是当涉及到Core Data时，我很难弄明白为什么不使用优秀的Xcode Data Modeler工具就应该消磨时间。

由于数据模型被固定在一个给定的状态(除非你想做一些丑陋的迁移操作，这些操作可能会出错，用户会发疯，真的很生气)，我看不出以编程方式创建的数据模型有什么大的意义，因为它总是在改变它。

我错过了什么吗？

Answer 1

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

Answer 2

因此，如果您的应用程序处理的资源是动态的，就像@Andiih提到的那样，那么这个程序员是唯一的方法。直到运行时我才知道我的核心数据实体是什么，我不知道属性是什么，也不知道数据是什么样子。因此，我请求服务器提供我应该支持的资源类型以及它们的属性。我在运行时构建模型、实体、属性和关系。我仍然希望使用核心数据，因为我正在处理大量数据，并且我需要NSFetchedResultsController等高效内存管理的好处。我只能通过编程来实现。

问题是如何处理迁移，以尝试并尽可能多地保留持久存储，以便在模型更改后减少网络数据有效负载的大小。现在，如果有冲突，我会销毁整个模型和持久化存储。我还没有想出从以编程方式生成的模型创建.xcdatamodel的方法，因此我还不能创建版本映射来进行迁移。

Answer 3

每件事都是权衡的。基本上，如果您正在构建一个简单的应用程序，我认为IB和visual Core数据建模器是正确的工具。您需要确定应用程序何时变得足够大/足够复杂，以便能够直接控制代码的所有方面。

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

对于Core Data，这个问题几乎是相同的。你的项目有定义的范围吗？您能预见该作用域中的所有工作都在可视化建模器中完成吗？如果是这样的话，可能就没问题了。对于其他项目，你可能会被要求不断地添加功能，也许花更多的时间把它写出来更好，这样你以后就有更多的灵活性。

另一件需要考虑的事情是，在IB或任何混合视觉设计/代码系统中寻求帮助要困难得多，这一点没有太多提及。当出现问题或需要帮助时，发布代码比尝试解释可视化建模器中发生的事情要容易得多。