miércoles, 3 de diciembre de 2014
Aunque aún en beta e inmersa en un intenso proceso de desarrollo, la próxima versión de ASP.NET MVC está tomando forma en los hornos de Microsoft, y, sin ser definitivas, ya se pueden ver cuáles serán las novedades principales que la acompañarán.
En futuros posts iremos entrando en mayor detalle, pero de momento vamos a echar un vistazo desde una cierta distancia para tener la idea general sobre dónde estamos y la evolución que vamos a encontrar en las nuevas versiones de tecnologías y plataformas, de forma que podamos ver en qué nos afectará como desarrolladores y, en definitiva, para qué tenemos que irnos preparando.
Sin embargo, ASP.NET MVC aún arrastra una pesada losa heredada de los primeros tiempos de .NET, allá por 2002: el mastodóntico core de ASP.NET, llamado de forma genérica “System.Web”. Este núcleo, que conforma la monolítica infraestructura básica sobre la que corren casi todas las aplicaciones ASP.NET actuales, es enorme, complejo, pesado, muy ligado a tecnologías y servidores, y en muchos aspectos está 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.
MVC sigue irremediablemente atado a System.Web porque internamente lo utiliza en demasiados puntos, y esta dependencia no es buena para la evolución del framework, 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 entornos escalables y servicios en la nube.
OWIN y Katana, de los que hemos hablado por aquí extensamente, 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 WebAPI y SignalR los utilizaron de forma correcta para desvincularse totalmente de System.Web. Esta independencia hizo posible que pudieran alojarse servicios WebAPI o SignalR en cualquier tipo de proceso (aplicación web, servicio windows, aplicación de consola…) y que fueran muy eficientes.
Sin embargo, migrar MVC a los conceptos propuestos por OWIN para no era una tarea sencilla, por lo que la versión 5 continuó atada a System.Web, y el uso de componentes OWIN/Katana se limitaba a la inclusión de middlewares de plataformas ajenas al framework MVC, como Identity Framework.
Y estando así el patio, aparece por el horizonte .NET Core 5 (aka Core CLR), un subconjunto del .NET tradicional escrito desde cero, open source, con vocación multiplataforma (soportado directamente en Linux y Mac), fácilmente distribuible a través de Nuget y optimizado en el mundo web para obtener lo mejor de los entornos servidor, tanto cloud como on premise.
.NET Core 5 no supone, al menos de momento, la desaparición del .NET “clásico”, cuya próxima versión será la 4.6, y que seguirá una línea más continuista con las versiones anteriores. NET Core es sólo una alternativa optimizada para distintos entornos, entre ellos los servidores, pero seremos nosotros los que decidiremos sobre qué infraestructura queremos construir. Pero por poner un ejemplo de las ventajas de Core CLR en el mundo web, se estima que al usarlo una petición típica puede requerir 2Kb de memoria de servidor para ser procesada, frente a los 30Kb que se ocuparía en caso de seguir usando la infraestructura tradicional. Imaginad la repercusión que puede tener esto en cuanto a aprovechamiento de recursos de un servidor.
¿Y qué tiene todo esto que ver con ASP.NET MVC 6? Pues la respuesta está en ASP.NET 5. La próxima versión de ASP.NET será un framework unificado en el que encontraremos tecnologías de desarrollo como MVC, WebPages o SignalR, y que podrá correr sobre .NET 4.6 en Windows/IIS o sobre .NET Core en cualquier plataforma (por supuesto, incluida Windows).
Si todo esto os parece algo confuso, que probablemente lo es, podéis profundizar en este gran post de César de la Torre, de donde he tomado prestado el par de diagramas que veis por aquí porque creo que resumen muy bien la estructura general del nuevo escenario:
Y dado este nuevo contexto, el primer cambio que encontraremos en MVC 6 y el resto de frameworks es que no hay ningún tipo de vínculo con componentes de ASP.NET clásico (System.Web), lo cual incide en muchos aspectos generales, como el propio tamaño del framework o su la velocidad de ejecución, pero también en detalles que nos afectarán a la hora de desarrollar.
Por ejemplo, el global.asax dejaba de tener sentido como tal, pues en su interior encontrábamos código vinculado a eventos de objetos propios de ASP.NET clásico. El código de inicialización, de nuevo, será más parecido al de sistemas basados en OWIN y la implementación de funcionalidades trasversales como un logging las haremos a base de construir middlewares. Tampoco será ya necesario el archivo Web.config, que durante tantos años ha servido para configurar tanto el servidor como las aplicaciones. Los archivos de configuración de los proyectos han cambiado a un modelo mucho más potente y flexible que estudiaremos en su momento.
Claro, y puestos a retocar infraestructura, se ha aprovechado para poner al día algunas asignaturas pendientes en ASP.NET, como la inyección de dependencias, que ahora vendrá integrada de serie y aplicada internamente en todos los frameworks, o el uso de la asincronía de forma generalizada. Si hasta ahora habéis ignorado los célebres async/await,
Roslyn es otro gran protagonista en el nuevo ASP.NET, tanto que incluso está dispuesto a cambiar la forma en que desarrollamos. El ciclo “Editar>Salvar>Ejecutar>Parar>Editar…” se va a simplificar porque ya no hará falta compilar de forma explícita, será Roslyn el que se encargue por detrás de esta tarea. Por ejemplo, si cambiamos el código de un controlador bastará con recargar la página en el navegador para ver el resultado, no habrá que parar la ejecución y volver a empezar. Como podréis suponer, esto no sólo afecta al workflow del proceso de desarrollo, sino que además posibilita otros escenarios de despliegue que hasta ahora no existían. Es un cambio fuerte para los que llevamos años con ASP.NET, pero seguro que podemos acostumbrarnos ;-)
En cuanto al tooling, también cambia bastante la cosa. Todas las herramientas de build y ejecución pueden lanzarse fácilmente desde la línea de comandos, supongo que porque se trata del común múltiplo en un contexto multiplataforma. Así, es posible realizar estas tareas exactamente de la misma forma independientemente de si estamos en Windows, Mac o Linux. Pero ojo, esto no significa que tengamos que usar oscuros comandos continuamente en nuestro día a día, seguro que Visual Studio y otras herramientas proporcionarán interfaces más similares a los que estamos acostumbrados a utilizar, aunque probablemente determinadas acciones estarán accesibles exclusivamente, al menos de momento, desde línea de comandos.
Puede usarse cualquier tipo de editor para programar aplicaciones ASP.NET, e incluso existen proyectos como Omnisharp para llevar utilidades como intellisense o herramientas de refactorización a editores ajenos a Microsoft como Brackets, Emacs o Sublime Text, desde cualquier sistema operativo. De nuevo, la idea es que el desarrollo de aplicaciones ASP.NET pueda hacerse desde cualquier plataforma y herramienta, y dejar que el desarrollador decida si prefiere alejarse de Windows/Visual Studio.
De la misma forma, y siguiendo una tendencia que se apunta desde hace ya algún tiempo, Visual Studio 2015 se alinea y hace uso de herramientas ya asentadas en otras comunidades de desarrolladores web, como el gestor de paquetes de frontend Bower o el sistema de automatización Grunt. Esto, unido a la necesidad de dar un poco de coherencia a las necesidades de mejora en la organización interna de los propios proyectos, tiene también su incidencia en la estructura de carpetas de las soluciones, que seguirán a partir de ahora un esquema más cercano a la realidad del desarrollo web.
Observad que todo lo que estamos comentando son cambios y novedades generales de la infraestructura de ASP.NET 5 y, por tanto, aplicable para todos los frameworks que se construyan sobre ella. Nada específico de MVC hasta el momento.
A lo bestia, podríamos decir que MVC se ha comido a WebAPI. Un ejemplo práctico es que ya no existirá la clase
Otra novedad interesante es la introducción de los View Componentes, un nuevo tipo de elementos reutilizables que permiten realizar acciones y componer porciones de vista de forma más eficiente y mejor integrada que las conocidas acciones hija o vistas parciales. Lo veremos en mayor detalle más adelante, pero si queréis ir echando un vistazo, el amigo Eduard escribió sobre ellos hace unos meses.
Con MVC6 encontraremos también una nueva versión de Razor que incluye también novedades interesantes para la capa vista, como la integración de la asincronía en procesos de renderizado, flush parciales de páginas, inyección de dependencias sobre las propias vistas, o los nuevos e interesantísimos tag helpers, para mi gusto una de las novedades más interesantes de esta revisión, pues permiten seguir eliminando ruido de las vistas y hacerlas más fáciles de leer y escribir. Podéis ir leyendo algo sobre ello en el blog de Unai.
En general, no se trata de grandes novedades en sí mismas. De hecho, de no ser por los cambios en infraestructura y las modificaciones internas que esto ha acarreado casi casi podría pasar por un incremento menor de versión.
La entrada de ASP.NET 5 tampoco afectará especialmente a aplicaciones escritas con versiones anteriores de los frameworks como MVC 5, pues seguirán ejecutándose sin problema sobre .NET 4.6, el entorno completo. Pero obviamente no podrán beneficiarse de las novedades de ASP.NET 5 si no son migradas.
Y los problemas los encontraremos precisamente en la migración de una aplicación existente MVC 5 o anteriores a MVC 6. Pero observad que la mayor parte de una aplicación MVC convencional podría valer: los controladores seguirán siendo controladores, seguiremos teniendo vistas, y nuestro modelo podría seguir siendo el mismo (dependiendo de cómo lo hayamos construido, claro). Las mejoras al propio framework MVC 6 (view components, controladores POCO, inyección de dependencias de ASP.NET…) son opcionales y podemos usarlas según las necesitemos, pero no nos van a condicionar una migración, exceptuando quizás la unificación con WebAPI, que sí implicaría la adaptación o reescritura de componentes.
Por ello, las cosas más complicadas en una migración vendrán provocadas principalmente por los cambios en la infraestructura, que van a impedir que se pueda de forma directa, “a la copy&paste”. Los múltiples breaking changes nos obligarán siempre a revisar, replantear y reescribir en algunos casos partes de nuestra aplicación como:
En definitiva, si bien los cambios a nivel de plataformas de desarrollo de alto nivel como ASP.NET MVC no son enormes (salvo para WebAPI, descanse en paz ;-)), el replanteamiento de la infraestructura (desde ASP.NET hacia abajo) sí convierte esta nueva oleada de tecnologías en una revolución bastante interesante, probablemente la de mayor calado casi desde el origen del framework, y a la que tendremos que prestar la atención que merece durante los meses venideros.
Publicado en Variable not found.
En futuros posts iremos entrando en mayor detalle, pero de momento vamos a echar un vistazo desde una cierta distancia para tener la idea general sobre dónde estamos y la evolución que vamos a encontrar en las nuevas versiones de tecnologías y plataformas, de forma que podamos ver en qué nos afectará como desarrolladores y, en definitiva, para qué tenemos que irnos preparando.
Disclaimer: estamos aún en una fase en la que algunas cosas pueden cambiar y aún no existe información exhaustiva de muchos detalles, por lo que pueden existir ausencias o imprecisiones. Pero bueno, digo yo que el grueso será más o menos correcto ;-)
Piedras en la mochila
En estos momentos, tenemos una versión de ASP.NET MVC estable, potente, rápida y con una gran comunidad de desarrolladores, tanto noveles como los que encontraron en este framework la alternativa a Webforms que estaban esperando. En los cinco años transcurridos desde la aparición oficial de la primera versión, se ha convertido, sin duda, en el estándar de facto para el desarrollo web basado en tecnologías Microsoft.Sin embargo, ASP.NET MVC aún arrastra una pesada losa heredada de los primeros tiempos de .NET, allá por 2002: el mastodóntico core de ASP.NET, llamado de forma genérica “System.Web”. Este núcleo, que conforma la monolítica infraestructura básica sobre la que corren casi todas las aplicaciones ASP.NET actuales, es enorme, complejo, pesado, muy ligado a tecnologías y servidores, y en muchos aspectos está 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.
MVC sigue irremediablemente atado a System.Web porque internamente lo utiliza en demasiados puntos, y esta dependencia no es buena para la evolución del framework, 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 entornos escalables y servicios en la nube.
OWIN y Katana, de los que hemos hablado por aquí extensamente, 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 WebAPI y SignalR los utilizaron de forma correcta para desvincularse totalmente de System.Web. Esta independencia hizo posible que pudieran alojarse servicios WebAPI o SignalR en cualquier tipo de proceso (aplicación web, servicio windows, aplicación de consola…) y que fueran muy eficientes.
Sin embargo, migrar MVC a los conceptos propuestos por OWIN para no era una tarea sencilla, por lo que la versión 5 continuó atada a System.Web, y el uso de componentes OWIN/Katana se limitaba a la inclusión de middlewares de plataformas ajenas al framework MVC, como Identity Framework.
Los nuevos aires
Y estando así el patio, aparece por el horizonte .NET Core 5 (aka Core CLR), un subconjunto del .NET tradicional escrito desde cero, open source, con vocación multiplataforma (soportado directamente en Linux y Mac), fácilmente distribuible a través de Nuget y optimizado en el mundo web para obtener lo mejor de los entornos servidor, tanto cloud como on premise.
.NET Core 5 no supone, al menos de momento, la desaparición del .NET “clásico”, cuya próxima versión será la 4.6, y que seguirá una línea más continuista con las versiones anteriores. NET Core es sólo una alternativa optimizada para distintos entornos, entre ellos los servidores, pero seremos nosotros los que decidiremos sobre qué infraestructura queremos construir. Pero por poner un ejemplo de las ventajas de Core CLR en el mundo web, se estima que al usarlo una petición típica puede requerir 2Kb de memoria de servidor para ser procesada, frente a los 30Kb que se ocuparía en caso de seguir usando la infraestructura tradicional. Imaginad la repercusión que puede tener esto en cuanto a aprovechamiento de recursos de un servidor.
¿Y qué tiene todo esto que ver con ASP.NET MVC 6? Pues la respuesta está en ASP.NET 5. La próxima versión de ASP.NET será un framework unificado en el que encontraremos tecnologías de desarrollo como MVC, WebPages o SignalR, y que podrá correr sobre .NET 4.6 en Windows/IIS o sobre .NET Core en cualquier plataforma (por supuesto, incluida Windows).
Si todo esto os parece algo confuso, que probablemente lo es, podéis profundizar en este gran post de César de la Torre, de donde he tomado prestado el par de diagramas que veis por aquí porque creo que resumen muy bien la estructura general del nuevo escenario:
Algunas novedades de ASP.NET 5
Siguiendo la línea iniciada por la idea “One ASP.NET” que casi monopolizó las novedades en la última oleada de tecnologías de desarrollo para la web, en ASP.NET 5 crearemos aplicaciones web de cualquier tipo usando una infraestructura común, a la que iremos añadiendo las piezas necesarias para cubrir nuestras necesidades: MVC, SignalR, seguridad, logging, etc. Con esto se consigue una modularidad que hasta ahora era imposible de serie, aunque muy a la filosofía OWIN que ya comenzó a cuajar tiempo atrás; de hecho, si en su momento comprendisteis o trabajasteis con OWIN/Katana la forma de configurar sistemas ASP.NET 5 os resultará bastante familiar.Y dado este nuevo contexto, el primer cambio que encontraremos en MVC 6 y el resto de frameworks es que no hay ningún tipo de vínculo con componentes de ASP.NET clásico (System.Web), lo cual incide en muchos aspectos generales, como el propio tamaño del framework o su la velocidad de ejecución, pero también en detalles que nos afectarán a la hora de desarrollar.
Por ejemplo, el global.asax dejaba de tener sentido como tal, pues en su interior encontrábamos código vinculado a eventos de objetos propios de ASP.NET clásico. El código de inicialización, de nuevo, será más parecido al de sistemas basados en OWIN y la implementación de funcionalidades trasversales como un logging las haremos a base de construir middlewares. Tampoco será ya necesario el archivo Web.config, que durante tantos años ha servido para configurar tanto el servidor como las aplicaciones. Los archivos de configuración de los proyectos han cambiado a un modelo mucho más potente y flexible que estudiaremos en su momento.
Claro, y puestos a retocar infraestructura, se ha aprovechado para poner al día algunas asignaturas pendientes en ASP.NET, como la inyección de dependencias, que ahora vendrá integrada de serie y aplicada internamente en todos los frameworks, o el uso de la asincronía de forma generalizada. Si hasta ahora habéis ignorado los célebres async/await,
Task
y otras hierbas similares, me temo que tendréis que iros poniendo al día si queréis sacar provecho de las tecnologías que se avecinan.Roslyn es otro gran protagonista en el nuevo ASP.NET, tanto que incluso está dispuesto a cambiar la forma en que desarrollamos. El ciclo “Editar>Salvar>Ejecutar>Parar>Editar…” se va a simplificar porque ya no hará falta compilar de forma explícita, será Roslyn el que se encargue por detrás de esta tarea. Por ejemplo, si cambiamos el código de un controlador bastará con recargar la página en el navegador para ver el resultado, no habrá que parar la ejecución y volver a empezar. Como podréis suponer, esto no sólo afecta al workflow del proceso de desarrollo, sino que además posibilita otros escenarios de despliegue que hasta ahora no existían. Es un cambio fuerte para los que llevamos años con ASP.NET, pero seguro que podemos acostumbrarnos ;-)
En cuanto al tooling, también cambia bastante la cosa. Todas las herramientas de build y ejecución pueden lanzarse fácilmente desde la línea de comandos, supongo que porque se trata del común múltiplo en un contexto multiplataforma. Así, es posible realizar estas tareas exactamente de la misma forma independientemente de si estamos en Windows, Mac o Linux. Pero ojo, esto no significa que tengamos que usar oscuros comandos continuamente en nuestro día a día, seguro que Visual Studio y otras herramientas proporcionarán interfaces más similares a los que estamos acostumbrados a utilizar, aunque probablemente determinadas acciones estarán accesibles exclusivamente, al menos de momento, desde línea de comandos.
Puede usarse cualquier tipo de editor para programar aplicaciones ASP.NET, e incluso existen proyectos como Omnisharp para llevar utilidades como intellisense o herramientas de refactorización a editores ajenos a Microsoft como Brackets, Emacs o Sublime Text, desde cualquier sistema operativo. De nuevo, la idea es que el desarrollo de aplicaciones ASP.NET pueda hacerse desde cualquier plataforma y herramienta, y dejar que el desarrollador decida si prefiere alejarse de Windows/Visual Studio.
De la misma forma, y siguiendo una tendencia que se apunta desde hace ya algún tiempo, Visual Studio 2015 se alinea y hace uso de herramientas ya asentadas en otras comunidades de desarrolladores web, como el gestor de paquetes de frontend Bower o el sistema de automatización Grunt. Esto, unido a la necesidad de dar un poco de coherencia a las necesidades de mejora en la organización interna de los propios proyectos, tiene también su incidencia en la estructura de carpetas de las soluciones, que seguirán a partir de ahora un esquema más cercano a la realidad del desarrollo web.
Observad que todo lo que estamos comentando son cambios y novedades generales de la infraestructura de ASP.NET 5 y, por tanto, aplicable para todos los frameworks que se construyan sobre ella. Nada específico de MVC hasta el momento.
Y entonces… ¿qué cambios concretos encontraremos en ASP.NET MVC 6?
Pues en primer lugar, encontraremos los cambios derivados de todas las novedades introducidas en ASP.NET 5 anteriormente comentados:- Posibilidad de crear aplicaciones MVC sobre .NET 4.6 o Core CLR.
- La estructura de los proyectos cambiará.
- Cambios en el workflow de desarrollo debido a la compilación automática. Si queremos.
- Tendremos nuevas fórmulas para configurar los proyectos y aplicaciones.
- En la mayoría de los casos no será necesario usar contenedores IoC para inyectar dependencias, puesto que ASP.NET ya incluirá este mecanismo de serie.
- Desplegable en cualquier plataforma (Windows, Linux, Mac), y ejecutable en cualquier tipo de host (IIS u otro servidores web, servicios del sistema operativo, aplicaciones…)
A lo bestia, podríamos decir que MVC se ha comido a WebAPI. Un ejemplo práctico es que ya no existirá la clase
ApiController
, sino que su comportamiento habrá sido absorbido por los habituales controladores MVC (que por cierto, podrán ser objetos POCO puros). Esto implica algunas modificaciones al sistema de routing, al binding, a los mecanismos de negociación de contenidos, y a la forma de retornar resultados desde las acciones, pero estos cambios afectarán principalmente a las aplicaciones WebAPI, las basadas exclusivamente en MVC sufrirán poco debido a esta unificación.Otra novedad interesante es la introducción de los View Componentes, un nuevo tipo de elementos reutilizables que permiten realizar acciones y componer porciones de vista de forma más eficiente y mejor integrada que las conocidas acciones hija o vistas parciales. Lo veremos en mayor detalle más adelante, pero si queréis ir echando un vistazo, el amigo Eduard escribió sobre ellos hace unos meses.
Con MVC6 encontraremos también una nueva versión de Razor que incluye también novedades interesantes para la capa vista, como la integración de la asincronía en procesos de renderizado, flush parciales de páginas, inyección de dependencias sobre las propias vistas, o los nuevos e interesantísimos tag helpers, para mi gusto una de las novedades más interesantes de esta revisión, pues permiten seguir eliminando ruido de las vistas y hacerlas más fáciles de leer y escribir. Podéis ir leyendo algo sobre ello en el blog de Unai.
En general, no se trata de grandes novedades en sí mismas. De hecho, de no ser por los cambios en infraestructura y las modificaciones internas que esto ha acarreado casi casi podría pasar por un incremento menor de versión.
Pero lo importante, ¿me dolerá, doctor?
Pues depende, amigo. Para las nuevas aplicaciones, probablemente ASP.NET 5 y MVC 6 serán las plataformas naturales sobre la que trabajaremos siempre que el entorno de desarrollo y explotación nos lo permitan. Las novedades de ASP.NET y MVC comenzaremos a usarlas de forma progresiva y seguro que en poco tiempo nos haremos con el nuevo entorno. En este sentido, no creo que el aterrizaje de MVC 6 sea demasiado doloroso.La entrada de ASP.NET 5 tampoco afectará especialmente a aplicaciones escritas con versiones anteriores de los frameworks como MVC 5, pues seguirán ejecutándose sin problema sobre .NET 4.6, el entorno completo. Pero obviamente no podrán beneficiarse de las novedades de ASP.NET 5 si no son migradas.
Y los problemas los encontraremos precisamente en la migración de una aplicación existente MVC 5 o anteriores a MVC 6. Pero observad que la mayor parte de una aplicación MVC convencional podría valer: los controladores seguirán siendo controladores, seguiremos teniendo vistas, y nuestro modelo podría seguir siendo el mismo (dependiendo de cómo lo hayamos construido, claro). Las mejoras al propio framework MVC 6 (view components, controladores POCO, inyección de dependencias de ASP.NET…) son opcionales y podemos usarlas según las necesitemos, pero no nos van a condicionar una migración, exceptuando quizás la unificación con WebAPI, que sí implicaría la adaptación o reescritura de componentes.
Por ello, las cosas más complicadas en una migración vendrán provocadas principalmente por los cambios en la infraestructura, que van a impedir que se pueda de forma directa, “a la copy&paste”. Los múltiples breaking changes nos obligarán siempre a revisar, replantear y reescribir en algunos casos partes de nuestra aplicación como:
- La propia estructura de proyecto.
- La configuración (lo que antes teníamos en el web.config).
- El routing.
- Código de inicialización (lo que hasta ahora teníamos en el
Application_Start
) o eventos de aplicación. - El sistema de inyección de dependencias.
- Módulos, handlers y otros especímenes de esta fauna.
- Todos los controladores WebAPI, debido a la fusión con MVC.
- Si pensamos usar Core CLR y en nuestra aplicación hacemos uso de características no soportadas (recordar que se trata de un subconjunto de .NET, no incluye todo), tendremos que reescribirlas usando las alternativas que tengamos disponibles.Y si no las hay, tendremos un problema.
- Lo mismo ocurrirá si hacemos uso de componentes de terceros que tengan dependencias a componentes no soportados.
- Si usamos temas algo avanzadillos y hemos sustituido o extendido componentes internos del framework por personalizaciones podríamos encontrar también algunos problemas, pues muchos se han reescrito para dar cabida a los cambios en infraestructura.
- … y seguro que se me olvidan cosas y que conforme vayamos conociendo mejor MVC 6 iremos descubriendo algunos temas conflictivos más.
En definitiva, si bien los cambios a nivel de plataformas de desarrollo de alto nivel como ASP.NET MVC no son enormes (salvo para WebAPI, descanse en paz ;-)), el replanteamiento de la infraestructura (desde ASP.NET hacia abajo) sí convierte esta nueva oleada de tecnologías en una revolución bastante interesante, probablemente la de mayor calado casi desde el origen del framework, y a la que tendremos que prestar la atención que merece durante los meses venideros.
Publicado en Variable not found.
6 Comentarios:
Las mejoras planteadas son considerables y necesarias. Nos vamos a encontrar con un "framework" muy avanzado que ilusiona por el enorme futuro que ofrece. Estimo que va a pegar un bocado muy importante a "frameworks" de la competencia, especialmente Java, y hay muchas posibilidades de que ASP.NET MVC se convierta en el gran dominador de su mercado.
Ante esta batería de novedades interesantísimas sólo me surge una duda: ¿cuándo está previsto que salga la versión definitiva o, al menos, la "release candidate"? Es un aspecto importante porque tengo algunos proyectos en cola y valoraría aplazar el comienzo de su desarrollo si no supone esperar mucho.
Hola, Balder!
Que yo sepa no hay fechas todavía. Y la verdad es que estaría bien tener al menos una referencia, porque el caso en el que te encuentras es muy común y crea dudas sobre cuál es la decisión correcta en este momento.
En cualquier caso, si tienes que iniciar nuevos proyectos puedes hacerlos con mvc5, pero teniendo cuidado y estudiando un poco de lo que se conoce de mvc6 y su entorno para poder migrar más adelante de forma poco traumática, o al menos lo menos dolorosa posible.
Gracias por comentar!
Hola José, que excelente post, muchas gracias. todos estos cambios son una revolución como dices, y todos esto nos tiene que impactar a todos, de forma positiva aunque podremos tener algunos problemas a la hora de migrar aplicaciones, vale la pena hacerlo, el hecho de desacoplar Asp.net MVC de System.Web es un gran punto a favor, ya quiero ver la mejora en el performance de las aplicaciones, al igual que el selfHosting y el despliegue en múltiples plataformas. Estos son cambios que están partiendo la historia de Microsoft y todos los DEvelopers en dos.
saludos!
Sin duda valdrá la pena :-)
Muchas gracias por comentar, Gustavo!
Hay alguna fecha estimada para el lanzamiento del nuevo framweork y MVC 6
Que yo conozca todavía no hay fechas, Camilo :)
Enviar un nuevo comentario