Entity Framework Core ForeignKey Стандартные соглашения

Question

Я ищу документ [ForeignKey] соглашений. Я нашел список соглашений об именах на MSDN .

Я не уверен, какое соглашение отображает действие ниже.

class Student
{
    public int id{ set; get;}

    public int myclassroomid{ set; get;}

    public Classroom myclassroom{ set; get;}
}

class Classroom
{
    [Key]
    public int cid{ set; get;}
}

Я не понимаю, как работает соглашение по умолчанию.

Я нашел NavigationPropertyNameForeignKeyDiscoveryConvention , похоже, этот сценарий не применяется.

где я могу найти официальный документ? объясните некоторые основные моменты, если они есть, было бы лучше с примером кода.

Answer 1

Вы смотрите в неправильных местах - все это для EF6, в то время как EF Core - совершенно другая система, поэтому отправной точкой должна быть официальная документация здесь Entity Framework Core .

Условные обозначения Foregn Key описаны в Отношения - Условные обозначения , в частности:

Если зависимый объект содержит свойство с именем, совпадающим с одним из этих шаблонов, он будет настроен как внешний ключ:

• <navigation property name><principal key property name>
• <navigation property name>Id
• <principal entity name><principal key property name>
• <principal entity name>Id

В вашем примере myclassroomid соответствует правилу # 2 - имя свойства навигации "myclassroom" + "Id". Это явно не упоминается, но при сопоставлении регистр не учитывается, поэтому «Id» также соответствует «ID», «id» и т. Д. c.

Answer 2

NavigationPropertyNameForeignKeyDiscoveryConvention описывает, как свойство навигации в Student находит FK, объявленный в Student. AFAIK, он не будет рассматривать что-либо настроенное в сущности Classroom.

Он будет использовать тип и ссылочное имя, поэтому будет искать ClassroomId или MyClassroomId. Это часто приводит к тому, что люди, которые хотят использовать несколько ссылок на одну и ту же сущность, имеют одно свойство навигации, соответствующее имени типа. Т.е. CustomerId / Customer Customer и CreatedById / Customer CreatedBy. EF может попытаться преобразовать CreatedBy в CustomerId в зависимости от типа.

Само свойство навигации объединит ссылку на любое поле, объявленное как PK в типе класса. Удаление атрибута [Key] в cId в классе не будет работать, поскольку это не соответствует правилам PK. (Id или ClassroomId) Это также не учитывает FK, то есть размещение столбца cId в Student, скорее всего, не будет отображаться на ссылку MyClassroom.

Лично я всегда использую явное отображение для отношений, и я избегаю объявлять свойства FK, вместо этого отдавая предпочтение свойствам теней / Map(). Если вы собираетесь использовать соглашения, то ваша схема должна быть настроена на их соответствие без особых случаев. Самое простое и удобочитаемое - использовать {TableName} + Id для ссылок на PK и FK. Исключением являются множественные ссылки на одну и ту же таблицу / сущность, затем используются описательные имена для ссылок и связанных с ними FK. Т.е. CreatedBy + CreatedById и OrderingCustomer + OrderingCustomerId вместо Customer + CustomerId, если оба свойства навигации должны были указывать на сущность Customer.