Auditor Fiscal da Receita Estadual - AFRE - Tecnologia da Informação e Comunicação - Conhecimentos Especificos (P3)
Uma Secretaria da Fazenda estadual expõe, em ASP.NET Core (.NET 8, Minimal APIs), uma API para calculo de ICMS sobre fretes interestaduais. O serviço ICalculoTributoService utiliza FazendabDbContext (EF Core) para persistência e um cliente HTTP para consultar tabelas de alíquotas interestaduais via serviço externo. Em testes de carga, o uso de FazendaDbContext e ICalculoTributoService como Singleton gerou aumento de memória e conexões abertas ao banco. Considerando o modelo de injeção de dependência e lifetimes do contêiner padrão do .NET, a combinação de lifetimes que é tecnicamente adequada para esse cenário é registrar FazendaDbContext. como
AScoped e ICalculoTributoService como Scoped, configurando o cliente HTTP com addHEttpClient e injetando HttpClient no serviço.
BTransient e ICalculoTributoService como Scoped, mantendo um HttpClient estático compartilhado em toda a aplicação.
Cscoped e ICalculoTributoService como Transient, criando instâncias de HttpClient com new HttpClient () no construtor do serviço.
Dsingleton e ICalculoTributoService como Scoped, injetando o contexto singleton em serviços escopados e usando AddHttpClient para o cliente HTTP.
ETransient e ICalculoTributoService COMO Transient, gerando um novo contexto e um novo HttpClient a cada resolução do serviço.
Revelar gabarito e comentário▾
GabaritoA — Scoped e ICalculoTributoService como Scoped, configurando o cliente HTTP com addHEttpClient e injetando HttpClient no serviço.
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 no ASP.NET Core – Lifetimes
Gabarito: Alternativa A. A combinação tecnicamente adequada é registrar tanto FazendaDbContext quanto ICalculoTributoService como Scoped, configurando o cliente HTTP com AddHttpClient e injetando HttpClient no serviço. Essa configuração respeita o ciclo de vida por requisição HTTP para o contexto (evitando concorrência e vazamento de memória) e gerencia corretamente as conexões HTTP (evitando esgotamento de portas).
A questão aborda um problema comum em aplicações ASP.NET Core: o uso inadequado de lifetimes para DbContext e HttpClient. O DbContext do Entity Framework Core não é thread-safe e deve ser registrado como Scoped (uma instância por requisição). Já o HttpClient é projetado para ser reutilizado; o método AddHttpClient (parte do pacote Microsoft.Extensions.Http) gerencia um pool de handlers, permitindo que o HttpClient seja injetado de forma segura sem criar novas conexões a cada requisição.
Abaixo, a análise de cada alternativa:
DbContext (EF Core)
1Scoped
Thread-safe por requisição
Singleton: concorrência
Transient: sobrecarga
2HttpClient
AddHttpClient (pool)
Reutiliza handlers
new HttpClient(): socket exhaustion
3Serviço (ICalculoTributoService)
Scoped
Compatível com DbContext
Transient: perde rastreamento
LEVEL · soulevel.com.br
Alternativa A — ✅ Correta ⟵ GABARITO
FazendaDbContext como Scoped: instância única por requisição, alinhado ao padrão do EF Core.
ICalculoTributoService como Scoped: dependências do serviço (DbContext e HttpClient injetado via AddHttpClient) são compatíveis com o escopo.
HttpClient injetado via AddHttpClient: a fábrica gerencia o ciclo de vida do handler, evitando socket exhaustion e garantindo que o HttpClient seja seguro.
Alternativa B — ❌ Incorreta
FazendaDbContext como Transient: cria um novo contexto a cada resolução, gerando sobrecarga de conexões e perda do rastreamento de mudanças dentro da mesma requisição. Não é recomendado para APIs.
HttpClient estático compartilhado: embora seja uma prática comum, sem o AddHttpClient pode levar a problemas de DNS stale e socket exhaustion se não houver gerenciamento adequado.
Alternativa C — ❌ Incorreta
ICalculoTributoService como Transient: cria uma nova instância do serviço a cada injeção, o que é aceitável, mas o uso de new HttpClient() no construtor é problemático – cria uma nova instância a cada resolução, descartando o handler anterior e causando degradação de performance.
AddHttpClient não é utilizado, perdendo os benefícios de reutilização de conexões.
Alternativa D — ❌ Incorreta
FazendaDbContext como Singleton: compartilhado por todas as requisições, viola a segurança de thread do DbContext, causando exceções de concorrência e vazamento de conexões – exatamente o problema descrito no enunciado.
Injetar um singleton em um serviço scoped cria uma dependência cativa (captive dependency), onde o serviço scoped usa a mesma instância do contexto, agravando o problema.
Alternativa E — ❌ Incorreta
Ambos como Transient: DbContext transient é inadequado para APIs (perde o escopo da requisição). HttpClient criado a cada resolução com new HttpClient() piora ainda mais a situação, gerando múltiplas instâncias e esgotando recursos.
Tabela Resumo dos Lifetimes
Alternativa
DbContext
Serviço
HttpClient
Adequado?
A
Scoped ✅
Scoped ✅
AddHttpClient (gerenciado) ✅
Sim
B
Transient ❌
Scoped ✅
Estático (sem AddHttpClient) ❌
Não
C
Scoped ✅
Transient ❌ (mas aceitável)
new HttpClient() ❌
Não
D
Singleton ❌
Scoped ✅
AddHttpClient ✅
Não
E
Transient ❌
Transient ❌ (aceitável)
new HttpClient() ❌
Não
Conclusão: A única alternativa que resolve os problemas de memória e conexões abertas é a letra A, respeitando as boas práticas do .NET para injeção de dependência e gerenciamento de recursos.