Pensar el desarrollo con herramientas Microsoft era sinónimo de usar imperativamente Visual Studio, SQL Server y Windows. Era más que evidente que en los planes de Microsoft no se contaba con la idea de ser “open source” como una política de la empresa. Es por esto que la aparición de la versión 1.0 del framework Net Core fue bastante disruptivo. Éste se podía usar en los sistemas operativos más comunes para el desarrollo de software como Linux y MacOS, lo cual extendió las posibilidades de poder trabajar con esta nueva herramienta.

Por ello, la versión 1.0 buscó solucionar el problema más usual de esta herramienta de desarrollo para entornos web: el performance.

Como sabemos, una de las dependencias que se tenían al desarrollar aplicaciones web con .NET era el tener que usar Internet Explorer. Este navegador era considerado como uno de los más problemáticos para este tipo de desarrollo. Esto, gracias a que se necesitaban hacer algunos ajustes extras para tener todo funcionando (no siempre muy elegantes ni mucho menos eficientes).

En la imagen 1 del cuadro comparativo se explica el desempeño de este nuevo framework . Con más de 6.9 millones de respuestas exitosas por segundo

Imagen 1: Cuadro comparativo
Fuente: Tech empower

¿Qué hay de nuevo en framework Net Core?

Tal como mencionamos, la versión 1.0 de NET Core soluciona el problema de performance. Siendo 8 veces más rápido que Node.Js en renderizar texto plano. Asimismo, con la salida de la versión 2.0, el performance mejoró aún más. También, lograron adicionar el acceso a un número mayor de APIs, brindando soporte a Razor Pages y SignalR. Lo cual hizo que migrar aplicaciones a .NET Core fuera aún más fácil. 

Desde noviembre del año pasado tenemos la versión 3.0 de este framework. Se han añadido soporte Windows Forms, WPF y Entity Framework 6. Haciendo posible portar aplicaciones Windows, aunque no con gran facilidad, ya que no se cuenta con un diseñador de formularios.

Así como .NET Core 3.0 adiciona soporte a gran cantidad de sus características previas, Microsoft tomó la decisión de no portar otras características como WebForms, WCF y Remoting Services. Para lo cual se recomienda usar Blazor o ASP NET Core Web API.

.NET Schedule

Imagen 2: Liberación de .NET en los próximos años 
Fuente

Como podemos ver en la imagen 2, el término “.NET Core” y “NET Framework” desaparecen y se establece sólo como “.NET”. Esto se debe a que Microsoft busca unificar el concepto de los términos en una sola herramienta para simplificar aún más el uso de la plataforma.

.Net Core

https://msdnshared.blob.core.windows.net/media/2018/10/Move-your-first-steps-with-.NET-Core-3.0-for-desktop-developmentnetcore32.png
Imagen 3: Componentes actuales de .NET Core 3 
Fuente

En la imagen 3 podemos ver cuáles son los componentes actuales del .NET Core 3.1 LTS. Nótese que como parte de esta versión no tenemos aplicaciones de escritorio ni móviles. Aún dependen de librerías que no han sido portadas a Net Core. Por ejemplo: las librerías de Mono que aún se requieren para desarrollo en Xamarin. 

.NET – A unified platform

Imagen 4: Arquitectura de NET 5
Fuente

Pero esto está a punto de cambiar. Microsoft planea liberar en noviembre de 2020 este framework unificado (tal como se ve en la imagen 4). De esta forma, se tendrá una suite de trabajo para desarrollar aplicaciones de escritorio, web, mobile, IoT, gaming e inteligencia artificial.

Es por esto que está en nosotros, los desarrolladores, investigar cómo y cuánto podría afectarnos el cambio en nuestros desarrollos actuales. Así, prepararemos la mejor estrategia que nos ayude a que este cambio tenga el menor impacto posible en nosotros. Por el momento se ha liberado la versión .NET v5.0.0-preview.3 (revisar aquí)

Los cambios que se vienen implementando:

1. Unificación del SDK

Una sola Base Class Library. Como sabemos, actualmente para el desarrollo con Xamarin aún requerimos las librerías base de Mono pero una vez que se dé este cambio, necesitaremos un solo SDK.

Además, el SDK móvil (Xamarin) se encontrará integrado en .NET 5.

2. Las aplicaciones nativas soportan diferentes plataformas

Por ejemplo, si creamos una aplicación nativa, esta podrá ejecutarse en diferentes dispositivos como Windows Desktop, Microsoft Duo (dispositivo Android de Microsoft) y iOS. Cabe mencionar que ciertas funcionalidades propias de Windows, solo seguirán siendo disponibles desde Windows.

3. Inclusión de Blazor Web Applications

Esto nos brindará la posibilidad de ejecutar nuestra aplicación en navegadores, dispositivos móviles o como si fuera una aplicación de Windows.

4. Cloud Native Applications de alto performance.

5. Existe la promesa de Microsoft en seguir mejorando el performance de este framework

En cada release que salga a la luz seremos capaces de notarlo. En el actual release de .NET 5 contamos con un mejor soporte de contenedores (Docker y Kubernetes) y soporte a HTTP3.

Adicionalmente, uno de los cambios no referidos directamente con el framework es la reducción del número de repositorios de Github (con la versión 1.0 de Net Core se tenían más de 100 repositorios).

De ahí que, ahora contamos con repositorios unificados por categorías:

Conclusión

Como desarrolladores .NET debemos de estar constantemente revisando las actualizaciones de este nuevo producto, pues este cambio puede llegar a afectar no solo a nosotros, sino también a las compañías para las cuales construimos software de calidad.

A todos aquellos que aún siguen desarrollando para aplicaciones legacy con .NET Framework 4.8, ha llegado el momento de plantear a sus respectivas compañías el inicio de investigación para evaluar la posibilidad de portar dichas aplicaciones a .NET 5, o, en el peor escenario, rehacer las aplicaciones con este nuevo SDK. 

Por otro lado, a título personal, recomiendo solo ir revisando noticias al respecto, pero no hacer desarrollos. Esto, por experiencia personal con la versión 3.0 Preview. Los cambios que se pueden esperar entre estas versiones pueden generar confusiones, pues lo que funcionó bien con el Preview 1 podría no funcionar con el Preview 2. Haciendo que investigar se vuelva frustrante, más aún; si nuestro objetivo es saber si podemos migrar una aplicación que ya está en producción.

Por tal motivo, es mejor esperar un poco para poder testear una versión estable. Recomiendo esperar hasta la versión RC (Release Candidate) sea liberada, para poder realizar pruebas de concepto adecuadas.

Por último, para aquellos que se encuentran analizando la portabilidad de su aplicación .NET Core 3, pueden usar la herramienta .NET Portability Analyzer. Esta herramienta les podrá indicar qué porciones de código son migrables, lo cual es bastante útil como punto de partida.

Este artículo hace parte de las Tech Insiders de .Net. A lo largo del año, estaremos realizando distintos eventos virtuales para que puedas conocer las últimas tendencias y seguir capacitándote.

Si quieres estar pendiente a nuestros próximos eventos acá.

Facebooktwitterredditlinkedinby feather

Leave a Reply

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>