ADO.NET 实体框架：同一行可以有多个实体类型吗

发布于 2024-08-28 21:23:52 字数 364 浏览 5 评论 0原文

我有一个由 Artist、Author 和 TextWriter 继承的基类 Participant。我的数据存储中只有一张表：参与者{ ID，名，姓，是艺术家, 是作者，是文本编写者， } 这个想法是为参与者可以拥有的所有角色创建一个类。

我已成功创建 edmx 文件，但当我尝试获取同时也是作者的参与者（作为艺术家）时，我收到以下错误：

EntitySet“参与者”中的所有对象都必须具有唯一的主键。但是，“Artist”类型的实例和“Author”类型的实例都具有相同的主键值“EntitySet=Participants;ID=1”。

谢谢

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

夕嗳→ 2024-09-04 21:23:52

是的，这是可能的。您要求的是“每个层次结构的表”继承。您的表需要包含标识每行类型的任何“鉴别器列”。

然而，一个人的记录在具体化（从数据库中读取）时不能有多个具体类型，因为一个对象只能有一种类型。我之前写过有关此问题的文章：

在设计良好的对象关系映射时，您必须克服的心理障碍之一是主要以面向对象的术语或关系术语进行思考，无论哪种都适合您的个性。然而，良好的对象关系映射包含良好的对象模型和良好的关系模型。例如，假设您有一个数据库，其中包含人员表以及员工和客户的相关表。一个人可能在所有三个表中都有一条记录。现在，从严格关系的角度来看，您可以为员工构建一个数据库 VIEW，为客户构建另一个数据库 VIEW，这两个数据库都包含 People 表中的信息。当使用一个视图或另一个视图时，您可以暂时将某个人视为“只是”员工或“只是”客户，即使您知道他们都是。因此，来自这种世界观的人可能会想做一个 OO 映射，其中 Employee 和 Customer 都是 Person 的（直接）子类。但这不适用于我们现有的数据；由于单个人同时拥有员工和客户记录（并且由于没有任何 Person 实例可以同时属于具体子类型 Employee 和 Customer），因此 Person 和 Employee 之间的 OO 关系需要是组合而不是继承，对于 Person 和 Customer 也是如此。

如果“Bob”是既是艺术家又是作者的参与者，那么他不能是以下类型，例如艺术家 和作者同时，除非一个是另一个的超类型。艺术家和作者中的任何一个都应该与另一个具有子类型关系，或者您应该使用聚合而不是继承来将 Participant 与 Artist 和 Author 相关联。对象的实例只能有一种具体类型；这不会改变，因为您将其存储到数据库中。

Yes, this is possible. What you're asking for is "table per hierarchy" inheritance. Your table needs to contain any "discriminator column" which identifies the type of each row.

However, no record for one person can have more than one concrete type when materialized (read from the DB), because an object can only have one type. I've written about this issue before:

One of the mental barriers that you have to get over when designing a good object relational mapping is the tendency to think primarily in object oriented terms, or relational terms, whichever suits your personality. A good object relational mapping, though, incorporates both a good object model and a good relational model. For example, let’s say you have a database with a table for People, and related tables for Employees and Customers. A single person might have a record in all three tables. Now, from a strictly relational point of view, you could construct a database VIEW for employees and another one for customers, both of which incorporate information from the People table. When using a one VIEW or the other, you can temporarily think of an individual person as "just" an Employee or "just" a Customer, even though you know that they are both. So someone coming from this worldview might be tempted to do an OO mapping where Employee and Customer are both (direct) subclasses of Person. But this doesn’t work with the data we have; since a single person has both employee and customer records (and since no Person instance can be of the concrete subtype Employee and Customer simultaneously), the OO relationship between Person and Employee needs to be composition rather than inheritance, and similarly for Person and Customer.

If "Bob" is a Participant who is both an Artist and an Author, then he cannot be of type, say, Artist and Author at the same time, unless one is a supertype of the other. Either Artist and Author should have a subtype relationship with the other or you should use aggregation rather than inheritance to relate Participant with Artist and Author. An instance of an object can have only one concrete type; this does not change because you store it to the DB.

回复收藏 0 原文

~没有更多了~