是否有任何充分的理由为多个核心数据实体使用 NSManagedObject 子类？
可以让一个 NSManagedObject 子类代表多个 Core Data 实体。例如，类 Thing 可以表示实体 Vegetable 和 Blanket，即使数据建模为 Vegetable 和Blanket 不共享遗产。
我认为苹果工程师这样做是有合理理由的。但我认为在对多个实体使用一个类时，没有任何一种情况是有用或明智的。类到实体的一对一映射似乎是唯一的实际用例。
这个设计决定的理由是什么？
It is possible to have one NSManagedObject subclass represent multiple Core Data entities. For example the class Thing could represent the entities Vegetable and Blanket even when the data is modelled such that Vegetable and Blanket do not share heritage.
I assume that the engineers at Apple did this for a rational reason. But I cannot think of a single circumstance when using one class for multiple entities would be useful or wise. A one-to-one mapping of class to entity seems like the only practical use case.
What could the rationale be for this design decision?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我认为没有人这样做过，但只要实体具有相同的键，您就可以使用相同的 NSManagedObject 子类来表示它们。
您可以这样做，因为 NSManagedObject 本身被设计为能够使用其关联存储来表示任何实体。当您不费心子类化时，您最终会得到代表数据模型中每个不同实体的 NSManagedObject 类的实例。
NSManagedObject 子类并没有真正改变那么多。子类中定义的属性实际上只是 NSManagedObject 基类关联存储的包装器。 （这是您使用
primativeValueForKey:访问的子类。子类主要是为了提供轻松访问和数据模型本身无法提供的任何自定义行为的便利。但是，它们保留了 NSManagedObjects 的灵活性。如果您有子实体除了实体的名称之外什么都不改变，那么您可以安全地使用同一个类来表示它们，但是，如果它们在任何其他方面有所不同，那么这样做是鲁莽的。
I don't think anyone ever does it but as long as the entities have the same keys you could use the same NSManagedObject subclass to represent them.
You can do this because NSManagedObject itself is designed to be able to represent any entity using its associative storage. When you don't bother to subclass, you end up with instances of the NSManagedObject class representing each of the different entities in your data model.
NSManagedObject subclasses don't really change that much. The properties defined in the subclasses are really just wrappers around the NSManagedObject base classes associative storage. (That's the one you access with
primativeValueForKey:. The subclass are largely a convenience to provide easy access and any customized behavior the data model itself cannot provide. However, they retain NSManagedObjects flexibility.If you have subentities that change nothing but the name of the enitity, then you could safely use the same class to represent them. If they differ in any other way, however, it would be reckless to do so.