Domain Driven Design afferma che dovresti avere un modello di dominio, che riflette il linguaggio ubiquitario usato dagli esperti del dominio. Quando si utilizzano gli ORM e molte e molte relazioni sono abituato a fare questo:
public class Student
{
public Student()
{
this.Courses = new HashSet<Course>();
}
public int StudentId { get; set; }
[Required]
public string StudentName { get; set; }
public virtual ICollection<Course> Courses { get; set; }
}
public class Course
{
public Course()
{
this.Students = new HashSet<Student>();
}
public int CourseId { get; set; }
public string CourseName { get; set; }
public virtual ICollection<Student> Students { get; set; }
}
Tuttavia, con EF Core è necessario creare una classe di partecipazione come descritto qui: link . Nel caso di quanto sopra; Dovrei creare una classe chiamata: StudentCourse.
Qual è il modo più appropriato per mappare un ORM a un modello di dominio assumendo che non vi siano vincoli tecnici come con EF Core se al momento si deve avere una classe di join? Il mio pensiero è:
1) Se la tabella di join ha stato e comportamento, utilizzare una classe join.
2) Se la tabella di join ha un nome riconosciuto dagli esperti del dominio, utilizzare una classe join, ad es. Una persona potrebbe avere diritto a prestiti: qui l'idoneità è la classe di partecipazione ed è un termine riconosciuto dal dominio. Nel caso di quanto sopra; StudentCourse non è riconosciuto dal dominio.
3) Altrimenti non utilizzare una classe di join (come nell'esempio sopra).