Questões de Concurso sobre ASP .NET

scoped e ICalculoTributosBervice como Scoped, configurando o cliente HTTP com AddpgttpClient e injetando HttpClient no serviço.

Transient e ICalculoTributoService como Scoped, mantendo um HHpClient estático compartilhado em toda a aplicação.

scoped e ICalculoTributoservice como Transient, criando instâncias de HttpClient com new HttpClient () no construtor do serviço.

singleton & ICalculeTributoservice como scoped, injetando o contexto singleton em serviços escopados e usando AddHttpClient para o cliente HTTP.

Transient é ICalculoTributoservice como Transient, gerando um novo contexto e um novo HttpClient a cada resolução do serviço.

Certo

Errado

Preferir ValueTask/ValueTask<T> em todos os métodos para reduzir alocações; quando o método apenas “dispara e esquece”, usar async void para simplificar.

Reservar async void apenas para manipuladores de eventos; para métodos de serviço/repositório, retornar Task/Task<T>.

await não bloqueia, mas em ASP.NET Core o contexto é sempre recapturado; por isso, ConfigureAwait(false) é obrigatório para evitar deadlocks.

Para não “segurar” a thread de requisição, envolver todo I/O em Task.Run e retornar void quando não houver resultado.

Retornar Task quando houver resultado e async void quando não houver, já que o chamador não precisa aguardar.

A ordem dos middlewares é sempre irrelevante por definição da plataforma, pois o runtime intercepta uniformemente exceções, autenticação, compressão e roteamento independentemente da posição no pipeline.

UseDeveloperExceptionPage em produção para máxima visibilidade com stack trace ao usuário final.

ILogger <T> não é thread-safe, exigindo implementação própria para concorrência.

Não há suporte a logging estruturado, sendo necessário serializar objetos manualmente.

UseExceptionHandler configurado no topo do pipeline e logging estruturado com scopes/identificadores de correlação (Correlation IDs), preservando contexto por requisição.

Páginas HTML estáticas com CSS inline e lógica em stored procedures, reduzindo camadas de aplicação.

Windows Forms hospedado no navegador via WebView, preservando event handlers no servidor.

Silverlight e componentes AJAX legados, reaproveitando a lógica de UI existente.

Portabilidade direta do código Web Forms (System.Web, postbacks e view state) para o runtime do .NET 6.

ASP.NET Core MVC ou Razor Pages, usando modelos, ações/handlers e visões com DI, routing e validação do pipeline moderno.

ASP.NET Web Forms e WCF (hospedando serviços) não são suportados nativamente em .NET Core/.NET 5+, exigindo rearquitetura.

O .NET Framework possui suporte limitado a bibliotecas de terceiros, o que inviabiliza a compatibilidade com .NET Core.

Aplicações .NET Framework não executam em Windows, sendo obrigatório portar antes para Linux.

O .NET Core não possui garbage collector, o que impede migração de serviços de longa duração.

O .NET Framework é sempre mais lento que .NET Core em aplicações web, e por isso a migração é essencialmente um ganho de desempenho garantido.

Manter a aplicação em .NET Framework e usar WCF para criar a API.

Replicar o banco de dados e criar uma nova API em Java.

Criar a API usando Web Forms, que é uma tecnologia robusta do .NET Framework.

Usar o .NET Framework para criar uma API SOAP, pois é mais seguro.

Migrar a lógica de negócio para uma nova API desenvolvida com ASP.NET Core (.NET 6+), garantindo desempenho e compatibilidade multiplataforma.

Uma nova instância é criada para cada controlador ou Razor Page que solicita o serviço.

Uma nova instância é criada a cada solicitação do serviço no contêiner de injeção de dependência.

Uma única instância é criada e mantida para toda a vida útil da aplicação.

Uma única instância do serviço é criada e mantida entre diferentes requisições que utilizam a mesma thread até que a aplicação termine a execução.

Uma nova instância é criada para cada requisição HTTP, sendo compartilhada entre os componentes no mesmo escopo da requisição.

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.

Registrar 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.

DbContext Transient com repositórios Singleton, usando repositórios como ponto central estável enquanto o contexto é recriado a cada injeção.

DbContext Singleton e ILogger Scoped, “equilibrando” persistência do contexto com logs por requisição, assumindo compartilhamento seguro de estado entre threads.

DbContext 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.

Em ações POST, o vinculador prioriza a query string; o corpo fica reservado a upload de arquivos. Para ler JSON, é preciso anotar tudo.

Com [ApiController], todo parâmetro sem atributo (inclusive os simples) é lido do corpo; valores de rota e query só funcionam quando duplicados com [FromRoute] e [FromQuery].

O atributo [FromBody] é obrigatório sempre que houver JSON; sem ele, tipos complexos e simples vêm como default, a menos que estejam em minimal APIs.

Em [ApiController], por padrão tipos complexos que não são resolvidos via injeção de dependência vêm do corpo (JSON), enquanto tipos simples são inferidos da rota e/ou da query string.

Métodos GET aceitam corpo por padrão; portanto, mesmo sem atributos, a inferência também será do corpo nesses casos.

Xamarin

Mono

UWP

.NET 5+

.Net Framework

Manter ProcessingService e EmailSender como Singleton, trocando IOptionsSnapshot por IOptionsSnapshot (inalterado) e guardando um IServiceProvider interno para criar AppDbContext sob demanda; seguir com HttpClient direto e property injection em EmailSender.

Tornar tudo Transient para evitar estado compartilhado; injetar HttpClient estático por desempenho; manter Service Locator no controlador porque “flexibiliza” a resolução.

Usar injeção por construtor em todas as classes; registrar ProcessingService como Scoped; substituir HttpClient por IHttpClientFactory; usar IOptionsMonitor em singletons e IOptionsSnapshot apenas no escopo da requisição; no SyncWorker, criar um escopo por iteração com IServiceScopeFactory e resolver serviços Scoped dentro dele; em cenários de background que precisam de EF, preferir IDbContextFactory<AppDbContext>; remover property injection obrigatória e o Service Locator do controlador.

Promover AppDbContext a Singleton para casar com ProcessingService singleton; substituir IOptionsSnapshot por valores lidos de IConfiguration diretamente; manter HttpClient direto e injetar o ProcessingService no SyncWorker sem criação de escopos.

Trocar ProcessingService para Scoped, mas manter IOptionsSnapshot dentro de EmailSender Singleton; continuar com Service Locator apenas nos controladores e usar HttpClient direto, pois o AddHttpClient já foi chamado.

Uma nova instância do serviço é criada a cada vez que ele é solicitado.

A mesma instância do serviço é usada para todas as requisições durante todo o ciclo de vida da aplicação.

O serviço é criado apenas em ambiente de desenvolvimento.

O serviço é otimizado para operações de longa duração em background.

A mesma instância do serviço é criada por requisição HTTP, mas compartilhada entre diferentes componentes dentro dessa mesma requisição.

Java

C++

Python

ASP

o uso exclusivo de bancos de dados relacionais.

a dependência de um servidor web específico, como o IIS.

o suporte para o desenvolvimento de aplicações apenas para Windows.

a possibilidade de criar aplicativos web de maneira cross-platform e modular.

a integração exclusiva com a linguagem C#.

não oferece suporte para hospedagem de serviços RPC.

Razor é um framework front-end baseado em componentes que suporta renderização do lado do servidor e interatividade do cliente em um único modelo de programação.

o ASP.NET 4.x possui desempenho superior ao ASP.NET Core.

a classe HttpRequest encapsula informações sobre a solicitação HTTP de entrada e permite somente leitura.

é possível implementar Injeção de dependência no ASP.NET Core registrando a dependência em um contêiner de serviço interno, o IServiceProvider.

exige a criação manual de SQL para todas as operações de banco de dados.

é restrito ao uso com bancos de dados SQL Server apenas.

suporta o desenvolvimento de aplicações utilizando o padrão de Design MVC (Model-View-Controller).

oferece suporte para mapeamento objeto-relacional e permite interagir com bancos de dados usando objetos .NET.

não permite a realização de consultas complexas e avançadas sobre os dados.

Assembly.

C#.

Lua.

R.

Swift.

corresponde ao código HTML final, completo, gerado como resposta a uma chamada a essa página.

fica armazenada no servidor, por padrão, sendo que cada sessão ativa contém um valor específico.

é um valor booleano que determina se cada requisição à página deve ser processada no servidor em modo de depuração, provendo informações extras sobre a execução do código quando ativada.

corresponde a um dicionário que contém pares chave/valor, sendo colocado em um campo oculto (hidden) da página.

armazena código Java que pode ser executado dentro do ambiente ASP.NET no servidor, permitindo a integração entre essas duas tecnologias.

possuir gerenciamento de memória superior ao PHP;

utilizar programação por script no lado cliente;

gerar páginas web estáticas;

criar páginas de alta performance;

ter acesso limitado por alguns navegadores.