List, virtual and Entity Framework

Question

In all the examples I have found about Entity framework, always use ICollection for collections of objects.

public partial class Standard
{
    public Standard()
    {
        this.Students = new HashSet<Student>();
        this.Teachers = new HashSet<Teacher>();
    }

    public int StandardId { get; set; }
    public string StandardName { get; set; }
    public string Description { get; set; }

    public virtual ICollection<Student> Students { get; set; }
    public virtual ICollection<Teacher> Teachers { get; set; }
}

public partial class Teacher
{
    public Teacher()
    {
        this.Courses = new HashSet<Course>();
    }

    public int TeacherId { get; set; }
    public string TeacherName { get; set; }
    public Nullable<int> StandardId { get; set; }
    public Nullable<int> TeacherType { get; set; }

    public virtual ICollection<Course> Courses { get; set; }

    public virtual Standard Standard { get; set; }
}

Questions:

1 Cannot work directly with the concrete type, such as List?

public partial class Standard
{
    public int StandardId { get; set; }
    public string StandardName { get; set; }
    public string Description { get; set; }

    public virtual List<Student> Students { get; set; }
    public virtual List<Teacher> Teachers { get; set; }
}

2 I also read that EF does not work with collections of primitive types. What to do in this case?

3 Because the property needs to be virtual, the EF does some modification in it?

Answer 1

Entity Framework, ORM used in architecture . NET.

Responding:

1) Yes, you can use the Concrete Type without problems List it will work just like the guys Interfaces.

Advantage in this aspect is that in the constructor I do not need to initialize this List, as is done with the interfaces (Hashset, only remembering that it starts only the interfaces ICollection<T>, IEnumerable<T>, IEnumerable, ISerializable, IDeserializationCallback, ISet<T>, IReadOnlyCollection<T>) If typed with IList will have to give a new List with your type

---

2) No, it doesn’t really work because it can’t determine the size of items in the list, it has to be dynamic so the proposed structures are Ilist, or Icollection, or Observablecollection and/or List. To maintain a pattern always use ICollection<T>.

---

3) Needs to be virtual, because the Entity Framework rewrite this item, then this modifier has this functionality used by ORM Entity Framework. It will turn fields into methods as described in this link.

Example:

//Campos
[ForeignKey("UfId")]
public virtual ICollection<Cidades> Cidades { get; set; }

I’d stay inside like this:

//Metodos
public ICollection<Cidades> get_Cidades()
{
    return _cidades;
}

public void set_Cidades(Cidades value)
{
    _cidades = value;
}

private Cidades _cidades;

The Entity Framework then creates a proxy or navigation of properties on the relationships between related entities. Without the modifier virtual it does not achieve that effect of late relationships and shipments.

References:

Why use 'virtual' for class properties in Entity Framework model Definitions?

Making a virtual Property to cause EF to load the Property