Ахах )))
У столяра тоже нет проблем с контекстом, с базами данных, с ЯП и другими технологиями тоже нет проблем )))

Но вообще, стоит признать, DbContext это полная шляпа, если проект выходит за рамки небольшого-среднего, то начинаются проблемы, при чём по большей части архитектурные.

Да не.. многолетняя практика показывает, что EF и DbContext подходит только для небольших проектов. Ну или в доску примитивных, где ничего сложнее CRUD-а нет.

От того сколько там сущностей, 10 или 100500 вообще монопенисуально, это сути не меняет.

Если тебе маппинг нужен, то есть микро-ормы, которые решают эту задачу эффективно и гибко.

Ну погоди... Судя по тому, что ты прям категорически настаивал, что тебе не нужен DbContext в Scoped, значит ты совершенно не используешь полноценно все преимущества именно EF, как ORM. Тебе нужен тупой маппер.

Т.е. ты используешь EF, как поделку-недоорм. Какие претензии? Берёшь в таком случае более подходящий инструмент.

Какой смысл говорить, что лопата это "поделка", а надо использовать экскаватор, но при этом в другом топике ты топил за то, что каждому человеку нужно выдать по персональному экскаватору, а не использовать один на бригаду

Ты уж определись.

А там прям высшая математика, для избранных священнослужителей, прошедших курс 10-летней медитации?

https://docs.microsoft.com/en-US/aspnet/core/fundamentals/dependency-injection?view=aspnetcore-5.0#entity-framework-contexts

By default, Entity Framework contexts are added to the service container using the scoped lifetime because web app database operations are normally scoped to the client request .

И обрати внимание:

Services of a given lifetime shouldn't use a database context with a lifetime that's shorter than the service's lifetime.

Документацию стоит хоть иногда открывать :)
Ну и в исходниках, которые открыты, тоже много чего полезного можно для себя открыть.

Я конечно понимаю, фантазировать -- оно безусловно интересней, чем работать с реальностью.