ADO.NET Entity Framework: Puis-je avoir plusieurs types d'entités pour la même ligne?

Question

J'ai une classe de base Participants hérités par Artist, Author et TextWriter. Je n'ai qu'une seule table dans le magasin de données: participants { ID, FirstName, LastName, IsArtist, IsAuthor, IsTextWriter, } L'idée est d'avoir une classe pour tous les rôles qu'un participant peut avoir.

J'ai réussi à créer le fichier edmx mais lorsque je tente d'obtenir un participant (comme Artiste) qui est aussi un auteur que je reçois l'erreur suivante:

All objects in the EntitySet 'Participants' must have unique primary keys. However, an instance of type 'Artist' and an instance of type 'Author' both have the same primary key value, 'EntitySet=Participants;ID=1'.

Merci

Answer 1

Oui , c'est possible. Ce que vous demandez est "table per hierarchy" héritage. Votre table doit contenir une "colonne discriminante" qui identifie le type de chaque ligne.

Cependant, aucun enregistrement pour une personne ne peut avoir plus d'un type concret lorsqu'il est matérialisé (lu dans la base de données), car un objet ne peut avoir qu'un seul 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.

Si « Bob » est un Participant qui est à la fois un artiste et un auteur, il ne peut pas être de type, disons, Artist et Author en même temps, à moins que l'on est un super-type de l'autre . L'artiste et l'auteur doivent avoir une relation de sous-type avec l'autre ou vous devez utiliser l'agrégation plutôt que l'héritage pour associer Participant avec Artist et Author. Une instance d'un objet ne peut avoir qu'un seul type concret; cela ne change pas parce que vous le stockez dans la base de données.