Widziałem ten komentarz na MSDN (link i link): „Zauważ, że niezależne stowarzyszenia powinny być unikane, ponieważ często takie rzeczy jak N-Tier i współbieżności staje się trudniejsze”Niezależne stowarzyszenia EF4 - Dlaczego ich unikać?
Jestem nowy na EF4 i buduję aplikację internetową n-Tier. To brzmi jak ważna pułapka. Czy ktoś może mi wyjaśnić, co to oznacza?
Myślę, że to osobiste preferencje. Oryginalnie EF został stworzony, aby używać tylko indep. stowarzyszeń i dostosowane do bardziej klasycznego podejścia ERM. Jednak większość z nas jest tak bardzo zależna od FK, że uczyniła życie bardzo skomplikowanym. Tak więc MS dało nam FK w EF4, co oznaczało nie tylko posiadanie FK jako własności w jednostce zależnej, ale relacje są zdefiniowane przez ograniczenia w modelu koncepcyjnym, a nie pochowane w mapowaniach. Nadal istnieje kilka relacji, które można zdefiniować tylko z powiązaniem indep: wiele do wielu i unikalnych kluczy obcych. Zauważ, że jeśli planujesz korzystać z usług RIA (nie brzmi tak), że RIA rozpoznaje tylko skojarzenia FK.
Jeśli wolisz wykorzystać niezależne skojarzenia, nadal możesz używać ich w EF4. Są całkowicie wspierane. Ale, jak sugeruje James, jest jeszcze kilka pułapek, które będą świadome ... rzeczy, które będziesz musiał robić bardziej wyraźnie, ze względu na sposób, w jaki EF pracuje z wykresami. Lub taki przypadek, w którym po prostu chcesz tego FK, np. Masz identyfikator klienta, ale nie masz takiej instancji. Możesz utworzyć zamówienie, ale bez tej przyjemnej własności CustomerID FK, musisz zrobić dodatkowe żonglowanie, aby uzyskać tam identyfikator klienta.
hth
Jeśli jesteś nowicjuszem w EF i zaczynasz od EF4, łatwą odpowiedzią jest zignorowanie tego - prawie na pewno będziesz używał zagranicznych związków kluczy zamiast niezależnych stowarzyszeń.
Zagadnienie klucza obcego jest obsługiwane przez relację klucza obcego w bazie danych, a relacja ta jest wyraźnie opisana w modelu koncepcyjnym. Ten rodzaj stowarzyszeń jest nowy dla EF4 i rozumiem, że jest to ustępstwo po problemach, które ludzie mieli z Independent Associations.
Bezwzględnie, jeśli chcesz oddzielić schemat przechowywania od schematu pojęciowego (który jest rodzajem punktu EF), nie chcesz, aby twój schemat pojęciowy wiedział o takich rzeczach jak klucze obce, ponieważ są to bazy danych (np.) koncepcja. Wcześniejsze wersje EF zastosowały to podejście i mamy to coś zwane Niezależnym Stowarzyszeniem.
Pomyśl o stowarzyszeniach niezależnych jako stowarzyszeniach śledzonych przez EF bez znajomości podstawowego klucza obcego. EF nadal to popiera, ale ma poważne słabości.
EF4 w VS2010 użyje Twoich kluczy obcych i utworzy relacje klucza obcego, chyba że powiesz inaczej. Na ogół te prace, jak można się spodziewać. Nadal istnieją pewne getchy - np. wokół kaskadowych usunięć.
Jeśli chcesz dowiedzieć EF - mogę polecić tę książkę:
http://learnentityframework.com/learnentityframework/
Wszystko, co chcesz wiedzieć, bardzo jasno wyjaśnione.
Okeedoke. Ale co konkretnie są problemy spowodowane n-warstw i współbieżności? – anon
Główną różnicą, poza różnicą w schemacie, jest to, że obiekt z niezależnym powiązaniem nie wystawia klucza obcego w warstwie koncepcyjnej. Związek jest utrzymywany w oddzielnym obiekcie. W zależności od tego, jak projektujesz aplikację, przekazywanie tej dodatkowej informacji między warstwami jest bardziej skomplikowane. Zagraniczne powiązania kluczy są o wiele łatwiejsze w obsłudze, ponieważ można ustawić klucz obcy bezpośrednio na jednostce - lub zmodyfikować odsłonięty zestaw powiązanych podmiotów/jednostek. –
"Mniej łatwa praca" w moim umyśle niekoniecznie oznacza "unikanie". To ostatnie sugeruje, że istnieją konkretne pułapki. Czy są jakieś artykuły na temat tych pułapek? (Mam książkę Julii Lerman, BTW.) – anon