EDMX table association avec champ

Version imprimable

14/06/2010, 11h00
mbibim63

EDMX table association avec champ

Bonjour,

je travaille sur un projet avec Oracle et je voudrais générer mes entités à l'aide de T4. Mon problème est que je ne dispose pas d'outils de mapping entre ma BDD Oracle et mon fichier EDMX. Du coup, je reconstruis mon modèle de données à la main dans mon fichier EDMX.

Je suis confronté à un cas particuliers pour lequel je n'arrive pas trouver la façon de le représenter dans mon fichier EDMX : j'ai une table d'association en BDD qui représente une liaison m..n et cette table contient donc une clé primaire double en plus un champ spécifique à chaque liaison.

Comment représenter cette table d'association dans mon fichier EDMX ?

Mon soucis est que lorsque je créé mes liaisons 1..n dans mon fichier EDMX entre ma table d'association est mes deux tables connexes, les champs créés dans ma table d'association sont des NAVIGATION PROPERTIES. Ils ne peuvent par conséquent pas devenir ma double clé primaire dans cette table d'association !! Et si je n'ai pas de clé primaire, je ne peux pas générer mes entités à mon template TT !!!

J'espère avoir été clair ... et j'espère que vous allez m'aider à solutionner ce problème.

Merci d'avance :)
14/06/2010, 16h22
cinemania

Sans disposer de connecteurs supportant l'entity framework entre Oracle et ton applicatif, je pense, mais je peux me tromper, que développer avec EF est une pure perte de temps.

Aux dernières nouvelles (bien que ça commence a faire un moment que j'ai pas regardé), mais bon ca évolue tellement, il n'y a pas de Connecteur Dotnet-Oracle "viable" au sens supportant intégralement Linq To SQL ou mieux Entity Framework (Linq To Entities) qui soit gratuit, et mêmes les payants sont loin d'être au point...
La plupart proposes des ersatz de gestion EF, le problème c'est qu'un ersatz ça ne suffit pas et pas de gestion du tout fait le même effet.

La seule raison qui fait que MySQL par exemple possède son connecteur avec une gestion complète de EF, est que ce connecteur a été écrit avant le rachat de MySQL par Oracle.
Peut être que ça les décidera finalement à sortir un connecteur EF Compliant avec leur DB mais bon, à part racheter le code des autres Oracle visiblement ne sais pas faire grand chose... c'est du moins le cas actuellement. Il est loin le temps où c'était une société dynamique :)

Nota si tu trouve un connecteur qui intègre EF, tu peux tout à fait générer ton schéma EF depuis la base de données. Les outils de bases s'appuie sur ces connecteurs. Toute la question est d'en trouver un bon...
D'ailleurs si quelqu'un en a un gratuit qui supporte pleinement EF il serait sympa de le faire partager.
17/06/2010, 17h37
B.AF
Citation:

Envoyé par mbibim63

Bonjour,

je travaille sur un projet avec Oracle et je voudrais générer mes entités à l'aide de T4. Mon problème est que je ne dispose pas d'outils de mapping entre ma BDD Oracle et mon fichier EDMX. Du coup, je reconstruis mon modèle de données à la main dans mon fichier EDMX.

Je suis confronté à un cas particuliers pour lequel je n'arrive pas trouver la façon de le représenter dans mon fichier EDMX : j'ai une table d'association en BDD qui représente une liaison m..n et cette table contient donc une clé primaire double en plus un champ spécifique à chaque liaison.

Comment représenter cette table d'association dans mon fichier EDMX ?

Mon soucis est que lorsque je créé mes liaisons 1..n dans mon fichier EDMX entre ma table d'association est mes deux tables connexes, les champs créés dans ma table d'association sont des NAVIGATION PROPERTIES. Ils ne peuvent par conséquent pas devenir ma double clé primaire dans cette table d'association !! Et si je n'ai pas de clé primaire, je ne peux pas générer mes entités à mon template TT !!!

J'espère avoir été clair ... et j'espère que vous allez m'aider à solutionner ce problème.

Merci d'avance :)

La solution c'est de changer ton modéle relationnel.
En fait l'histoire à montré que les ORM et les clefs non synthétiques cohabitent mal.

Il faut vraiment en passer par là. Avec n'importe quel ORM ce sera un cauchemard, puisque l'ensemble des générateurs considérerons que les élements de clef sont des entités, donc il faudra faire du ghost tout le temps, avec des perfs pas terribles.

D'une maniére générale, c'est une mauvaise idée dans l'usage d'un ORM d'utilisé 1 à n entités comme membres de la clef d'un entité.

En fait tu réimplementes en objet la contrainte du relationnel qui ne sait pas gérer cela. Donc c'est une espéce d'anti pattern pas terrible.

Baisquement :
Code:

1 2 3 4 5 6 7 8 9 10 11 class aclass { public List<bclass> nrelation {get;set;} } class bclass { public List<aclass> mrelation {get;set;} }
CQFD : L'objet sait faire, pas le relationel.