核心数据实体继承->有局限性吗？

问题描述

| 我以为我会将其发布到社区。我正在使用coredata，并且有两个实体。两个实体都有层次关系。我现在注意到很多重复的功能，并且想知道是否应该重新构造以具有一个抽象的基础实体（HierarchicalObject），并使我的实体继承自它们。 所以问题是我应该考虑这种继承的一些限制吗？阅读那里的一些文章，我会看到一些折衷，请让我知道我的假设是否正确。 （良好）清理结构，将HierarchicalObject功能保持在一个位置。 （好）有了继承，两个对象现在都在同一个sqlite表中（我正在使用Sqlite作为后端）。因此，如果对象数量增加，搜索/排序可能需要更长的时间？不知道这是否很重要，因为在我的案例中，对象的数量应该保持静态。 （不太好）有了继承，关系会变得更复杂吗？ （http://www.cocoadev.com/index.pl?CoreDataInheritanceIssues） 还有其他事情要考虑吗？ 感谢您的意见。     

解决方法

我认为绘制以关闭实体和类之间的平行关系是错误的。尽管非常相似，但它们确实有一些重要差异。 最重要的区别是实体没有像类那样的代码，因此当您拥有具有重复属性的实体时，您不会增加很多额外的编码，并且可能引入错误。 许多人认为类继承必须与实体继承并行。它不是。只要一个类从NSManagedObject派生下来并响应它所代表的实体的正确键值消息，该类就可以在其继承中进行很多快乐的冒险，而这并没有反映在实体继承中。例如。在NSManagedObject下方创建自定义基类是相当普遍的，并且所有后续托管对象子类都继承自该基类，而不管它们的实体如何。 我认为，唯一需要实体继承的时间是当您需要不同的实体来显示相同​​的关系时。例如：

Owner{
  vehical<-->Vehical.owner
}

Vehical(abstract){
  owner<-->Owner.vehical
}

Motocycle:Vehical{ 

}

Car:Vehical{

}

现在，Owner.vehical可以容纳一个“ 1”对象或一个“ 2”对象。注意，

Motocycle

和

Car

的托管对象类继承不必相同。您可能会遇到诸如

Motocycle:TwoWheeled:NSManagedObject

和

Car:FourWheeled:NSManagedObject

之类的东西，并且一切正常。 最后，实体只是上下文的指令，告诉它对象图如何组合在一起。只要您的实体安排能够实现，您在设计细节上就具有很大的灵活性，比类的情况要灵活得多。     ,我认为值得一提的是，iOS 10上的Notes应用在其Core Data模型中使用继承。他们使用基础实体SyncingObject，该实体具有7个子实体，包括“便笺”和“文件夹”。正如您提到的，所有这些都存储在同一个SQLite表中，该表具有多达106列，并且由于在所有实体之间共享，大多数都是NULL。他们还将文件夹注释一对多关系实现为多对多关系，从而创建了数据透视表，这可能是继承问题的解决方法。 使用实体继承有几个优点，这些优点可能会超过这些存储限制。例如，唯一约束在实体之间可以是唯一的。提取请求可以返回不同的实体，从而使使用提取的结果控制器的UI更加简单，例如在侧边栏中按帐户或文件夹分组。     ,过去，对于具有继承关系的模型的数据迁移，我曾遇到过一些问题-您可能需要尝试一下，看看是否可以使其正常工作。 还要注意，所有对象都放在一个表中。 但是，由于Core Data正在管理对象图，因此保持结构的自然状态就像对对象进行建模（包括继承）一样，确实非常好。关于保持模型健全，要说的话很多，因此您在维护代码方面要做的工作更少。 我个人在自己的一个应用程序中使用了带有继承功能的相当复杂的CD模型，而且效果还不错（除了我说过的数据迁移问题外，但这对我来说实在是太难了，我不依赖在该工作了）。