Entités de structure d'entité de moulage dans la direction «incorrecte»

Question

J'utilise Entity Framework et possède une structure d'héritage avec une entité de base (appelons-la Customer) et une entité dérivée, appelons-la AccountCustomer. La différence est qu'un AccountCustomer a des détails supplémentaires (tels que les termes de paiement, etc.) stockés dans une table séparée dans la base de données et donc des propriétés supplémentaires dans l'Entité.

Je souhaite autoriser les utilisateurs à «promouvoir» un client spécifique en tant que client de compte. Je dois garder la même clé primaire (une clé composite visible par les utilisateurs et utilisée comme référence client). Pour le moment, je pense qu'appeler une procédure stockée pour créer l'enregistrement supplémentaire dans la table des comptes est la seule façon de procéder, mais jusqu'à présent, nous n'avons pas contourné Entity Framework, donc nous préférerions éviter cette technique si possible.

Quelqu'un a-t-il des solutions axées sur Entity Framework?

Answer 1

Il s'agit de l'un de ces scénarios "Veuillez ne pas le faire".

Vous pensez strictement à cela en termes de tables, plutôt qu'en terme d'objets.

Un client particulier est un client particulier. Le genre de chose qu'il ne change jamais. Maintenant, son statut peut changer, ou il peut acquérir des propriétés de compte supplémentaires, mais il ne passe jamais d'un type de chose (client) à un autre type de chose (compte client). Cela n'a tout simplement pas de sens sur le plan conceptuel (un fruit générique ne se transforme pas en pomme, n'est-ce pas ... ça commence comme une pomme avec un statut, et finit comme une pomme avec un nouveau statut), et c'est certainement impossible dans la programmation orientée objet .NET ... ce qui le rendrait impossible dans un ORM comme EF. Alors, s'il vous plaît, réfléchissez à une manière raisonnable de conceptualiser cela, ce qui conduira à une manière sensée d'exprimer cela en termes orientés objet, ce qui conduira à une solution EF sensible.

Answer 2

J'ai résolu cela par une solution de rechange.

• charge toutes les propriétés de navigation connexes de la classe de base, elle-même, y compris

var customer = db.Customers.Include("whatever dependince you have").FirstOrDefault(u=>u.UserId == userId); // vous pouvez répéter cette opération pour tous vos comprend

• Cache les propriétés de navigation à locale variables ie var profile = customer.Profile;
• Supprimer la classe de base par db.Customer.Remove(customer);
• Création de la classe dérivée var accountCustomer = new AccountCustomer();
• Définissez toutes ses propriétés et propriétés de navigation à partir de la classe de base, c'est-à-dire

accountCustomer.UserId = customer.UserId;

accountCustomer.Profile = profile; // do the same for all of the properties and navigation properties from the base class

• Ajouter la nouvelle classe de retour à la db

this.Entry<T>(accountCustomer).State = EntityState.Added;

• Appel db.SaveChanges()

C'est tout!