Questões de .NET Framework

Scoped e ICalculoTributoService como Scoped , configurando o cliente HTTP com AddHttpClient e injetando HttpClient no serviço.

Transient e ICalculoTributoService como Scoped , mantendo um HttpClient 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 e ICalculoTributoService como Scoped , injetando o contexto singleton em serviços escopados e usando AddHttpClient para o cliente HTTP.

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

ViewState e postback como contrato central de estado e navegação.

Silverlight plug-in para intermediar eventos de UI e chamadas HTTP.

Ciclo de vida de páginas do Web Forms (Page Load/Init/PreRender) preservado no ASP.NET Core.

Pipeline do WCF com bindings SOAP para intercetar requests HTTP.

Pipeline de middlewares com Endpoint Routing, compondo autenticação, autorização, sessões, MVC/Razor Pages e APIs.

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.

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.

Preferir ValueTask/ValueTask 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.

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

Publicações self-contained, que exigem a imagem Software Development Kit (SDK) em produção, pois não executam corretamente em imagens apenas de runtime, mesmo quando incluem o runtime no publish.

Multi-stage build, que aumenta o tamanho por introduzir camadas residuais do estágio de build.

O HEALTHCHECK do Docker substitui a livenessProbe/readinessProbe do Kubernetes, tornando desnecessária a configuração de probes no nível do cluster.

Multi-stage build aliado a livenessProbe/readinessProbe do Kubernetes, reduzindo a imagem final e expondo sinais de saúde ao orquestrador.

Imagens SDK, que são recomendadas em produção por conterem ferramentas de diagnóstico e compilação just-in-time.

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.

Java compila o código-fonte para um código intermediário chamado bytecode, que é executado pela Java Virtual Machine (JVM), enquanto .NET compila suas linguagens (como C#) para a Common Intermediate Language (CIL), que é executada pelo Common Language Runtime (CLR).

A plataforma .NET compila o código diretamente para o formato nativo do sistema operacional de destino, enquanto o Java 8 sempre executa o código de forma interpretada, resultando em menor performance.

A Java Virtual Machine (JVM) é um conceito exclusivo do sistema operacional Windows, enquanto o Common Language Runtime (CLR) do .NET foi projetado desde o início para ser multiplataforma, rodando em Linux e Windows.

O ambiente de execução do Java 8 permite a utilização de diversas linguagens (como Kotlin e Scala), enquanto o ambiente .NET está restrito exclusivamente à linguagem C#.

O bytecode do Java e a CIL do .NET são funcionalmente idênticos, sendo a única diferença o nome de suas máquinas virtuais (JVM e CLR, respectivamente), que são apenas implementações concorrentes da mesma especificação técnica.