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

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

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. Таблица Patient имеет поле PatID int KEY.

У нас есть требования переименовать наши поля для наших первых моделей сущностей кода; соответствующие поля в этом примере, которые необходимо изменить, изменяются 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]

Ответы

Ответ 1

EF еще не поддерживает отношения, где главный ключ не является первичным ключом, а некоторым другим столбцом с уникальным ключевым ограничением. Это в списке запросов функций, но ни реализовано, ни дорожная карта для следующей версии (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.