Configuré mi DbContext (EF Core 5.0) con el siguiente código:
protected override void OnModelCreating(ModelBuilder modelBuilder) { modelBuilder.Entity<User>() .HasMany(p => p.Roles) .WithMany(p => p.Users) .UsingEntity<Dictionary<string, object>>("UsersToRoles", x => x.HasOne<Role>().WithMany().HasForeignKey("UserId"), x => x.HasOne<User>().WithMany().HasForeignKey("UserId"), x => x.ToTable("UsersToRoles")); modelBuilder.Entity<Role>() .ToTable("Roles") .Property(r => r.Application) .IsRequired(); base.OnModelCreating(modelBuilder); } La cuestión es que no me gustaría que la entidad Role contenga una colección de Users . Lo guardo porque EF Core lo requiere para configurar la relación de muchos a muchos.
¿Hay alguna manera de crear la misma relación, pero sin tener que definir la propiedad de navegación Role.Users ?
La respuesta corta es: lo que está preguntando se desea, pero aún no se admite, como se indica claramente (aunque no se enfatiza lo suficiente, pero a nadie le gusta resaltar las limitaciones) al comienzo de la sección actual Muchos a muchos del EF oficial. Documentación básica (el énfasis es mío):
Las relaciones de muchos a muchos requieren una propiedad de navegación de colección en ambos lados .
También al final del elemento de seguimiento original Propiedades de navegación de muchos a muchos (omitir) # 19003 , puede ver básicamente la misma pregunta
Hola, hay alguna forma de evitar definir la propiedad para una de las entidades? p.ej
builder.HasMany(p => p.Tags).WithMany(); // notice no parameter in `WithMany`
y la respuesta del equipo es
Aún no #3864
apuntando directamente a Admitir relaciones unidireccionales de muchos a muchos a través de navegaciones en la sombra # 3864 , que es el problema abierto actual correspondiente, y parece que está programado para la versión 6.0.
En cuanto a por qué exactamente, solo los miembros del equipo pueden responder eso, pero lo más probable es que se deba a la falta habitual de tiempo suficiente para adaptar algo en el marco de tiempo limitado para entregar un lanzamiento específico. Un concepto completamente nuevo (y no completamente completo) (saltar navegaciones) que se usa para implementar la característica real, con muchas mejoras posibles como Admite navegaciones de salto de no muchos a muchos # 21673 , el en cuestión y muchos otros: usted puede ver la lista actual aquí Mejorar muchos a muchos, omitir navegaciones y propiedades del indexador #22960 . Además de las dificultades técnicas, la falta de compatibilidad con la propiedad de navegación en la sombra (aunque eso no detiene los otros tipos de relaciones que se pueden configurar incluso sin navegación en ninguno de los lados (cómo sería útil eso es otra historia)), etc.
Una nota final en caso de que esté buscando una solución alternativa/una forma de superar la limitación actual. Por lo general, me gusta ir más allá de las limitaciones de EF Core, pero aquí primero no veo un valor (personalmente miro las propiedades de navegación más como metadatos que representan una relación en las consultas LINQ en lugar de un almacenamiento), y también intento superarlo con el uso directo de API de metadatos internos, junto con el código de aspecto feo, solo condujo a diferentes excepciones de tiempo de ejecución, lo que para mí demuestra que el código actual realmente se basa en tener la navegación "inversa", y eso está restringido en muchos lugares.
Entonces, como mínimo, necesita una propiedad o campo privado de ICollection<User> Users , excluido de la serialización y configurado con fluidez
modelBuilder.Entity<User>().HasMany(e => e.Roles).WithMany("Users");y viva con el hecho de que se completará a partir de la corrección de navegación de EF Core. O mejor, vive con la propiedad de navegación pública y espera la implementación oficial de la característica.