Цель: инжектить внутрь класса-сущности DBContext для доступа к данным.
Препятствие: архитектура проекта.
Допустим, есть проект
MyApp.Domain, в котором описаны сущности домена.
namespace MyApp.Domain
{
public class PlanPage
{
public Guid Id { get; set; }
}
}
namespace MyApp.Domain
{
public class PlanPageDay
{
public Guid Id { get; set; }
public Guid PlanPageId { get; set; }
}
}
Также, есть проект
MyApp.Infrastructure.EntityFramework, в котором описано отображение сущностей домена в БД. В нем есть также следующий класс.
namespace MyApp.Infrastructure.EntityFramework.Models
{
public class PlanPageEntity : PlanPage
{
private readonly ApplicationDbContext _applicationDbContext;
protected PlanPageEntity(ApplicationDbContext applicationDbContext)
{
_applicationDbContext = applicationDbContext;
}
public ICollection<PlanPageDay>? Days { get; set; }
public async Task<ICollection<PlanPageDay>> GetDays()
{
return Days ??= await _applicationDbContext.PlanPageDays
.Where(pd => pd.PlanPageId == Id)
.ToListAsync();
}
}
}
Цель примера: вынести реализацию загрузки связанных сущностей в неблокирующие методы и сохранить separation of concerns, которым мы обмазываемся в проекте.
Вопрос: возможно ли сконфигурировать Entity framework так, чтобы приведённый ниже код заработал корректно?
// Код создания сущности-агрегата где-то в доменной логике
var plan = new PlanPage(/*аргументы конструктора*/);
// Код запроса сущности из БД.
public async Task<PlanPage> GetPlanPage(Guid id)
{
return await _applicationDbContext.Set<PlanPageEntity>().FindAsync(id);
}
Обратите внимание, что у Entity Framework'а запрашивается дочерний расширяющий класс, в который, по замыслу, будет предоставлен DBContext и который реализует все кишки доступа к связанным данным.