Questão de Programação — Frameworks em Programação — FUNDATEC 2025
Programação›Frameworks em Programação
Código
qg474996
Banca
FUNDATEC
Órgão
PROCERGS
Ano
2025
Nível
Superior
Cargo
Analista em Computação/Ênfase em Programação de Sistemas na Tecnologia Microsoft
Um relatório mensal de um órgão federal consome milhões de linhas de uma base operacional usando EF Core. Os dados são apenas leitura (sem atualização das entidades em memória) e a equipe relata alto uso de CPU e memória ao executar as consultas no pipeline de CI. Qual técnica é mais apropriada para reduzir o overhead nas consultas desse relatório?
AManter ChangeTracker.Auto DetectChangesEnabled = true para "otimizar" a verificação de mudanças mesmo em leitura.
BAplicar AsNoTracking() para evitar o change tracking quando os resultados são somente leitura.
CHabilitar EnableSensitiveDataLogging em produção para obter mais detalhes, com impacto desprezível.
DUsar Include em todas as navegações, garantindo que tudo esteja em cache no contexto.
EDesabilitar o cache do banco de dados (buffer) para ler sempre do disco e "garantir frescor".
Revelar gabarito e comentário▾
GabaritoB — Aplicar AsNoTracking() para evitar o change tracking quando os resultados são somente leitura.
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”.
Entity Framework Core – Otimização de Consultas
Gabarito: letra B. Em consultas somente leitura, o método AsNoTracking() do EF Core desabilita o rastreamento de alterações (change tracking), eliminando o overhead de CPU e memória que o contexto gasta para monitorar as entidades retornadas. As demais alternativas ou são irrelevantes ou pioram a performance.
A questão testa o conhecimento sobre o mecanismo de change tracking do Entity Framework Core e como desativá-lo quando não é necessário, prática essencial para consultas de leitura pesadas.
Alternativa A — ❌ Incorreta
Manter AutoDetectChangesEnabled = true é o comportamento padrão e faz o contexto verificar alterações em todas as entidades rastreadas a cada operação. Em consultas apenas leitura, isso é desnecessário e adiciona custo computacional. O correto é desabilitar essa detecção ou usar AsNoTracking().
Alternativa B — ✅ Correta ⟵ GABARITO
AsNoTracking() é um método de extensão de IQueryable que instrui o EF Core a não rastrear as entidades retornadas pela consulta. Como não há necessidade de atualização, o contexto não mantém referências às entidades, reduzindo significativamente o consumo de memória e CPU. É a técnica padrão recomendada para consultas de leitura pesadas.
Alternativa C — ❌ Incorreta
EnableSensitiveDataLogging é usado para logging de dados sensíveis (como valores de parâmetros) e é voltado para depuração. Em produção, além de expor dados, adiciona overhead considerável de logging, não sendo "impacto desprezível". Não resolve o problema de consumo de recursos.
Alternativa D — ❌ Incorreta
Include carrega entidades relacionadas (eager loading). Usá-lo indiscriminadamente aumenta o volume de dados retornados e o processamento, piorando a performance. Não há "cache no contexto" garantido por Include; o cache de primeiro nível (contexto) ainda pode causar retenção de memória se o tracking estiver ativo.
Alternativa E — ❌ Incorreta
Desabilitar o cache de buffer do banco de dados (SQL Server buffer pool) força todas as leituras a vir do disco, eliminando o benefício de páginas em memória. Isso degrada drasticamente a performance de consultas repetitivas. "Garantir frescor" não é relevante para um relatório mensal.
PEGA ESSA DICA!
Em consultas de leitura volumosas (relatórios, listagens), SEMPRE utilize AsNoTracking() para evitar que o contexto mantenha rastreamento desnecessário. Combine com AsSplitQuery() quando necessário para evitar explosão cartesiana em Include múltiplos. Essas são práticas fundamentais no EF Core.
Fechamento: Portanto, a alternativa correta é a letra B.