¡Bueno, pues parece que esto se mueve! Hace unos días ha sido publicada la Release Candidate de ASP.NET MVC 4 coincidiendo con la liberación de Windows 8 Release Preview y Visual Studio 2012 Release Candidate (que, de hecho, incluye de serie MVC 4 RC).

Y como viene siendo costumbre, vamos a dar un repaso a todo lo que encontramos en esta nueva entrega, que presumiblemente será la última (bueno, o penúltima, nunca se sabe) antes de la versión definitiva. Eso sí, para no hacer el post demasiado largo nos centraremos exclusivamente en los cambios más destacables y visibles que se han introducido respecto a la versión beta.

1. Cambios en plantillas de proyecto

En la versión RC de MVC 4, al crear un nuevo proyecto encontramos plantillas ya conocidas de versiones y revisiones anteriores del framework:

• Empty
• Internet Application
• Intranet Application
• Mobile Application
• Web API

Adicionalmente, aparece una nueva plantilla, llamada Basic, que podríamos decir que es un término medio entre la plantilla vacía y la aplicación para internet. En ella se incluyen sólo unas vistas shared (el archivo _viewstart, un _layout y la página estándar de error), los scripts, recursos gráficos y estilos utilizados en ellas, y la inicialización de bundles, rutas y filtros. Nada de los célebres HomeController o AccountController y sus vistas asociadas.

Otra cosa curiosa: recordaréis que la versión Beta traía “soporte experimental” para Single Page Applications, o Aplicaciones de Página Única. Pues bien, se ve que ahora han optado por no continuar con este experimento y en la RC de MVC 4 han eliminado la plantilla para proyectos SPA, que seguirá evolucionando pero de forma independiente a MVC 4. Casi que mejor así ;-)

También ha sido eliminado de la plantilla Internet Application el sistema de autenticación basado en Ajax que quedaba tan molón, pero que complicaba bastante el código del AccountController.

2. Nueva convención de ubicación de archivos (App_Start)

El código de inicialización de las aplicaciones cada vez va tomando más volumen; incluso en las aplicaciones  más simples nos encontramos con la necesidad de definir rutas, bundles, filtros globales, inicialización del acceso a datos, mapeos para inyección de dependencias, y un largo etcétera.

Introducir todo este código en el global.asax.cs no es una buena idea, y como el framework no aportaba ninguna sugerencia al respecto, al final acabábamos poniéndolo cada uno donde nos parecía oportuno.

Pues bien, a partir de hora, todo el código de inicialización de las aplicaciones se encontrará por defecto en la carpeta App_Start. De hecho, en las plantillas no vacías ya vemos cómo se incluye la definición de rutas, filtros o bundling. Por otra parte, en el global.asax.cs sólo encontraremos las correspondientes llamadas a dada uno de estos inicializadores.

3. Nuevas referencias

Examinando las referencias de los distintos tipos de proyecto encontramos nuevos ensamblados, que corresponden con los siguientes componentes:

• Json.NET (en el ensamblado Newtonsoft.json) que es ahora utilizado como formateador JSON por WebAPI, sustituyendo las funcionalidades proporcionadas  tradicionalmente por System.Json.dll.
• WebGrease, que es el nuevo sistema de optimización de scripts, css e incluso imágenes, que es ya utilizado por el sistema de bundling del paquete System.Web.Optimization.
• Antl3.Runtime es la adaptación para .NET del runtime del analizador de gramáticas ANTLR (Another Tool for Language Recognition). Es una dependencia de WebGrease.
• Entity Framework 5.0 RC, que aporta toda la infraestructura de acceso a datos que necesitamos para nuestras aplicaciones. Esta revisión incorpora múltiples novedades: tipos enumerados, tipos espaciales, TVFs, mejoras en el diseñador (VS2012), etc. Puedes leer más sobre las novedades incorporadas en EF 5 RC aquí.

4. Avances en WebAPI

WebAPI, el nuevo framework que tanto entusiasmo está provocando, sigue evolucionando y mejorando con esta versión. De hecho, diría que es uno de los puntos que más cambios han sufrido, al menos visiblemente, desde su aparición en la versión beta de ASP.NET MVC 4. Las novedades de mayor calado son las siguientes:

• Los métodos de nuestro API que retornen un IQueryable<T> deben decorarse con el atributo [Queryable] para que esté permitido componer consultas sobre ellos.
• Es posible registrar de forma global una clase que implemente ITraceWriter para utilizarla como punto único de trazado y diagnóstico, en la que podemos registrar los eventos que vayan produciéndose en el sistema.
• También es posible, usando el método extensor RegisterForDispose(), asociar a un Request un objeto IDisposable, de forma que será liberado automáticamente cuando termine de ser procesada la petición. Muy interesante para gestionar de forma correcta el ciclo de vida de los objetos.
• Podemos utilizar el servicio ApiExplorer de nuestros Api Controllers para obtener metainformación en tiempo de ejecución sobre los servicios, lo que da opción para crear sistemas de ayuda o clientes dinámicos (por ejemplo para pruebas).
• Ha sido simplificada la forma de solicitar y responder objetos con negociación de contenidos. Ahora, por ejemplo, usaremos el método extensor CreateHttpResponse<T> para retornar objetos desde nuestros métodos con control total sobre la respuesta. Las clases que usábamos antes, HttpRequestMessage<T> y HttpResponseMessage<T>, han sido eliminadas.
• Se han introducido métodos específicos en la propiedad Headers para obtener las cookies asociadas a una petición y para añadirlas a una respuesta.
• Y muchos otros cambios internos que podéis consultar en el documento de notas de la revisión.

La verdad es que algunos de los avances que han sido incorporados tienen también sentido para controladores MVC convencionales y no sólo para WebAPI. Espero que estas dos líneas paralelas serán unificadas vistas a la versión definitiva, porque la verdad es que no le veo demasiado sentido a mantenerlas separadas. De hecho, en estos momentos resulta un poco caótico que existan clases duplicadas en ensamblados distintos (System.Web.Http para WebAPI y System.Web.Mvc para ASP.NET MVC).

Por poner un ejemplo, el filtro HttpGet podemos encontrarlo en ambos namespaces, y dependiendo del contexto en que lo necesitemos (WebAPI o MVC) debemos usar uno u otro, y lo mismo ocurre con muchos otros elementos, tanto internos como externos. Esto puede provocar muchos fallos difíciles de detectar dado que las clases usadas dependerán en muchos casos del namespace usado en nuestro código.

En fin, espero que esto quede unificado en algún momento…

5. Cambios en el sistema de bundling

Hasta ahora, el mismo sistema de bundling venía de serie con lógica para incluir de forma automática los scripts de uso más habitual en aplicaciones web usando métodos como EnableDefaultBundles(). Sin embargo, los desarrolladores no podíamos modificarla porque se incluía en los propios componentes de la biblioteca de optimización.

A partir de la RC, la configuración de los bundles por defecto se realiza de forma explícita en nuestra aplicación. En la nueva carpeta /App_Start encontramos la clase BundleConfig, en cuyo método estático RegisterBundles() se encarga de ello, y obviamente podemos modificarlo a nuestro antojo:

public class BundleConfig
{
    public static void RegisterBundles(BundleCollection bundles)
    {
        bundles.Add(new ScriptBundle("~/bundles/jquery").Include("~/Scripts/jquery-1.*"));
 
        bundles.Add(new ScriptBundle("~/bundles/jqueryui").Include("~/Scripts/jquery-ui*"));
 
        bundles.Add(new StyleBundle("~/Content/css").Include("~/Content/site.css"));
 
        [...]

Respecto a revisiones anteriores de MVC 4, se ha simplificado un poco la sintaxis para crear bundles, asociarlos al componente encargado de realizar su transformación, y especificar los recursos a incluir en el paquete.

Por otro lado, las referencias desde las vistas a los distintos bundles también se han simplificado y se generan de forma automática utilizando clases estáticas provistas desde el ensamblado System.Web.Optimization:

        @Styles.Render("~/Content/css")
        @Scripts.Render("~/bundles/jquery")

Otro aspecto muy interesante es que dependiendo de si estamos ejecutando la aplicación en modo release o debug los bundles serán compactados y minimizados o no, para facilitar la depuración.

6. Cambios en scaffolding

También se han introducido cambios relativos a la creación de controladores:

• Ahora es posible añadir un controlador sobre cualquier carpeta del proyecto pulsando el botón derecho sobre ella. Esto facilitará la organización de aplicaciones donde convivan controladores MVC y controladores WebAPI. 
• Se ha eliminado la plantilla de controlador Ajax grid que encontrábamos en la beta del producto. El motivo, según indican en el documento de notas de la revisión, no es otro que dejar al mínimo la lista de plantillas disponibles. 
• Se ha creado una nueva plantilla para controladores WebAPI basados en una entidad y contexto de datos de Entity Framework.

Por otra parte, las famosas recetas (recipes) han sido finalmente eliminadas de MVC 4 y serán incorporadas como parte de Nuget. De hecho, si lo pensamos un poco, la idea inicial tiene bastante más que ver con Nuget que con MVC, así la decisión creo que es bastante correcta.

Y hasta aquí llegamos. Tenemos más detalles descritos en el documento de notas de la revisión, que os recomiendo que leáis, y seguro iremos descubriendo muchos otras novedades durante las próximas semanas.

Enlaces:

• Sitio web oficial
• Descarga (Visual Studio & Visual Web Developer 2010 SP1)
• Notas de la revisión

Publicado en Variable not found.