Analista em Computação/Ênfase em Programação de Sistemas na Tecnologia Microsoft
Em uma interface de programação de aplicações (API) ASP.NET Core com Entity Framework Core (EF Core) em produção, deseja-se evitar concorrência indevida e dependência cativa envolvendo DbContext. Qual é a adequada configuração de lifetimes?
ADbContext Scoped (por requisição Hypertext Transfer Protocol - HTTP) e repositórios também Scoped, garantindo instância isolada por request e evitando capturar serviços de vida curta em serviços de vida longa.
BRegistrar DbContext como Singleton por ser "thread-safe" e maximizar cache de primeiro nível, mantendo uma única instância global que "aproveita" o pool de conexões como parte do próprio contexto.
CDbContext Transient com repositórios Singleton, usando repositórios como ponto central estável enquanto o contexto é recriado a cada injeção.
DDbContext Singleton e ILogger Scoped, "equilibrando" persistência do contexto com logs por requisição, assumindo compartilhamento seguro de estado entre threads.
EDbContext Scoped e loggers Transient "para capturar contexto por chamada", partindo da premissa de que loggers devem variar de instância a cada log e que scopes não são suportados por logging Singleton.
Revelar gabarito e comentário▾
GabaritoA — DbContext Scoped (por requisição Hypertext Transfer Protocol - HTTP) e repositórios também Scoped, garantindo instância isolada por request e evitando capturar serviços de vida curta em serviços de vida longa.
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
Injeção de Dependência e DbContext no ASP.NET Core
Gabarito: letra A. O DbContext do EF Core deve ser registrado com ciclo de vida Scoped (por requisição HTTP) para garantir isolamento entre requisições e evitar concorrência indevida. Repositórios que dependem do DbContext também devem ser Scoped, evitando capturar serviços de vida curta em serviços de vida longa (dependência cativa). Essa é a prática recomendada pela documentação oficial do .NET e do EF Core.
A banca testa o conhecimento sobre os três ciclos de vida do container de DI (Singleton, Scoped, Transient) e sua aplicação correta ao DbContext, que não é thread-safe. A alternativa A é a única que alinha a teoria com a prática segura.
NÃO CAIA NESSA!
A alternativa B (Singleton) é a armadilha clássica. Muitos candidatos confiam no falso senso de “performance” de uma instância única global, mas o DbContext foi projetado para ser usado como unidade de trabalho por requisição. Uma instância Singleton causaria erros de concorrência e corrupção de dados, pois o EF Core não sincroniza o estado entre threads. A banca explora essa confusão recorrente entre desenvolvedores.
Ciclo de Vida
DbContext
Repositórios
Consequência
A (correta)
Scoped
Scoped
Isolamento por requisição; evita concorrência e dependência cativa
B
Singleton
(implícito Singleton)
Concorrência indevida; corrupção de estado; não thread-safe
C
Transient
Singleton
Dependência cativa (DbContext curto preso em repositório longo); overhead
D
Singleton
Scoped (ILogger)
DbContext não thread-safe; incompatibilidade de lifetimes
E
Scoped
Transient (loggers)
Loggers Transient não capturam escopo; premissa incorreta sobre logging
DbContext no ASP.NET Core
1Ciclo de vida correto
Scoped (por requisição HTTP)
Isolamento entre requisições
Evita concorrência indevida
2Repositórios
Scoped (mesmo ciclo)
Dependência cativa (Singleton)
3Ciclos incorretos
Singleton (não thread-safe)
Transient (overhead desnecessário)
LEVEL · soulevel.com.br
Alternativa A — ✅ Correta ⟵ GABARITO
Afirma que DbContext e repositórios devem ser Scoped, ou seja, uma instância por requisição HTTP. Isso isola completamente o contexto entre requisições simultâneas, evita dependência cativa (serviço de vida curta preso em um de vida longa) e respeita a natureza não thread-safe do DbContext. É o padrão consagrado em aplicações ASP.NET Core com EF Core.
Alternativa B — ❌ Incorreta
Propõe DbContext como Singleton. O DbContextnão é thread-safe: múltiplas threads (requisições) compartilhando a mesma instância causariam concorrência indevida, resultados incorretos e exceções. O cache de primeiro nível (ChangeTracker) ficaria corrompido. Singleton é contraindicado para qualquer objeto que mantenha estado mutável e não seja thread-safe.
Alternativa C — ❌ Incorreta
Sugere DbContextTransient e repositórios Singleton. A cada injeção, uma nova instância de DbContext seria criada, gerando overhead desnecessário de criação e descarte (abertura/fechamento de conexões). Além disso, repositórios Singleton capturariam instâncias Transient, criando dependência cativa: os repositórios manteriam referências a objetos que deveriam ser descartados, causando vazamento de memória e comportamento imprevisível.
Alternativa D — ❌ Incorreta
Mantém DbContextSingleton e coloca ILogger como Scoped. O problema central (DbContext Singleton) persiste: a instância única global continua sujeita a erros de concorrência. A troca do logger não mitiga o risco principal. Além disso, a afirmação de que o compartilhamento de estado entre threads é “assumido como seguro” é falsa — não há garantia de segurança.
Alternativa E — ❌ Incorreta
Define DbContextScoped (correto), mas sugere loggers Transient com a justificativa incorreta de que “scopes não são suportados por logging Singleton”. Na verdade, o ILogger padrão do .NET (via ILogger<T>) já é registrado como Singleton e funciona perfeitamente dentro de escopos, pois não mantém estado por requisição. A alegação sobre Transient para loggers não resolve nenhum problema de concorrência com DbContext e introduz complexidade desnecessária.
PEGA ESSA DICA!
Decore os três lifetimes e suas aplicações típicas:
Singleton: serviços sem estado ou com estado compartilhado thread-safe (ex: configurações, cache imutável).
Scoped: por requisição HTTP — ideal para DbContext, Unit of Work, repositórios que acessam banco.
Transient: serviços leves e sem estado compartilhado (ex: helpers de formatação).
Para DbContext, sempre Scoped, nunca Singleton ou Transient. Isso cai recorrentemente em provas de .NET.