核心数据实体继承 -->限制？

Question

我想我会把这个发布到社区。我正在使用 coredata，并且有两个实体。两个实体都具有层级关系。我现在注意到有很多重复的功能，并且想知道是否应该重新构建一个抽象的基本实体（HierarchicalObject），并让我的实体继承它们。

所以问题是我应该考虑这种继承的一些限制吗？阅读了一些帖子，我看到了一些权衡，请告诉我我的假设是否正确。

1. （好）清理结构，将 HierarchicalObject 功能保留在一处。
2. （好的）通过继承，两个对象现在最终都在同一个 sqlite 表中（我使用 Sqlite 作为后端）。那么如果对象数量增加，搜索/排序可能需要更长的时间？不确定这是否是一个大问题，因为我的例子中的对象数量应该保持相当静态。
3. （不太好）有了继承，关系会变得更复杂吗？ (http://www.cocoadev.com/index.pl?CoreDataInheritanceIssues)

有吗还有其他需要考虑的事情吗？

感谢您的评论。

Answer 1

我认为将实体和类进行比较是错误的。虽然非常相似，但它们确实存在一些重要的差异。

最重要的区别是实体没有像类那样的代码，因此当您拥有具有重复属性的实体时，您不会添加大量额外的编码和引入错误的可能性。

很多人认为类继承必须与实体继承并行。事实并非如此。只要一个类从 NSManagedObject 派生并响应它所代表的实体的正确键值消息，该类就可以在其继承中拥有许多快乐的冒险，而这些冒险并没有反映在实体继承中。例如，在 NSManagedObject 下面创建一个自定义基类是相当常见的，并且所有后续的托管对象子类都继承自该基类，而不管它们的实体如何。

我认为唯一绝对需要实体继承的时候是当您需要不同的实体出现在同一关系中时。例如：

Owner{
  vehical<-->Vehical.owner
}

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

Motocycle:Vehical{ 

}

Car:Vehical{

}

现在 Owner.vehical 可以容纳 Motocycle 对象或 Car 对象。请注意，Motocycle 和 Car 的托管对象类继承不必相同。您可以拥有诸如 Motocycle:TwoWheeled:NSManagedObject 和 Car:FourWheeled:NSManagedObject 之类的东西，一切都会正常工作。

最后，实体只是上下文的指令，告诉它对象图如何组合在一起。只要您的实体安排能够实现这一点，您在设计细节上就有很大的灵活性，比类的类似情况下的灵活性要大得多。

Answer 2

我认为提及 iOS 10 上的 Notes 应用程序在其核心数据模型中使用继承会很有用。他们使用一个基本实体SyncingObject，该实体有7个子实体，包括Note和Folder。正如您所提到的，所有这些都存储在同一个 SQLite 表中，该表有多达 106 列，并且由于在所有实体之间共享，所以大多数都是 NULL。他们还将文件夹注释一对多关系实现为多对多关系，从而创建数据透视表，这可能是解决继承问题的方法。

使用实体继承有几个优点，可能会超越这些存储限制。例如，唯一约束在实体之间可以是唯一的。对父实体的提取请求可以返回多个子实体，从而使使用提取结果控制器的 UI 更加简单，例如按侧边栏中的帐户或文件夹进行分组。 Notes 使用此在文件夹行上方显示“所有注释”行，该行实际上是帐户子实体。

Answer 3

我过去在继承模型的数据迁移方面遇到过问题 - 您可能想尝试一下，看看是否可以让它工作。

正如您还指出的那样，所有对象都放在一张表中。

然而，由于 Core Data 正在管理对象图，因此以自然方式建模对象（包括继承）的方式保持结构确实很好。为了保持模型的健全，有很多话要说，这样您就可以减少维护代码的工作。

我个人在我自己的一个应用程序中使用了一个相当复杂的带有继承的 CD 模型，并且效果很好（除了我所说的数据迁移问题，但这对我来说一般来说太不稳定了，我不依赖不再继续工作）。