Menú de navegaciónMenú
Categorías

La mejor forma de Aprender Programación online y en español www.campusmvp.es

?id=6a944e03-e201-476d-a5eb-5973ea176319

¿Por qué ASP.NET Core?

banner-asp-net-core-750x300

Ya hemos hablado muchas veces en esta web de .NET Core, y de cómo ha cambiado muchas cosas respecto a versiones anteriores de la plataforma de desarrollo de Microsoft. Y esto es especialmente cierto en el ámbito del desarrollo web y ASP.NET Core.

Nota: si no tienes claro qué es .NET Core y cómo se relaciona con .NET "tradicional", por favor, antes de seguir lee este artículo.

Sin duda, su aparición ha supuesto el cambio más grande para las tecnologías de desarrollo web de Microsoft desde sus inicios, y tanto es así que, de hecho, es un producto totalmente nuevo, escrito desde cero.

Pero, obviamente, el gigante de Redmond no ha dado este paso por capricho; se trata de una gran inversión que sin duda debía estar justificada.

A continuación, veremos qué motivos llevaron a Microsoft a considerar un proyecto de esta envergadura, así como las características más destacadas que encontramos en este framework.

¿Por qué ASP.NET Core?

Desde sus comienzos, allá por el año 2002, el framework ASP.NET ha incluido todo lo necesario para construir aplicaciones web usando los lenguajes y herramientas de Microsoft. Contenía tanto aspectos de pura infraestructura como marcos de trabajo para el desarrollo de aplicaciones (básicamente Web Forms), y todo construido de forma monolítica.

Una consecuencia de este diseño era que cuando usabas ASP.NET en tus aplicaciones, obligatoriamente debías incluir todo el framework aunque no lo utilizaras por completo. Por ejemplo, aunque tu sitio web fuera una simple página web informativa, cada petición se veía obligada a atravesar un complejo entramado de componentes para generar la respuesta que era finalmente enviada el cliente: módulos, handlers, recuperación de estado de vistas, construcción de árboles de controles, seguridad, gestión de errores, etc. Algunos de estos componentes podían activarse o desactivarse desde el archivo de configuración, pero seguían estando ahí, ocupando memoria y tiempo de proceso en cada petición.

Esta estructura asimismo complicaba bastante la evolución del producto, que debía mantener la mirada hacia atrás para proporcionar la mayor retro-compatibilidad posible. Dado que el diseño del producto no era modular, no era posible actualizar un componente o funcionalidad de forma individual, y la complejidad del framework hacía que los ciclos de aparición de nuevas versiones eran muy largos (¡años!), mientras que se estaba viendo que las tecnologías y tendencias para la web evolucionaban muy rápido. Cada versión añadía características nuevas que contribuían a engordar ese monstruo en el que se había convertido ASP.NET, pero normalmente iban muy por detrás de las necesidades reales del mercado y de la comunidad de desarrolladores.

Cuando Microsoft empezó a construir otros marcos de trabajo basados en ASP.NET (MVC, luego Web API, Web Pages, y más tarde SignalR), comenzaron a darse cuenta de que todos ellos arrastraban una pesada losa: el mastodóntico núcleo de ASP.NET, llamado de forma genérica System.Web. Este núcleo, que conformaba la monolítica infraestructura básica sobre la que corrían todas las aplicaciones basadas en ASP.NET, era enorme, complejo, pesado, muy ligado a tecnologías y servidores de Microsoft, y en muchos aspectos estaba mal diseñado, o al menos no diseñado con los parámetros y buenas prácticas que hoy en día entendemos como razonables.

Y en la práctica, la conclusión a la que llegaron es que todos los nuevos marcos de trabajo estaban limitados por su infraestructura. MVC, Web API o SignalR estaban razonablemente bien construidos y pensados desde un principio para ser muy eficientes, pero su dependencia de ASP.NET no era buena para su evolución ni para la apertura de nuevas fronteras como el salto a entornos multiplataforma, además de suponer un lastre importante en cuanto la velocidad y consumo de recursos de las peticiones, tan importantes en los modernos entornos escalables y servicios en la nube.

El siguiente diagrama refleja la pila de tecnologías web de Microsoft con ASP.NET 4.x:

old-stack

OWIN y Katana vinieron al rescate hace algún tiempo como los aislantes que necesitábamos entre los marcos de trabajo de alto nivel y la infraestructura, y las últimas versiones de los frameworks más jóvenes como Web API y SignalR los utilizaron de forma correcta para desvincularse totalmente de System.Web. Esta independencia hizo posible que pudieran alojarse servicios Web API o SignalR en cualquier tipo de proceso (aplicación web, servicio Windows, aplicación de consola…) y que fueran muy eficientes.

Sin embargo, conseguir lo mismo con MVC era mucho más complejo, y hasta su versión 5 continuó completamente atado a System.Web (ASP.NET 4.x) porque internamente lo utilizaba en demasiados puntos.

Era el momento de romper la baraja

En Noviembre de 2012, en el marco del evento Visual Studio Connect(), Microsoft presentó públicamente los detalles sobre lo que sería la próxima versión de ASP.NET, todavía en aquél momento llamada "ASP.NET vNext" o, internamente, "Project K". La idea era partir desde cero y crear una infraestructura ligera, modular, y capaz de ejecutarse tanto sobre .NET framework tradicional como en el nuevo .NET Core que comenzaba también a aparecer en el horizonte (y todavía no se llamaba así), abriendo la puerta a posibilidades inimaginables hasta el momento, como la ejecución multiplataforma, y a un rendimiento sin precedentes.

Como referencia, se estima que una petición típica en ASP.NET clásico (4.x) puede requerir un mínimo de 30Kb de memoria en el servidor para ser procesada, frente a los 2Kb de que se ocuparían en ASP.NET Core. Seguro que puedes imaginar la repercusión que puede tener esto en cuanto a aprovechamiento de recursos de un servidor en un sitio web con una carga media o alta.

Para nosotros los desarrolladores, el coste de acceder a estas ventajas está bien claro: ASP.NET Core rompe con las versiones anteriores en muchos aspectos. De hecho, es un entorno nuevo que tenemos que aprender y en el que tenemos que acostumbrarnos a trabajar.

Espero que esto te haya ayudado a entender por qué Microsoft ha tenido que crear ASP.NET Core y el camino que se ha recorrido hasta llegar aquí.

En un próximo artículo, la semana próxima, contaré cuáles son las principales novedades de ASP.NET Core y qué nos ofrece frente a ASP.NET tradicional. ¡Hasta entonces!

Fecha de publicación:
José María Aguilar José María atesora una amplísima experiencia trabajando en el mundo del desarrollo de software (programador, analista, responsable de informática, consultor, director técnico), principalmente con tecnologías Microsoft. Actualmente trabaja como consultor y desarrollador independiente, ofreciendo servicios tecnológicos a empresas e instituciones.
Es un reconocido experto en desarrollo web en todo el mundo, y es autor del libro de Microsoft Press "SignalR Programming in Microsoft ASP.NET".
Escribe regularmente artículos sobre ASP.NET MVC y otros temas relacionados con el desarrollo de software en su blog.
Puedes seguirlo en Twitter en @jmaguilar. Ver todos los posts de José María Aguilar

¿Te ha gustado este post?
Pues espera a ver nuestra newsletter...

Suscríbete a la newsletter

La mejor formación online para desarrolladores como tú

Comentarios (7) -

Esteban GaRo
Esteban GaRo

Muy buen artículo, ahora me ha llamado más la atención este nuevo framework, pero... ¿Es ahora un buen momento para comenzar a conocerlo? o ¿Deberíamos esperar a que "madure" un poco con el fin de encontrarlo más estable?.
Saludos.

Responder

campusMVP
campusMVP

Hola Esteban:

La versión actual es estable y está con funcionalidad completa, permitiéndote realizar aplicaciones web del mismo tipo que podrías crear con ASP.NET MVC 5.

De todos modos es probable que nuestro artículo de presentación del curso, en el que hay preguntas frecuentes, te aclare esta duda mejor:

/recursos/post/Nuevo-curso-Desarrollo-web-con-ASPNET-Core-MVC.aspx

y también el de José María Aguilar, su autor, en el que explica también ese tema:

www.variablenotfound.com/.../...-en-campusmvp.html

Saludos!

Responder

Oscar Fiblas Aramayo
Oscar Fiblas Aramayo

Al final sucede lo de siempre: cuando aparece un nuevo producto/herramienta (Windows, Visual Studio, tecnología,...) todo son maravillas. Recuerdo cuando se presentó .NET todo era alabanzas en ese nuevo "salto" que daba Microsoft en el desarrollo de software, mejor rendimiento, escalamiento, etc. Y resulta que después de un tiempo se empiezan a encontrar puras desventajas por lo que hay que dar otro "salto" en el desarrollo de software. Lo mismo sucedió cuando salieron Windows XP, Windows 7, ahora con Windows 10. En algunos años más alguien escribirá acerca de los problemas y desventajas de Core por lo que ahí va de nuevo otro "salto". No será que todo esto es sólo para justificar lo de obsolecensia programada?

Responder

José Manuel Alarcón
José Manuel Alarcón

Hola Oscar:

No es obsolescencia programada, es evolución tecnológica. De hecho .NET no está obsoleto, simplemente es una tecnología madura que va a evolucionar menos que Core, en la que están centrados ahora.

El mundo evoluciona y las tecnologías que estaban diseñadas para trabajar con un determinado entorno, ahora no lo están. Cuando .NET Se diseñó a finales de los años 90 (salió en 2001) no existía la nube, ni las arquitecturas de micro-servicios, ni siquiera los servicios REST basados en JSON (lo más de lo más por entonces era SOAP, basado en XML y hoy casi olvidado). Además el diseño era monolítico: si haces algo con .NET debes distribuir la plataforma completa aunque uses solamente una ínfima parte de ella.

En el entorno actual y para ciertas aplicaciones, como se explica en el artículo, ese diseño no es eficiente y se hace necesaria otra cosa. Para dar respuesta a eso dentro del mundo Microsoft surge .NET Core.

Seguramente dentro de 10 años, como no sabemos qué nos vamos a encontrar, surgirán nuevas necesidades y probablemente nuevas tecnologías. En un mundo que cambia tanto como el tecnológico no podemos esperar otra cosa.

Las demás plataformas también cambian. Java, aunque de manera lenta, ha evolucionado un montón en sus 25 años de vida y a partir de ahora cambiará mucho más pues han decidido sacar versiones nuevas cada año. Node.js ni siquiera existía hace 10 años. Incluso tecnologías que parece que no cambian demasiado como HTML y JavaScript, hace 5 o 6 años eran muy diferentes y tenían muchas menos capacidades que ahora. Hay ejemplos en casi cualquier tecnología que escojas.

En el caso de .NET ahora tienes también Xamarin, que está cambiando a marchas forzadas y al que es complicado seguirle el ritmo y que compite incluso con .NET y con .NET core en algunas cosas (más sobre estas tecnologías aquí: www.campusmvp.es/.../...llo-microsoft-en-2018.aspx). ¿Que lo podrían gestionar mejor de cara a los desarrolladores (y a los que nos dedicamos a la formación y los contenidos)? Sin lugar a dudas. Pero la evolución es necesaria.

Estaría de acuerdo contigo en el caso de otras tecnologías que cambian muchas veces de manera casi caprichosa, arbitraria y a veces absurda (por ejemplo, muchas tecnologías Front-End), y además personalmente pienso que no han gestionado bien en absoluto la forma de desarrollar .NET Core 1 durante los dos años que estuvo en preparación /ahora con 2.0 parece que las cosas van mejor).

Saludos!

Responder

Buenas tardes.  Muy bueno el articulo. La consulta que quería realizar es: si tengo que desarrollar una aplicación (web o de escritorio) desde cero con .NET, me conviene utilizar .NET Core, correcto? o hay cosas aún no puedo desarrollar con este framework? Por ultimo, en que ocaciones tendría que elegir .NET tradicional?

Responder

José Manuel Alarcón
José Manuel Alarcón

Hola Juan:
Si quieres desarrollar con .NET una nueva aplicación Web desde cero, .NET Core es una buena elección de cara al futuro. Si es de escritorio igual de momento no es tan buena idea ya que está orientada a aplicaciones de consola y no tanto gráficas, aunque esto cambiará de cara a .NET Core 3 que soportará Windows Forms y WPF (si bien de momento solo en Windows, que se sepa). Hoy por hoy .NET Core está orientado sobre todo a la web, aunque se puedan hacer otras cosas.

Respecto a elecciones: en estos momento está complicado porque hay muchas opciones. Léete esto: www.campusmvp.es/.../...llo-microsoft-en-2018.aspx

Saludos.

Responder

Existe electron.net que usa electron como gui, y net core como backend, ambos son multiplataformas, así que por ese aspecto, genial.

Responder

Agregar comentario

Los datos anteriores se utilizarán exclusivamente para permitirte hacer el comentario y, si lo seleccionas, notificarte de nuevos comentarios en este artículo, pero no se procesarán ni se utilizarán para ningún otro propósito. Lee nuestra política de privacidad.