Właśnie przetestowane w projekcie nowego VS2010 (EFv4), aby upewnić się, i oto co znalazłem:
Gdy tabela asocjacyjna w środku (Company_Product) ma tylko 2 kluczy obcych do innych tabel (CompanyID i ProductID), a następnie dodanie wszystkich 3 tabel do projektanta kończy modelowanie wielu do wielu relacji. Nie generuje nawet klasy dla tabeli Company_Product. Każda firma ma kolekcję Produktów, a każdy Produkt ma kolekcję Firm.
Jeśli jednak Twoja tablica asocjacyjna (Company_Product) ma inne pola (takie jak SKU, własny klucz podstawowy lub inne opisowe pola, takie jak daty, opisy itp.), Wówczas modelarz EF utworzy oddzielną klasę, a robi to, co już widziałeś.
Posiadanie klasy w środku z relacjami 1: * do firmy i produktu nie jest złą rzeczą, a wciąż możesz uzyskać żądane dane za pomocą łatwych zapytań.
// Get all products for Company with ID = 1
var q =
from compProd in context.Company_Product
where compProd.CompanyID == 1
select compProd.Product;
To prawda, że nie jest tak łatwo poruszać się po prostu relacje modelu, kiedy masz już załadowana jednostka obiektów, na przykład, ale to, co jest dla warstwy danych. Uwzględnij zapytania, które uzyskają pożądane dane. Jeśli naprawdę chcesz pozbyć się tej średniej klasy Company_Product i mieć wiele-do-wielu bezpośrednio reprezentowanych w modelu klasy, to musisz rozebrać tabelę Company_Product tak, aby zawierał tylko 2 klucze zagraniczne i pozbyć się ich. SKU.
Właściwie nie powinienem mówić, że MUSISZ to zrobić ... Możliwe, że będziesz w stanie dokonać pewnych zmian w projektancie i tak skonfigurować to w ten sposób. Spróbuję i zgłoś się.
UPDATE
Utrzymanie SKU w tabeli Company_Product (czyli mój model EF miał 3 klasy, a nie 2; stworzył klasę Company_Payload, z 1: * dla pozostałych 2 stoły), próbowałem aby dodać powiązanie bezpośrednio między firmą a produktem.Etapy I obserwowani byli:
- prawym przyciskiem myszy na klasy Spółki w projektancie
- Dodaj> Stowarzyszenie
- Ustaw „End” na lewo, aby być firmą (powinien być już)
- Set „Koniec” w sprawie prawa do produktu
- zmienić zarówno krotności na „* (wiele)”
- właściwości nawigacyjne powinny być nazywane „produkty” i „Spółkami”
- wciśnij OK.
- prawym przyciskiem myszy na połączeniu w modelu> kliknij „tablica odwzorowań”
- W sekcji „Dodaj tabelę lub widok” wybrać „Company_Product”
- Mapa Firma -> ID (po lewej) do CompanyID (po prawej)
- Mapa Produkty -> ID (po lewej) do IDProduktu (po prawej)
Ale to nie działa. Daje ten błąd: Błąd 3025: Problem z odwzorowaniem fragmentów rozpoczynających się od wiersza 175: Należy określić mapowanie dla wszystkich kluczowych właściwości (Company_Product.SKU) tabeli Company_Product.
To konkretne powiązanie jest nieprawidłowe, ponieważ używa Company_Product jako tabeli, ale nie mapuje pola SKU na nic.
Ponadto, podczas badania tego, natrafiłem na tę "najlepszą praktykę" z książki Entity Framework 4.0 Recipies (zauważ, że dla tabeli asocjacyjnej z dodatkowymi polami, oprócz 2 FK, odnoszą się one do dodatkowych pól jako "ładunek" W twoim przypadku SKU jest ładunkiem w Company_Product).
Best Practice
Unfortunately, a project that starts out with several, payload-free, many-to-many relationships often ends up with several, payload-rich, many-to-many relationships. Refactoring a model, especially late in the development cycle, to accommodate payloads in the many-to-many relationships can be tedious. Not only are additional entities introduced, but the queries and navigation patterns through the relationships change as well. Some developers argue that every many-to-many relationship should start off with some payload, typically a synthetic key, so the inevitable addition of more payload has significantly less impact on the project.
So here's the best practice. If you have a payload-free, many-to-many relationship and you think there is some chance that it may change over time to include a payload, start with an extra identity column in the link table. When you import the tables into your model, you will get two one-to-many relationships, which means the code you write and the model you have will be ready for any number of additional payload columns that come along as the project matures. The cost of an additional integer identity column is usually a pretty small price to pay to keep the model more flexible.
(Z rozdziału 2. Podmiotowi modelowania danych, 2.4. Podstawy modelowania wiele do wielu relacji z Payload)
Brzmi jak dobra rada. Zwłaszcza, że masz już ładunek (SKU).
Wszystko wygląda dobrze ... Powinieneś mieć 3 elementy w swoim modelu: Firma, Produkt i Company_Product. "Nie ma sposobu uzyskania dostępu do SKU bezpośrednio z modelu" wypróbowałeś ctx.Company_Products.First(). SKU? –