EFCore, репозитории и частные поля ⇐ C#

[Anonymous]

Мне не нравятся репозитории в EfCore, потому что EfCore сам по себе является репозиторием. НО. У меня возникла интересная проблема.
Я пытаюсь больше использовать DDD (это не означает, что мое приложение - DDD, а скорее то, что я медленно перехожу на сторону DDD). ).
Сначала у меня возник вопрос — стоит ли разделить модель предметной области и модель базы данных? Но EfCore также является картографом. Таким образом, он СОПРЯЖАЕТ саму модель предметной области с моделью базы данных. Хорошо, я придерживаюсь одной доменной модели.
Потом появилось что-то новое. Допустим, у нас есть система, которая связывает учеников с учителями. У многих учеников может быть много учителей.
Итак, у меня есть модели:

Код: Выделить всё

class Student
{
public Guid Id { get; set; }
public string Name { get; set; }
public ICollection _studentsTeachers = [];
public IEnumerable Teachers => _studentsTeachers.Where(x => x.IsActive).Select(x.Teacher)

public void AddTeacher(Teacher t)
{
...
}

public void RemoveTeacher(Teacher t)
{
...
}
}

Теперь мне нужно сохранить связь «многие ко многим», поэтому есть поле _studentsTeachers. Но я не хочу, чтобы его использовали на улице. Я хочу, чтобы свойство Teachers использовалось снаружи. Однако AddTeacher и RemoveTeacher работают с полем _studentTeachers.
Теперь у меня есть модель StudentTeacher:

Код: Выделить всё

class StudentTeacher
{
public Guid Id { get; set; }

public Guid StudentId { get; set; }
public Student Student { get; set; }

public Guid TeacherId { get; set; }
public Teacher Teacher { get; set; }

public bool IsActive { get; set; }
}

Итак, это всего лишь совместный объект с полезной нагрузкой — IsActive. Как вы можете видеть в моей модели «Студент», в свойстве «Учителя» выбраны только активные учителя.
Я не показываю модель «Учитель», потому что это на самом деле не важно.
Все работает отлично. Но есть два... "но".
Первое - конфигурация efcore сущности Student:

Код: Выделить всё

public override void Configure(EntityTypeBuilder builder)
{
//other properties

builder.Ignore(x => x.Teachers);
builder.HasMany("_studentsTeachers")
.WithMany();
}

Как видите, мне нужно ввести имя поля в виде чистой строки. Ладно, возможно, это еще не так ужасно. Но тогда, когда я хочу включить в запрос учителей:

Код: Выделить всё

var query = _dbContext.Students
.Include(x => EF.Property(x, "_studentsTeachers"))
.ThenInclude(x => x.Teacher);

Ну, я не думаю, что это красивый код. Честно говоря, я думаю, что это довольно ужасно.
Поэтому я подумал, что, возможно, мне следует создать модель базы данных только для этого объекта и использовать:

Код: Выделить всё

class StudentDbEntity: Student
{
public List StudentsTeachers { get; set; } = new();
}

и тогда я смогу настроить его вот так:

Код: Выделить всё

public override void Configure(EntityTypeBuilder builder)
{
//other properties

builder.Ignore(x => x.Teachers);
builder.HasMany(x => x.StudentTeachers)
.WithMany();
}

и тогда я смогу включить его в чистом виде:

Код: Выделить всё

 var query = _dbContext.Students
.Include(x => x.StudentsTeachers)
.ThenInclude(x => x.Teacher);

Но я не хочу использовать этот объект базы данных в своей системе, поэтому мне нужно создать РЕПОЗИТОРИЙ для этого объекта, например:

Код: Выделить всё

class StudentRepository(AppDbContext _dbContext)
{
public async Task GetStudent(Guid id)
{
var query = _dbContext.Students
.Include(x => x.StudentsTeachers)
.ThenInclude(x => x.Teacher)
.Where(x => x.Id == id);

var entity = await query.SingleOrDefaultAsync();
return (Student)entity;
}
}

Я считаю, что это действительно чисто, но думаю, что над этим нужно много работать. Потому что я не хочу иметь репозиторий только для одного объекта. Поэтому мне следует создать репозитории для остальных сущностей.
Поэтому и спрашиваю — какой путь вы бы предпочли? Вы видите много кода с такими именами полей, напечатанными в виде строк? Будете ли вы определенно использовать решение с репозиториями, зная, что EfCore сам по себе является репозиторием?

Подробнее здесь: https://stackoverflow.com/questions/793 ... ate-fields