Diferencias entre .NET y .NET Framework en cuanto a aplicaciones de servidor

Artículo
05/10/2023

Existen dos implementaciones de .NET admitidas para compilar aplicaciones del lado servidor.

Implementación	Versiones incluidas
.NET	.NET Core 1.0 - 3.1, .NET 5 y versiones posteriores de .NET.
.NET Framework	.NET Framework 1.0 - 4.8

Las dos comparten muchos de los mismos componentes y es posible compartir código entre ellas. En cambio, presentan diferencias fundamentales y la elección depende de lo que quiera realizar. En este artículo se proporcionan orientaciones sobre cuándo usar cada una.

Use .NET para la aplicación de servidor cuando:

Tenga necesidades multiplataforma.
Tenga los microservicios como objetivo.
Vaya a usar contenedores de Docker.
Necesite sistemas escalables y de alto rendimiento.
Necesite versiones de .NET en paralelo por aplicación.

Use .NET Framework para su aplicación de servidor cuando:

La aplicación usa actualmente .NET Framework (la recomendación es extender en lugar de migrar).
La aplicación usa bibliotecas de terceros o paquetes NuGet que no están disponibles para .NET.
La aplicación usa tecnologías de .NET Framework que no están disponibles para .NET.
La aplicación usa una plataforma que no es compatible con .NET.

Cuándo elegir .NET

En las secciones siguientes se explican de manera más detallada las razones indicadas anteriormente para elegir .NET en vez de .NET Framework.

Necesidades multiplataforma

Si la aplicación web o de servicio debe ejecutarse en varias plataformas, por ejemplo, Windows, Linux y macOS, use .NET.

.NET admite los sistemas operativos mencionados anteriormente como estación de trabajo de desarrollo. Visual Studio proporciona un entorno de desarrollo integrado (IDE) para Windows y macOS. También puede usar Visual Studio Code, que se ejecuta en macOS, Linux y Windows. Visual Studio Code es compatible con .NET, incluidos IntelliSense y la depuración. La mayoría de los editores de terceros, como Sublime, Emacs y VI, funcionan con .NET. Estos editores de terceros obtienen el editor de IntelliSense mediante Omnisharp. También puede evitar el uso de un editor de código y utilizar directamente la CLI de .NET, disponible para todas las plataformas compatibles.

Arquitectura de microservicios

Una arquitectura de microservicios permite una combinación de tecnologías en un límite de servicio. Esta combinación de tecnología permite un adopción gradual de .NET para los microservicios nuevos que funcionan con otros servicios o microservicios. Por ejemplo, puede combinar microservicios o servicios desarrollados con .NET Framework, Java, Ruby u otras tecnologías monolíticas.

Existen muchas plataformas de infraestructura. Azure Service Fabric está diseñada para sistemas de microservicios grandes y complejos. Azure App Service es una buena elección para microservicios sin estado. Los microservicios alternativos basados en Docker encajan en cualquier enfoque de microservicios, como se explica en la sección Contenedores. Todas estas plataformas admiten .NET, lo que hace que resulten perfectas para hospedar microservicios.

Para obtener más información sobre la arquitectura de microservicios, consulte .NET Microservices. Architecture for Containerized .NET Applications (Microservicios de .NET: Arquitectura para aplicaciones .NET en contenedor).

Contenedores

Los contenedores se usan normalmente junto con una arquitectura de microservicios. Los contenedores también se pueden usar para incluir las aplicaciones web o los servicios en contenedores que sigan cualquier patrón de arquitectura. .NET Framework se puede usar en contenedores de Windows. Sin embargo, la modularidad y la naturaleza ligera de .NET lo convierten en una mejor opción para los contenedores. Al crear e implementar un contenedor, el tamaño de su imagen es mucho más pequeño con .NET que con .NET Framework. Como es multiplataforma, puede implementar aplicaciones de servidor en contenedores de Docker de Linux.

Los contenedores de Docker pueden hospedarse en su propia infraestructura de Linux o Windows, o en un servicio en la nube como Azure Kubernetes Service. Azure Kubernetes Service puede administrar, organizar y escalar aplicaciones basadas en contenedores en la nube.

Sistemas escalables y de alto rendimiento

Cuando el sistema necesite el mejor rendimiento y escalabilidad posibles, .NET y ASP.NET Core son las mejores opciones. El entorno de ejecución de servidor de alto rendimiento para Windows Server y Linux convierte a ASP.NET Core en un marco web de gran rendimiento en los bancos de pruebas de TechEmpower.

El rendimiento y la escalabilidad son especialmente importantes para las arquitecturas de microservicios, donde podrían estarse ejecutando cientos de microservicios. Con ASP.NET Core, los sistemas se ejecutan con un número mucho menor de servidores/máquinas virtuales. Al usar menos servidores/máquinas virtuales, se ahorran costes de infraestructura y hospedaje.

Versiones de .NET en paralelo por nivel de aplicación

Para instalar aplicaciones con dependencias en otras versiones de .NET, se recomienda .NET. Esta implementación admite la instalación en paralelo de otras versiones del entorno de ejecución de .NET en la misma máquina. La instalación en paralelo permite varios servicios en el mismo servidor, cada uno en su propia versión de .NET. También reduce los riesgos y ahorra dinero en las operaciones de TI y las actualizaciones de aplicaciones.

La instalación en paralelo no es posible con .NET Framework. Se trata de un componente de Windows, y solo puede existir una versión en un equipo a la vez. Cada versión de .NET Framework reemplaza la anterior. Si instala una aplicación nueva que tenga como destino una versión posterior de .NET Framework, es posible que se interrumpan las aplicaciones existentes que se ejecutan en la máquina, ya que se ha reemplazado la versión anterior.

Cuándo elegir .NET Framework

.NET ofrece ventajas significativas para las aplicaciones nuevas y los patrones de aplicación. Pero .NET Framework sigue siendo la opción natural para muchos escenarios existentes y, por tanto, no se reemplaza por .NET para todas las aplicaciones de servidor.

Aplicaciones actuales de .NET Framework

En la mayoría de los casos, no tendrá que migrar las aplicaciones existentes a .NET. En su lugar, se recomienda usar .NET a medida que extiende una aplicación existente, como al escribir un nuevo servicio web en ASP.NET Core.

Bibliotecas de terceros o paquetes NuGet no disponibles para .NET

.NET Standard permite compartir código entre todas las implementaciones de .NET, incluidos .NET Core/5+. Con .NET Standard 2.0, un modo de compatibilidad permite que los proyectos de .NET Standard y .NET hagan referencia a bibliotecas de .NET Framework. Para obtener más información, vea Compatibilidad con las bibliotecas de .NET Framework.

Tendrá que utilizar .NET Framework solo cuando en las bibliotecas o los paquetes NuGet se usen tecnologías que no estén disponibles en .NET Standard o .NET.

Tecnologías de .NET Framework no disponibles para .NET

Algunas tecnologías de .NET Framework no están disponibles en .NET. En la lista siguiente se muestran las tecnologías más comunes que no se encuentran en .NET:

Aplicaciones de ASP.NET Web Forms: ASP.NET Web Forms solo está disponible en .NET Framework. No se puede usar ASP.NET Core para ASP.NET Web Forms.
Aplicaciones de ASP.NET Web Pages: ASP.NET Web Pages no se incluye en ASP.NET Core.
Servicios relacionados con flujos de trabajo: Windows Workflow Foundation (WF), Workflow Services (WCF + WF en un único servicio) y WCF Data Services (anteriormente conocido como «ADO.NET Data Services») solo están disponibles en .NET Framework.
Compatibilidad con lenguajes: Visual Basic y F# se admiten actualmente en .NET, pero no para todos los tipos de proyecto. Para obtener una lista de plantillas de proyecto compatibles, consulte Opciones de plantilla para dotnet new.

Para obtener más información, vea Tecnologías de .NET Framework no disponibles en .NET.

Plataformas no compatibles con .NET

Algunas plataformas de terceros o de Microsoft no son compatibles con .NET. Algunos servicios de Azure proporcionan un SDK que todavía no está disponible para su consumo en .NET. En esos casos, puede usar la API REST equivalente en lugar del SDK de cliente.