.NET 5 vs. .NET Framework para aplicativos de servidor

Artigo
05/10/2023

Há duas implementações do .NET com suporte para a criação de aplicativos do lado do servidor.

Implementação	Versões incluídas
.NET	.NET Core 1.0 – 3.1, .NET 5 e versões posteriores do .NET.
.NET Framework	.NET Framework 1.0 - 4.8

Ambas compartilham muitos dos mesmos componentes, e você pode compartilhar código entre as duas. No entanto, há diferenças fundamentais entre as duas e sua escolha depende do que você deseja realizar. Este artigo diretrizes sobre quando usar cada um.

Use o .NET Core no seu aplicativo de servidor se:

Você tiver necessidades de plataforma cruzada.
Você estiver direcionando microsserviços.
Você estiver usando contêineres do Docker.
Você precisar de alto desempenho e sistemas escalonáveis.
Você precisar de versões do .NET correspondentes a cada aplicativo.

Use o .NET Framework para o aplicativo para servidores se:

Seu aplicativo usar o .NET Framework atualmente (a recomendação é estender em vez de migrar).
Seu aplicativo usar bibliotecas de terceiros ou pacotes NuGet não disponíveis para o .NET.
Seu aplicativo usar tecnologias .NET Framework que não estão disponíveis para o .NET.
Seu aplicativo usar uma plataforma que não oferece suporte ao .NET.

Quando escolher o .NET

As seguintes seções oferecem uma explicação mais detalhada sobre os motivos mencionados anteriormente para escolher o .NET em vez do .NET Framework.

Necessidades de plataforma cruzada

Se o aplicativo Web ou aplicativo de serviço precisar ser executado em várias plataformas, por exemplo, Windows, Linux e macOS, use o .NET.

O .NET dá suporte aos sistemas operacionais mencionados anteriormente como sua estação de trabalho de desenvolvimento. O Visual Studio fornece um IDE (ambiente de desenvolvimento integrado) para Windows e macOS. Você também pode usar o Visual Studio Code, que é executado no Windows, Linux e macOS. O Visual Studio Code dá suporte ao .NET, incluindo IntelliSense e depuração. A maioria dos editores de terceiros, como Sublime, Emacs e VI, trabalham com o .NET. Esses editores de terceiros obtém o IntelliSense do editor usando o Omnisharp. Também é possível evitar o uso de editores de código e usar diretamente as ferramentas da CLI do .NET, que estão disponíveis para todas as plataformas com suporte.

Arquitetura de microsserviços

Uma arquitetura de microsserviços possibilita uma combinação de tecnologias em um limite de serviço. Essa combinação de tecnologias permite uma adoção gradual do .NET para novos microsserviços que funcionam com outros serviços ou microsserviços. Por exemplo, você pode combinar microsserviços ou serviços desenvolvidos com .NET Framework, Java, Ruby ou outras tecnologias monolíticas.

Há muitas plataformas de infraestrutura disponíveis. O Azure Service Fabric é criado para sistemas de microsserviço grandes e complexos. O Serviço de Aplicativo do Azure é uma boa escolha para microsserviços sem monitoração de estado. Alternativas de microsserviços baseadas em Docker se adaptam a qualquer abordagem de microsserviços, conforme explicado na seção Contêineres. Todas essas plataformas oferecem suporte ao .NET, e são ideais para hospedar microsserviços.

Para mais informações sobre arquitetura de microsserviços, consulte Microsserviços .NET. Arquitetura para aplicativos .NET em contêineres.

Contêineres

Os contêineres são frequentemente usados com uma arquitetura de microsserviços. Os contêineres também podem ser usados para colocar em contêiner os aplicativos ou serviços Web que seguem qualquer padrão de arquitetura. O .NET Framework pode ser usado em contêineres do Windows. Ainda assim, a modularidade e a natureza leve do .NET o tornam uma escolha melhor para contêineres. Ao criar e implantar um contêiner, o tamanho de sua imagem será muito menor com o .NET do que com o .NET Framework. Como ele é multiplataforma, é possível implantar aplicativos para servidores em contêineres do Docker do Linux.

Os contêineres do Docker podem ser hospedados em sua própria infraestrutura do Windows ou do Linux ou em um serviço de nuvem, como o Serviço de Kubernetes do Azure. O Serviço de Kubernetes do Azure pode gerenciar, orquestrar e dimensionar aplicativos baseados em contêiner na nuvem.

Alto desempenho e sistemas escalonáveis

Quando o seu sistema precisa do melhor desempenho e escalabilidade possíveis, o .NET e o ASP.NET Core são as melhores opções. O runtime de servidor de alto desempenho para Windows Server e Linux torna o ASP.NET Core uma estrutura da Web de desempenho superior nas avaliações da TechEmpower.

O desempenho e a escalabilidade são especialmente relevantes para arquiteturas de microsserviços, nas quais centenas de microsserviços podem estar em execução. Com o ASP.NET Core, os sistemas são executados com um número bem menor de servidores/VMs (Máquinas Virtuais). A redução em servidores/VMs gera economia em infraestrutura e hospedagem.

Versões do .NET lado a lado por nível de aplicativo

Para instalar aplicativos com dependências em diferentes versões do .NET, é recomendável o .NET. Essa implementação oferece instalação lado a lado de versões diferentes do runtime do .NET Core no mesmo computador. A instalação lado a lado permite vários serviços no mesmo servidor, cada um em sua própria versão do .NET. Ela também reduz os riscos e gera economia financeira nas operações de TI e atualizações de aplicativo.

A instalação lado a lado não é possível com o .NET Framework. Ele é um componente do Windows, e apenas uma versão pode existir em um computador por vez. Cada versão do .NET Framework substitui a versão anterior. Se você instalar um novo aplicativo destinado a uma versão posterior do .NET Framework, poderá acabar interrompendo os aplicativos existentes executados no computador, pois a versão anterior foi substituída.

Quando escolher o .NET Framework

O .NET oferece benefícios significativos para novos aplicativos e padrões de aplicativo. No entanto, o .NET Framework continua sendo a escolha natural para muitos cenários existentes e, portanto, não é substituído pelo .NET em todos os aplicativos para servidores.

Aplicativos .NET Framework atuais

Na maioria dos casos, não é necessário migrar aplicativos existentes para o .NET. Alternativamente, recomendamos o uso do .NET ao estender um aplicativo existente, como escrever um novo serviço Web no ASP.NET Core.

Bibliotecas de terceiros ou pacotes NuGet não disponíveis para o .NET

O .NET Standard permite o compartilhamento de código entre todas as implementações do .NET, incluindo o .NET Core/5+. Com o .NET Standard 2.0, um modo de compatibilidade permite que os projetos do .NET Standard e do .NET referenciem bibliotecas do .NET Framework. Para obter mais informações, consulte Suporte para bibliotecas do .NET Framework.

Portanto, apenas nos casos em que as bibliotecas ou pacotes NuGet usarem tecnologias que não estão disponíveis no .NET Standard ou .NET você precisará usar o .NET Framework.

Tecnologias do .NET Framework não disponíveis para o .NET

Algumas tecnologias do .NET Framework não estão disponíveis no .NET. A lista a seguir mostra as tecnologias mais comuns não encontradas no .NET:

Aplicativos ASP.NET Web Forms: os ASP.NET Web Forms só estão disponíveis no .NET Framework. O ASP.NET Core não pode ser usado para Web Forms do ASP.NET.
Aplicativos de páginas da Web do ASP.NET: as páginas da Web do ASP.NET não estão incluídas no ASP.NET Core.
Serviços relacionados a fluxo de trabalho: o WF (Windows Workflow Foundation), o Workflow Services (WCF + WF em um único serviço) e o WCF Data Services (anteriormente conhecido como "ADO.NET Data Services") só estão disponíveis no .NET Framework.
Suporte de linguagem: atualmente há suporte para Visual Basic e F# no .NET, mas não para todos os tipos de projeto. Para obter uma lista de modelos de projeto com suporte, consulte Opções de modelo para o dotnet new.

Para obter mais informações, confira Tecnologias do .NET Framework não disponíveis no .NET.

A plataforma não dá suporte ao .NET

Algumas plataformas de terceiros ou da Microsoft não oferecem suporte ao .NET. Alguns serviços do Azure fornecem um SDK que ainda não está disponível para ser consumido no .NET. Nesses casos, você pode usar a API REST equivalente em vez do SDK do cliente.