Если вы посмотрите на класс EntityTypeConfiguration<TEntityType>
, вы увидите следующую подпись для определения отношения один-ко-многим (которое является вашим отношением между Team
и BirthYears
):
HasMany<TTargetEntity>(Expression<Func<TEntityType, ICollection<TTargetEntity>>>
navigationPropertyExpression) where TTargetEntity : class;
Как видите, существует ограничение where TTargetEntity : class
, которое требует, чтобы BirthYears
представлял собой коллекцию class
объектов.int
не является классом, поэтому сопоставление будет невозможно.
Единственный обходной путь, который я вижу, - это определить небольшой класс ...
public class BirthYear
{
public int Id { get; set; }
public int Value { get; set; }
}
..и затем используйте это в своей коллекции в классе Team:
public ICollection<BirthYear> BirthYears { get; set; }
Соглашения о сопоставлении должны автоматически создавать отношение один-ко-многим, так что вам не нужен Fluent API для настройкиассоциация.
Редактировать
Исправление согласно правильному критику Ладислава в комментариях:
Классу BirthYear
требуется дополнительное свойство Key.Я добавил свойство Id
.
Также я предполагаю, что BirthYears
будет свойством, зависящим от Team
.Соглашения о сопоставлении создадут необязательные отношения от BirthYear
до Team
.Я думаю, что было бы более подходящим для модели сделать это соотношение обязательным при использовании Fluent API:
modelBuilder.Entity<Team>()
.HasMany(t => t.BirthYears)
.WithRequired();
Это автоматически включит каскадное удаление - связанные года рождения будут удалены из базы данных, когда командаудалено.
Редактировать 2
(Опять на основании комментария Ладислава) Если вы не хотите копировать годы в таблице BirthYears, вы также можете установить Много-Отношение ко-многим:
modelBuilder.Entity<Team>()
.HasMany(t => t.BirthYears)
.WithMany();
Это добавит таблицу соединения (TeamBirthYears
) между Team
и BirthYear
в базу данных.С точки зрения пространства хранения или производительности вы, вероятно, ничего не выиграете (поскольку класс BirthYear
очень мал, а запись в таблице BirthYear
имеет тот же размер, что и запись в таблице соединений).Но это может быть лучшим подходом, если вы планируете расширить класс BirthYear
дополнительными свойствами рано или поздно.В противном случае я бы лично все упростил с отношениями «один ко многим».Но выбор за вами.