Questões de Concurso sobre ASP .NET

Utiliza o ADO.NET para evitar o uso direto de SQL.

Contém o Blazor, um framework para UI web interativa usando JavaScript ao invés de C#.

Sua arquitetura tem como características a junção de responsabilidades e alto acoplamento.

Faz o mapeamento Objeto-Relacional com o Entity Framework, permitindo a manipulação de dados por meio de objetos.

Utiliza o Razor Pages como alternativa ao MVC (Model-View-Controller), onde cada página tem UI própria, porém, sem lógica associada.

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.

Segue rigidamente a separação em camadas proposta pelo padrão MVC, exigindo a definição explícita de controllers para cada requisição.

Baseia-se em consultas declarativas com LINQ como mecanismo central de organização da lógica de aplicação e navegação entre páginas.

Implementa, de forma obrigatória, o padrão de APIs RESTful, sendo utilizado exclusivamente para exposição de serviços e manipulação de dados via HTTP.

Restringe a interação com outras camadas da aplicação, limitando seu uso à renderização estática de conteúdo sem acesso a serviços ou dados dinâmicos.

Adota uma abordagem orientada a páginas, na qual cada unidade de interface encapsula sua lógica associada, reduzindo a necessidade de separação explícita em controllers.

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.

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.

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.

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.