Создание отношения сущностей с переименованными полями и непервичным ключом в первичной таблице

Question

Ниже приведены две частичные таблицы, в которых я пытаюсь определить отношение внешнего ключа.

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; } 

}

я устранил все, но соответствующие информационные, поля, плавания и т.д. для этого примера; надеюсь, не слишком много.

У нас есть таблица форм, с FK от PatGUID до стола пациента с полем PatGUID. Таблица пациентов содержит поле ввода PatID.

У нас есть требования переименовать наши поля для наших первых моделей сущностей кода; соответствующие поля в этом примере нуждаются в изменении: PatGUID изменяется на PatientGUID.

Сложность, которую я испытываю, заключается в попытке определить этот внешний ключ, используя либо аннотации, либо свободно.

Таким образом, конечный результат мне нужно:

• Первичный ключ Таблица: Пациент, поле: PatGUID (переименован PatientGUID)

• Ключ иностранных Таблица: Форма, поле: PatGUID (переименован в PatientGUID)

Это не похоже на то, что это должно представлять большую проблему, но комбинация Patient.PatGUID не является первичным ключом, а поля PatGUID, переименованные в PatientGUID, не позволили службе данных WCF правильно создать ссылку с надлежащей ссылкой, таким образом, правильный выбор/джойн:

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

Answer 1

EF еще не поддерживает отношения, где ключ доверителя не является первичным ключом, а какой-то другой столбца с уникальным ключом. Это on the feature request list, но ни реализовано, ни на дорожной карте для следующего выпуска (EF 6). Если он вообще будет реализован (возможно, в EF 7), ожидайте ждать год или больше, пока он не будет готов к производству.

В вашей конкретной модели EF не признает никакого отношения между Form и Patient вообще, потому что Patient.PatientID отмечен как [Key], не Patient.PatientGUID, и EF рассматривает Form.PatientGUID как обычную скалярную собственность, а не как FK в Patient.

В теории вы можете подделать Patient.PatientGUID как свойство [Key] в модели, хотя это не первичный ключ в базе данных, если вы не создаете модель из базы данных или базы данных из кодовой модели, то есть , если вы вручную сопоставляете модель и (существующую) базу данных. Но я не уверен, что это не вызовет тонких проблем в другом месте.

Альтернативный вариант - написать инструкцию join в LINQ, если вы хотите получить Patients и связанные с ним Forms. Затем вы можете объединить два объекта, используя произвольные свойства, а не только ключевые свойства.Это, на мой взгляд, более чистый и менее «хитрый» подход. Тем не менее, недостатком является то, что у вас не будет свойств навигации - ссылок или коллекций - между Patient и Form, и вы не можете использовать такие функции, как высокая загрузка (Include), ленивая загрузка или удобный синтаксис «пунктирный путь» (например, Form.Patient.SomePatientProperty и т. Д. .) в ваших запросах LINQ.