Relations multiples avec des tables de correspondance dans Entity Framework

Question

Le contexte de la question est ASP.NET MVC2/EF4. J'ai un certain nombre de tables de recherche dans la base de données qui ont été précédemment référencées par programme, chacune d'un certain nombre d'autres tables ... Donc, il peut y avoir une table de pays avec shortcode, desc, et une demi-douzaine de tables countryid en eux. Répétez l'opération pour 5 ou 6 autres tables de recherche. À l'heure actuelle, il n'y a pas de FK - la recherche a été programmatique dans l'interface utilisateur de l'ancienne interface de base de données. L'autre chose à se méfier est qu'une personne peut avoir un paysan. La personne peut être liée à un travail qui peut également avoir un pays. Le travail a un employeur avec un pays (et ainsi de suite) - c'est-à-dire que nous nous retrouvons avec un graphique assez embrouillé.

Sur la question: Je voudrais pouvoir accéder aux informations de pays dans les requêtes EF/LINQ sans jointures. Dois-je d'abord ajouter les FK multiples à la base de données? Est-ce que je ne fais que câbler les relations dans le concepteur? Quel (le cas échéant) dois-je rechercher lorsque plusieurs tables sont liées à la même table dans EF? Cela fonctionnera-t-il du tout?

Juste fondamentalement à la recherche de meilleures pratiques pour ce faire.

Answer 1

Créez d'abord le FK, mettez à jour le modèle à partir de la base de données dans le concepteur EF. Il créera automatiquement les associations entre vos entités à partir des relations FK.

Cela fonctionnera très bien. Le seul inconvénient est que EF va connecter votre graphique dans les deux sens et cela peut causer des problèmes. Par exemple, vous créez un objet Person temporaire et définissez le pays sur une entité Country existante. Si cette entité Pays fait également partie d'une autre entité qui a été modifiée dans le contexte actuel, alors lorsque vous sauvegardez des modifications, votre objet Personne temporaire peut aussi être ajouté à la base de données! La construction de graphes d'EF peut parfois devenir un peu trop enthousiaste.