Tworzenie relacji encji z polami o zmienionej nazwie i kluczem podstawowym w tabeli podstawowej

Question

Poniżej przedstawiono dwie tabele częściowe, w których próbuję zdefiniować relację klucza obcego.

public class Form 
{ 
    [Key, Column("FormID")] 
    public System.Guid FormGUID { get; set; } 

    [Column("PatGUID")] 
    public Nullable<System.Guid> PatientGUID { get; set; } 
} 

public class Patient 
{ 
    [Column("PatGUID")] 
    public System.Guid PatientGUID { get; set; } 

    [Key, Column("PatID")] 
    public int PatientID { get; set; } 

}

Mam wyeliminować wszystkie ale stosowne informacje, pola, nawigacje, itp dla tego przykładu; mam nadzieję, że nie za dużo.

Mamy formularz tabeli, z FK z PatGUID do tabeli pacjenta z polem PatGUID. Tabela pacjenta zawiera pole int KEY PatID.

Mamy wymagania, aby zmienić nazwy naszych pól dla naszych kodów pierwszych modeli encji; odpowiednie pola w tym przykładzie wymagające zmiany to PatGUID zmienione na PatientGUID.

Trudność, którą mam, próbuje zdefiniować ten klucz obcy przy użyciu adnotacji lub płynności.

więc końcowy wynik jest mi potrzebne:

• Primary Key Tabela: Pacjent, Pole: PatGUID (przemianowany PatientGUID)

• Foreign Key Tabela: Formularz, Pole: PatGUID (zmieniono nazwę PatientGUID)

Nie wygląda to na to, że powinien stanowić duży problem, ale połączenie Patient.PatGUID nie jest kluczem podstawowym, a zmienione nazwy PatGUID zmienione na PatientGUID nie umożliwiły usłudze danych WCF prawidłowego utworzenia odniesienia z odpowiednim odwołaniem, a zatem Prawidłowa select/join od:

SELECT … FROM [dbo].[Form] AS [Extent1] 
INNER JOIN [dbo].[Patient] AS [Extent2] ON [Extent1].[PatGUID] = [Extent2].[PatGUID] 

Answer 1

EF nie obsługuje jeszcze relacje gdzie klucz głównego zobowiązanego nie jest kluczem podstawowym, ale jakaś inna kolumna z unikalnym ograniczenie klucza. Jest to on the feature request list, ale ani zaimplementowane, ani na mapie drogowej dla następnej wersji (EF 6). Jeśli zostanie w ogóle zaimplementowany (prawdopodobnie w wersji EF 7), należy poczekać rok lub dłużej, aż będzie gotowy do produkcji.

w danym modelu EF nie rozpoznaje żadnego związku między Form i Patient w ogóle, ponieważ Patient.PatientID jest oznaczony jako [Key], nie Patient.PatientGUID i EF traktuje Form.PatientGUID jako zwykły własności skalarnego, a nie jako FK do Patient.

Teoretycznie można sfałszować Patient.PatientGUID jako właściwość [Key] w modelu, mimo że nie jest to klucz podstawowy w bazie danych, jeśli nie tworzy się modelu z bazy danych lub bazy danych z modelu pierwszego kodu, czyli , jeśli ręcznie mapujesz model i (istniejącą) bazę danych. Ale nie jestem pewien, czy nie spowoduje to subtelnych problemów w innym miejscu.

Alternatywą jest napisanie instrukcji instrukcji join w LINQ, jeśli chcesz pobrać Patients i powiązane Forms. Następnie można łączyć dwie jednostki przy użyciu dowolnych właściwości, a nie tylko kluczowych właściwości.Jest to, moim zdaniem, czystsze i mniej "podchwytliwe" podejście. Jednak wadą jest to, że nie będziesz mieć właściwości nawigacyjnych - referencji lub kolekcji - między Patient i Form i nie możesz korzystać z takich funkcji, jak rozładowane ładowanie (Include), leniwego ładowania lub wygodnej "składanej ścieżki z kropkami" (np. Form.Patient.SomePatientProperty, itp. .) w zapytaniach LINQ.