web-dev-qa-db-fra.com

EF relations un-à-plusieurs de base HasOne (). WithMany () vs HasMany (). WithOne ()

Disons que j'ai les 2 modèles suivants:

public class Blog
{
    public int BlogId { get; set; }
    public string Url { get; set; }

    public List<Post> Posts { get; set; }
}

public class Post
{
    public int PostId { get; set; }
    public string Title { get; set; }
    public string Content { get; set; }

    public Blog Blog { get; set; }
}

Maintenant, si je veux configurer les relations des modèles dans DbContext, y a-t-il une différence entre:

modelBuilder.Entity<Post>()
            .HasOne(p => p.Blog)
            .WithMany(b => b.Posts);

et

modelBuilder.Entity<Blog>()
            .HasMany(b => b.Posts)
            .WithOne(p => p.blog);

et s'il y a une différence, c'est quoi? dois-je écrire les deux ou juste l'un d'eux?

En remarque: Dois-je définir des clés étrangères? Sur la base de mes connaissances sur les bases de données, vous ne pouvez pas créer de relations sans clés étrangères, mais EF ne vous oblige pas à avoir des champs de clé étrangère. Alors, comment EF gère-t-il les relations sans connaître les clés étrangères? Cela provoque-t-il des baisses de performances ou des bugs?

c#entity-frameworkasp.net-core
19
soorena12

Vous avez raison, vous pouvez créer des relations dans DbContext sans clés étrangères dans la base de données.

Également:

WithOne: Les relations un à un ont une propriété de navigation de référence des deux côtés. Ils suivent les mêmes conventions que les relations un-à-plusieurs, mais un index unique est introduit sur la propriété de clé étrangère pour garantir qu'une seule personne à charge est liée à chaque principal.

Plusieurs-à-plusieurs: les relations sans classe d'entité pour représenter la table de jointure ne sont pas encore prises en charge. Cependant, vous pouvez représenter une relation plusieurs-à-plusieurs en incluant une classe d'entité pour la table de jointure et en mappant deux relations un-à-plusieurs distinctes.

Vous n'avez besoin de définir qu'une seule relation, car dans certains cas, vous allez créer une relation parent-enfant sans propriétés de navigation (une ou collection).

Pour votre exemple: vous ajoutez une relation pour Blog -> Posts car vous avez des propriétés de navigation dans les deux objets, les deux lignes se ressemblent mais de manière différente:

  • Blog -> Messages (Parent -> enfant)
  • Articles -> Blog (Enfant -> Parent)
10
H. Herzl

Vous pouvez définir vos modèles sans propriété de clé étrangère. Cependant, Entity Framework introduira une propriété fantôme, qui sera dans la base de données.

Selon la documentation :

Bien qu'il soit recommandé de définir une propriété de clé étrangère dans la classe d'entité dépendante, elle n'est pas obligatoire. Si aucune propriété de clé étrangère n'est trouvée, une propriété de clé étrangère fantôme sera introduite avec le nom <navigation property name><principal key property name> (voir Propriétés de l'ombre pour plus d'informations).

2
Knelis