J'essaie d'utiliser une classe commune d'entitéPeConfiguration pour configurer la clé primaire de toutes mes entités, de sorte que chaque classe de configuration dérivée ne se répète pas. Toutes mes entités implémentent une interface commune Ientity (qui dit que chaque entité doit avoir une propriété d'identification de type INT).
Ma classe de base de configuration ressemble à ceci: p> Chaque entité a alors sa propre classe de configuration spécifique extension celle-ci comme celle-ci: p> public interface IEntity {
int Id { get; set; }
}
public class Customer : IEntity {
public virtual int Id { get; set; }
public virtual string name { get; set; }
}
4 Réponses :
Je ne pense pas que vous devez traverser tout cela. EF 4.1 Le code utilise d'abord beaucoup de convention sur la configuration et via ceci, la propriété ID d'une entité est configurée comme clé primaire. Donc, en mettant en œuvre l'interface Ientity sur vos entités, vous les configurez avec l'identifiant comme clé primaire.
Voici un lien vers le blog de l'équipe Ado.net qui explique comment fonctionne la convention clé principale - Conventions pour le code d'abord
Oui, c'est vrai, mais personnellement, je n'aime pas la comptoir sur les conventions et, dans la mesure du possible, je souhaite avoir une configuration explicite, auto-documentant et sous contrôle de version. Tôt ou tard, quelque chose peut ne pas s'intégrer dans les conventions afin que ces problèmes soient résolvables à l'avant. Il existe également une configuration partagée non indiquée dans cet exemple simplifié que je ne suis pas sûr que la Convention s'occupera automatiquement.
"Je n'aime pas la comptage sur les conventions" - puis écrivez un test et il échouera lorsque la Convention change, documentant le fait (en code ou autrement) est une approche de moins que idéale
On dirait que ces configurations ont un problème d'interface. Cela fonctionne si vous modifiez Ientity à entitybase :
Eh bien, j'ai essayé de convertir les interfaces en classes abstraites, et cela ne fonctionne toujours pas. J'ai ensuite fait les classes de base non abstraites, et ça ne marche toujours pas! J'ai maintenant commencé à répéter la configuration jusqu'à (un jour?) Le logiciel de prise en charge de l'équipe de cadre d'entité utilisant des interfaces avec le code - premier (que je penserais était une exigence de base moi-même).
Cela a fonctionné pour moi avec une classe de base, donc il doit y avoir un autre problème.
Bien que cela fonctionne pour moi, je préférerais plutôt utiliser une interface. Espérons que EF soutiendra cela à l'avenir.
@LADISLAVMRNKA: +1 J'ai eu un problème similaire avec le même message d'erreur sur VS2010 EF4.4 lorsque vous essayez d'appliquer une configuration Rowversion via une interface commune. Dès que j'ai changé Ientity à entitybase Ça a fonctionné. Cela a fonctionné à la bonne voie, alors; Utilisation d'une classe normale comme classe de base où le Rowversion est simplement hérité ou une classe abstraite à l'aide d'une substitution sur le orthversion . Pitié L'approche d'interface ne fonctionne pas.
Vous pouvez simplement créer une méthode statique sur une classe et transmettre l'entité. Par exemple:
J'ai un problème similaire avec EF5.0 lorsque j'ai une classe abstraite générique avec une propriété d'identification et une implémentation pour les membres abstraits et les propriétés autonomes. ressemble au code-cadre d'entité d'abord ne cherche que des propriétés de la classe mappée. J'ai essayé d'utiliser le réflecteur - semble que je suis juste, mais je ne suis pas sûr de cela pour 100%.
et, heureusement, ont trouvé une solution pour cela: Donc, dans mon cas: pour mapper également les propriétés de la classe de base, je dois ajouter une ligne de code M.MapinheritedProperties () ...
Je vote pour fermer cette question car il s'agit d'un candidat à la libération et d'une version obsolète.