Introducción

Prólogo

"Sólo hay dos cosas difíciles en Informática: cache invalidation and naming things " (Phil Karlton).

Como sabe cualquier buen desarrollador, la nomenclatura es importante y debe reflejar la intención del autor con la mayor exactitud posible. Lo mismo ocurre con los frameworks y las tecnologías creadas a lo largo de la historia de la informática.

Inicialmente llamada .NET Core 5 (igual que ASP.NET 5 y Entity Framework 7), los equipos decidieron cambiar completamente el nombre de la nueva versión de ASP.NET, porque no, ASP.NET 5 no es más grande ni más completa, simplemente es diferente. Así que mantener exactamente el mismo nombre y solo cambiar el número de versión era irrelevante. En julio de 2016, ASP.NET 5 se convirtió en ASP.NET Core y con él, toda una nueva página en la historia del framework .NET y de Microsoft.

Dejemos una cosa clara desde el principio: el framework .NET clásico no está muerto. Miles de sistemas informáticos funcionan con él y seguirán haciéndolo. La llegada de .NET Core no significa la muerte de todos los viejos programas desarrollados antes y el .NET Framework seguirá evolucionando y creciendo. Sin embargo, hoy en día es importante estudiar qué framework se adapta mejor a sus necesidades y a las competencias disponibles en sus equipos, para hacer la mejor...

La llegada de .NET Core

.NET Core es un framework de desarrollo multiplataforma, diseñado por los equipos de Microsoft, para desarrollar sitios web, servicios y aplicaciones de consola. Puede parecer simplista a primera vista, pero .NET Core tiene muchas diferencias importantes con su predecesor.

Diagrama resumido de .NET Core en el ecosistema de Microsoft

La primera gran diferencia con el framework .NET es su capacidad para ejecutarse en cualquier plataforma. Los desarrolladores que deseen desarrollar con el framework .NET sólo podrán crear aplicaciones que se ejecuten en Windows, lo que resulta ideal para aplicaciones WPF, WinForms o WCF. La versión Core, en cambio, es capaz de ejecutarse tanto en Linux como en Windows o Mac, lo que la hace completamente portable de un sistema a otro.

Su portabilidad es una característica que debe tenerse en cuenta cuando se utilizan API específicas de una plataforma. Si el API en cuestión no es compatible con todas las plataformas, seguramente no estará presente en .NET Core. En cambio, el framework de .NET admite absolutamente todas las API de Windows, lo que puede ser decisivo según el caso de uso. En segundo lugar, es posible ejecutar varios runtimes de .NET Core al mismo tiempo, en la misma máquina. Por tanto, cuando se trata de compartir servidores y reducir costes, este framework puede ofrecer una ventaja considerable sobre el framework de .NET clásico.

Sin embargo, aún no todas las librerías NuGet son compatibles con .NET Core, a pesar del excelente trabajo de compatibilidad con versiones anteriores (alrededor del 70% de las librerías dirigidas al framework de .NET son compatibles con .NET Core). Dependiendo de las librerías externas a las que se dirija, es importante elegir el framework adecuado para evitar quedarse atascado.

La arquitectura global del sistema de información también puede influir en la elección del framework elegido. El framework .NET se ha utilizado a menudo para sistemas monolíticos...

La supercapa ASP.NET Core

Una de las primeras tecnologías introducidas en el framework fue ASP.NET. ASP.NET Core es en sí mismo un framework basado en .NET Core, que permite la creación de aplicaciones web, IoT y backend móvil. Por sí solo, permite: 

Este framework es decididamente de código abierto y cuenta con innumerables repositorios de GitHub en los que cualquiera puede contribuir: https://github.com/aspnet

En este sentido, los equipos de Microsoft organizan periódicamente Community Standups, que permiten a los desarrolladores de la comunidad conocer los últimos avances en inteligencia de negocio y desarrollos técnicos de la plataforma: https://live.asp.net/. Estos vídeos son una gran oportunidad para intercambios privilegiados entre los equipos y el resto del mundo. También brindan la oportunidad de conocer a las personas que están detrás de las tecnologías que se están desarrollando.

El pattern MVC siempre ha desempeñado un papel importante en ASP.NET, con diferentes versiones del framework que se ofrecen en línea con este pattern de diseño, siendo la última la versión 5. La versión Core no es una excepción a la regla y cuenta con características específicas de MVC que permiten crear aplicaciones web y API web como:

La arquitectura interna también ha cambiado significativamente. El framework ya no se basa en la dependencia System.Web.dll, sino en varios paquetes NuGet con una granularidad más fina para gestionar mejor la modularidad del framework. El proyecto MVC es de código abierto: https://github.com/aspnet/Mvc

Probablemente, la característica más obvia de ASP.NET Core es la composición de la aplicación: se trata simplemente de una aplicación de consola que lanza un servidor web.

using System;   
using Microsoft.AspNetCore.Hosting; 
  
namespace aspnetcoreapp   
{   
    public class Program   
    {   
        public static void Main(string[] args)   
        {   
             var host = new WebHostBuilder()   
                .UseKestrel()   
                .UseStartup<Startup>() 
                 .Build(); 
  
            host.Run();   
        }   
    }...

La renovación de un ecosistema

El objetivo de Microsoft es llevar sus herramientas al mayor número posible de plataformas, para ampliar su ecosistema y llegar a más profesionales de TI (desarrolladores, arquitectos, responsables de TI, etc.). Además, al abrirse al código abierto, Microsoft se beneficia de una creciente comunidad de expertos que contribuyen a sus proyectos en GitHub. VS Code es el repositorio con más contribuciones y todo el framework ASP.NET Core está en GitHub. Redmond se ha convertido así en el mayor contribuyente al mundo del código abierto y, con la adquisición de GitHub, la compañía estadounidense pretende invertir cada vez más en este sector integrándolo aún mejor en su ecosistema.

Están surgiendo nuevas arquitecturas y otras destacan claramente en mercados de rápido crecimiento. Con x64 dominando los mercados cloud, los servidores y los PC y ARM en smartphones y tabletas, las tecnologías de software tienen que adaptarse para sacar el máximo partido de una experiencia común, sea cual sea la arquitectura subyacente. Y no hay que olvidar el IoT, que está empujando cada vez más a ARM, permitiendo una mayor conectividad dentro de los objetos conectados. Todos estos factores hacen que .NET se tenga que adaptar y proponer cambios para dar una respuesta coherente a todas estas cuestiones.

Microsoft también se enfrenta a la creciente competencia de NodeJS para el desarrollo de servidores. JavaScript es uno de los lenguajes más adoptados en el mundo, por lo que resulta ventajoso para las empresas utilizar NodeJS para aunar competencias en la medida de lo posible. El rendimiento también es una característica clave. Por tanto, los equipos de Microsoft han tenido que reaccionar para ofrecer un framework más potente.

El ecosistema también está sujeto a un cambio creciente en las soluciones desarrolladas. Hace unas décadas, la tendencia en las mejores prácticas y en las soluciones denominadas de "calidad" se orientaba hacia filosofías de desarrollo: programación orientada a objetos, fuertemente tipada y código estático. Hoy hablamos de integración continua, despliegue continuo, Dockerización y arquitectura de microservicios. En este sentido...

Convergencia con .NET 5

Hasta la versión 3.1 de .NET Core, el framework se denominaba .NET Core y con él todas las herramientas y SDK asociados, como Entity Framework Core y ASP.NET Core. Por aquel entonces, las librerías .NET conocidas como .NET Standard estaban cada vez más extendidas y se beneficiaban de una amplia cobertura de API dentro de la BCL. Con .NET Standard, los desarrolladores pueden crear librerías reutilizables en prácticamente todo el ecosistema .NET.

Como su nombre indica, .NET Standard es un estándar, una especie de abstracción que cada plataforma subyacente debe implementar para beneficiarse de la reutilización en todo el ecosistema. Tecnologías como ASP.NET Core, Xamarin y UWP implementan este estándar, lo que permite a los desarrolladores crear librerías .NET Standard que se pueden utilizar en todas las plataformas compatibles con .NET Standard. La versión de .NET Standard también es una dimensión importante, ya que los desarrolladores se deben dirigir a una versión que cumpla las versiones admitidas por las plataformas a las que desean dirigirse. Por ejemplo, no podrán crear una librería .NET Standard 2.0 para una aplicación ASP.NET Core 2, porque .NET Core 2 no implementa el estándar en la versión 1.6. La matriz siguiente muestra la correspondencia entre .NET Standard y el ecosistema.

La matriz de correspondencias entre .NET Standard y otras plataformas .NET

La primera línea muestra las versiones de .NET Standard y, debajo, todas las plataformas del ecosistema .NET. Las distintas versiones de plataforma hacen referencia a la versión mínima a la que se debe apuntar para que sea compatible con la versión de .NET Standard, indicada en la primera línea.

Este enfoque presenta varios inconvenientes. El primero es la lentitud con la que se introducen nuevas funciones en la norma. El hecho de que el estándar tenga que implantarse en cada una de las plataformas exige la coordinación entre todos los equipos de las plataformas y el equipo que diseña el estándar.

Hasta la versión .NET Standard 2, esto no era un problema, ya que la tarea principal consistía en reconstituir los API existentes, sobre todo las presentes en el framework de .NET. Pero el futuro va a ser innovador y la innovación implica nuevas versiones de .NET Standard. Por tanto, dar soporte a nuevos API a través de .NET Standard y ver aparecer rápidamente nuevas versiones, es muy complicado.

El segundo inconveniente es el fuerte vínculo existente entre la abstracción que proporciona el estándar, la implementación por parte de las distintas plataformas y la complejidad resultante de esta unión. .NET Standard unifica las plataformas introduciendo una nueva que pretende ser el estándar para todas las demás. El mapeo sigue siendo difícil de entender, aunque esta no era la intención original.

El último inconveniente es la exposición de APIs específicas para una plataforma determinada. Para ser compatibles con .NET Standard, los equipos de las plataformas obviamente tienen que hacer concesiones. No todas las API son 100% transponibles de una plataforma a otra. Por ejemplo, es imposible implementar API relativas al registro de Windows en Android, ya que el registro no existe. Por tanto, esta concesión obliga a los desarrolladores a estar atentos a sus implementaciones y a introducir código específico para gestionar estos casos de incompatibilidad.

private static string GetLoggingDirectory() 
{   
    if (OperatingSystem.IsWindows()) 
    {   
        using (RegistryKey key =  
Registry.CurrentUser.OpenSubKey(@"Software\Fabrikam")) 
        {   
            if (key?.GetValue("LoggingDirectoryPath") is string 
configuredPath) 
                return configuredPath; 
        } 
    } 
   
    string exePath =  
Process.GetCurrentProcess().MainModule.FileName; 
    string folder = Path.GetDirectoryName(exePath); 
    return Path.Combine(folder, "Logging"); 
   
} 

A partir de .NET 5, las plataformas convergen realmente. En otras palabras, en lugar de tener por un lado un estándar que rige las API disponibles y por otro las plataformas que implementan este estándar, .NET 5 se construye sobre una única base de código, en todas las plataformas e implementa de facto el estándar sin pasar por una abstracción adicional. Extender el estándar sigue siendo posible, ya que basta con crear una rama desde el repositorio dotnet/runtime en GitHub. .NET 5 está disponible desde noviembre de 2020.

La lógica que subyace a las versiones de .NET también está cambiando con el lanzamiento de .NET 5. Los equipos de Microsoft ofrecerán una nueva versión principal de .NET cada año de forma fija, pero sólo una de cada dos versiones será de soporte a largo plazo. Este proceso proporciona un calendario fijo y predecible para las versiones de .NET....