Les propriétés de collection EntityFramework ont-elles besoin d'un setter ?

Question

L'approche habituelle pour modéliser les relations 1-n avec EntityFramwork (Code First) consiste à utiliser des propriétés de collection virtuelle comme :

class Project {
  public virtual ICollection<Remark> Remarks { get; set; }
}

class Remark {
  public virtual int ProjectId { get; set; }
  public virtual Project Project {get; set; }
}

Depuis le Remarks La collection est initialement null J'adopte l'approche suivante

  private ICollection<Remark> _remarks;
  public virtual ICollection<Remark> {
    get {
      if (_remarks == null)
        _remarks = new List<Remark>();
      return _remark;
    }
    set {
       _remarks = value;
    }
  }

afin d'utiliser le Remarks.Add sur une méthode nouvellement créée Project sans avoir besoin de définir explicitement la propriété.

Afaik EF dérive en interne de ma classe et écrase les propriétés de navigation virtuelle pour supporter le chargement paresseux.

Ma question : Dois-je définir le setter d'une propriété de collection ? EF l'exige-t-il ? J'aimerais plutôt n'exposer que le getter et laisser la classe gérer la collection en interne.

Editar En fait, je n'ai remarqué que ceci Question connexe juste après avoir posté le mien, donc peut-être que c'est juste un duplicata ...

Answer 1

Le cadre d'entités peut gérer les membres privés. Vous pouvez donner à la propriété un setter privé :

private ICollection<Remark> _remarks;
public virtual ICollection<Remark> Remarks
{
    get { return _remarks ?? (_remarks = new HashSet<Remark>()); }
    private set { _remarks = value; }
}

Vous pouvez même omettre complètement le setter.

Answer 2

D'après ce que j'ai vu, EF Core n'a pas non plus besoin d'un passeur.

Vous avez besoin virtual si vous utilisez lazy-loading. Sinon, vous pouvez également l'omettre.