¡ASP.NET MVC 4 Beta disponible!

ASP.NET MVC 4 betaBueno, supongo que ya os habréis enterado, pero por si acaso os lo comento: varios meses después de aparecer la última revisión pública, hoy mismo se ha publicado la beta de ASP.NET MVC 4 (para Visual Studio o Visual Web Developer 2010) que ya podemos ir descargando y probando para ir haciéndonos a la idea de lo que se nos viene encima.

Eso sí, si vais a hacerlo desinstalad la developer preview antes de nada, tal y como se indica en el documento de notas de la revisión. Si tenéis instalado ASP.NET MVC 3 o anteriores, tranquilos, que seguirán funcionando con normalidad tras instalar esta beta (¡o eso aseguran! ;-))

El producto aún está recién salido del horno, así que seguro que durante los próximos días seguimos descubriendo novedades interesantes en esta beta, pero os voy a ir comentando algunas de las que me he encontrado en un primer contacto.

1. Nuevas plantillas

En primer lugar, al crear un proyecto ASP.NET MVC 4 Beta nos encontramos con las siguientes plantillas:
  • Empty, Internet Application y Intranet Application, ya conocidas de versiones anteriores del framework.
  • Mobile application, que ya comentamos en el post en el que desmenuzábamos la developer preview de MVC 4, allá por el mes de septiembre.
  • ASP.NET Web API, una de las novedades de esta entrega, un interesante framework que facilita creación de aplicaciones que publican servicios y datos utilizando HTTP.
  • Single Page Application, otra novedad de la beta, que incluye un conjunto de herramientas y componentes específicos para implementar aplicaciones en una única página web, mediante el uso intensivo de Ajax.
Plantilla de proyectos MVC 4 beta

2. ASP.NET Web API

ASP.NET Web API es un nuevo framework que ofrece una fórmula muy sencilla para exponer determinadas funciones o datos de nuestras aplicaciones mediante el uso de toda la potencia que nos ofrece el protocolo HTTP, y muy apropiada para interfaces de tipo REST.

Esto, aunque ya podíamos conseguirlo con las versiones anteriores del framework, con ASP.NET Web API se ha simplificado bastante, permitiéndonos ir más al grano en nuestros desarrollos y olvidarnos de detalles de menor nivel. Las principales características de Web API son las siguientes:
  • Integración con el sistema de routing, de forma que tenemos control total sobre las URL de acceso a los servicios, y la posibilidad de usar mecanismos con los constraints.
  • Negociación de contenidos, de forma que cliente y servidor pueden acordar formatos de intercambio de información. De fábrica vienen con soporte XML, Json y otros, aunque es posible añadir nuevos formatos o incluso modificar la forma en que la negociación se produce.
  • Soporte de model binding y validación, mecanismos ya conocidos por los desarrolladores de MVC, que sirven para convertir la información disponible en las peticiones en objetos del CLR.
  • Soporte de filtros de acción, permitiendo la introducción de comportamientos trasversales cuya ejecución se realizará previa y posteriormente a la ejecución de acciones.
  • Composición de consultas, que ofrece la posibilidad de realizar peticiones directas según las convenciones OData de una forma realmente simple, retornando objetos IQueryable<T>.
  • Otras características, como la facilidad para la realización de pruebas unitarias, la resolución de dependencias, o la posibilidad de usar self-hosts para la publicación de servicios.
Puedes aprender más sobre ASP.NET Web API en la web oficial del producto.

En la práctica, lo que vamos a notar es que al crear un proyecto ASP.NET MVC 4 encontraremos una plantilla llamada “Web API”. Con ella podemos hacernos rápidamente una idea de las posibilidades que nos ofrece esta nueva característica.

La idea consiste en crear controladores “especiales” que no heredan del tradicional Controller, sino de la nueva clase ApiController. Sus acciones, a diferencia de las habituales cuando programamos con el framework, es que se nombran en función del verbo HTTP al que atenderán; es decir, existirá una acción GetXXX() para manejar las peticiones HTTP GET, otra acción PostXXX() para el verbo POST, etc. Para la ejecución de estas acciones se utilizan los mecanismos habituales de binding para poblar los parámetros, lo que implica, por ejemplo, que podemos utilizar parámetros complejos en las mismas, o data annotations para especificar restricciones.

Curiosamente, las “XXX” pueden ser cualquier cosa; el framework simplemente buscará que el nombre del método comience por Get, Post, o el verbo que sea, a la hora de determinar la acción a ejecutar.

El siguiente ejemplo muestra la implementación por defecto para los verbos habituales; observad que el retorno en las acciones de consulta son directamente los objetos a enviar al cliente serializados como JSON.
public class PruebaController : ApiController
{
    // GET /api/prueba
    public IEnumerable<string> Get()
    {
        return new string[] { "value1", "value2" };
    }
 
    // GET /api/prueba/5
    public string Get(int id)
    {
        return "value";
    }
 
    // POST /api/prueba
    public void Post(string value)
    {
    }
 
    // PUT /api/prueba/5
    public void Put(int id, string value)
    {
    }
 
    // DELETE /api/prueba/5
    public void Delete(int id)
    {
    }
}
Para facilitar la creación de estas clases, se ha incorporado en el diálogo de creación de controladores dos nuevas plantillas, “Empty API Controller” y “API Controller with empty read/write actions”. El resultado de utilizar la segunda de ellas es el código que hemos visto anteriormente.

Nuevas plantillas de controlador

Otro aspecto que hace posible el acceso exterior a las API definidas según esta vía es que en el global.asax encontramos registrada la siguiente ruta:
    routes.MapHttpRoute(
        name: "DefaultApi",
        routeTemplate: "api/{controller}/{id}",
        defaults: new { id = RouteParameter.Optional }
    );
De esta forma, una petición como POST /api/prueba sería dirigida hacia la acción Post() del controlador PruebaController que hemos visto anteriormente, o GET /api/prueba/5 invocaría la acción Get() de PruebaController, suministrándole el valor 5 en el parámetro id.

¿Y era necesario crear una plantilla de proyecto nada más que para eso? Pues no. De hecho, este mecanismo viene también incluido de serie en la plantilla “Internet Application”, donde podemos encontrar ya la ruta registrada. Es decir, en una aplicación normal simplemente hemos de crear nuestros controladores ApiController y las tendremos nuestros API publicados de forma inmediata.

Por último, comentar que ASP.NET Web API no sólo incluye componentes para implementar el lado servidor, también se ofrecen nuevos componentes que facilitan el acceso a servicios desde clientes .NET.

3. Single Page Applications (SPA)

Las aplicaciones de página única son aquellas que realizan todas sus funcionalidades sin apenas navegación entre páginas del sitio web, y usan de forma intensiva scripting y Ajax. Muchos servicios actuales, como Twitter y Facebook, utilizan este enfoque, logrando una gran sensación de dinamismo y modernidad en los interfaces de usuario.

Hasta ahora no disponían de un soporte especialmente potente en MVC 3 y anteriores… por no decir que no tenían soporte alguno. Había que gestionarlo todo de forma manual, como nos mostraba el amigo Eduard Tomás en este magnífico post: envío de datos al servidor, actualizaciones parciales de página, recepción de datos, control del botón “atrás” del navegador… en fin, no es una tarea sencilla.

MVC 4 Beta ha incluido, palabras textuales, “soporte experimental” para la creación de aplicaciones de este tipo, incluyendo los siguientes componentes:
  • Bibliotecas de script que permite interactuar con datos cacheados localmente,
  • Componentes adicionales de Web API con soporte para Unit of Work y DAL.
  • Una nueva plantilla de proyecto (“Single page applications”) con herramientas de para generar rápidamente andamiaje.
Puedes aprender más sobre Single Page Applications en ASP.NET en la web oficial del producto.

La nueva plantilla de proyectos, llamada “Single page applications”, que en verdad tiene bastante poca chicha, simplemente incluye un buen puñado de scripts en el proyecto y da algunas indicaciones que nos permiten poner en marcha el esqueleto de una interfaz CRUD usando SPA en unos cuantos clics.

Como podéis ver, esas instrucciones se encuentran en comentarios en una clase del Modelo:
// To quickly get started building a Single Page Application based on the following model
// class, build your solution (Build -> Build Solution), then right-click on the "Controllers" folder, 
// choose Add -> Controller, and set the following options:
//
//  * Controller name:    TasksController
//  * Template:           Single Page Application with read/write actions and views, using Entity Framework
//  * Model class:        TodoItem (MvcSPAApplication.Models)
//  * Data Context class: Choose <New data context...>, then click OK
//
// Afterwards, launch your application (Debug -> Start Debugging), then browse to the URL /Tasks
// For more information, see http://go.microsoft.com/fwlink/?LinkId=238343
 
public class TodoItem
{
    public int TodoItemId { get; set; }
    [Required]
    public string Title { get; set; }
    public bool IsDone { get; set; }
}
Si seguimos las instrucciones, lo que veremos en ejecución es una pantalla de introducción de datos de elementos TodoItem , funcionando en modo SPA, como la que podéis observar en la siguiente captura:

SPA en ejecución

Vamos a seguir paso a paso las instrucciones y comentamos lo que va ocurriendo en el proyecto.

Primero, creamos nuestro controlador TasksController utilizando la nueva plantilla “Single Page Application with read/write actions and views using Entity Framework”. Creo que esta extensa descripción no deja mucho lugar a dudas de lo que pretendemos generar, no?


Generación del controlador

Observad también que hemos indicado que deseamos generar una clase de contexto de datos, a la que vamos a llamar, en un alarde de originalidad, DataContext. El resultado de esta acción es la inclusión de un buen número de elementos en el proyecto.

En primer lugar, se añade a nuestra carpeta /models el contexto de datos, una clase similar a la que podemos generar desde MVC 3 en escenarios similares de creación de controladores: heredando de DbContext, y con una propiedad pública DbSet<TodoItem> para representar al conjunto de elementos en el almacén. Como viene siendo costumbre, se utiliza EF Code First para el acceso a datos.

Como era de esperar, en la carpeta /controllers encontraremos un controlador específico, TaskController, para cargar la página principal, desde donde realizaremos el mantenimiento de entidades TodoItem, que lo único que hace es retornar la vista. Será ésta (es decir, en cliente) donde se implementará la mayor parte de la lógica. El código de este controlador es el siguiente:
    public class TasksController : Controller
    {
        public ActionResult Index()
        {
            return View();
        }
    }
Dicha vista incluye toda la lógica de control, y realiza peticiones al servidor para actualizar o consultar los datos (entidades TodoItem) que necesita en cada caso. Estas peticiones, iniciadas mediante scripting desde el lado cliente, atacan a un controlador especial llamado DataController, que es generado automáticamente en la carpeta /controllers, y que se encuentra definido en los siguientes archivos:
  • DataController.cs, es una clase parcial donde podemos incluir el código genérico del controlador, aquél que sea común a todas las peticiones de datos que podamos recibir. En este caso hereda de DbDataController<DataContext>.
  • DataController.TodoItem.cs, es una porción de la clase parcial anterior que implementa métodos CRUD (GetTodoItem(), InsertTodoItem(), UpdateTodoItem(), y DeleteTodoItem()) sobre el elemento que hemos indicado anteriormente al generar el controlador. Habrá una clase similar a esta para cada entidad de las que generemos el interfaz de mantenimiento utilizando esta vía; es decir, que igual que tenemos DataController.TodoItem.cs para implementar los servicios relativos a la entidad TodoItem, tendremos DataController.Friend.cs para la gestión de entidades Friend, DataController.Product.cs para Product, etc. En definitiva, que dentro del controlador DataController tendremos métodos para manipular los datos de las entidades que necesitemos desde nuestro interfaz SPA.
En cuanto a la vista, es obvio que en /Views/Tasks encontraremos la vista principal de la funcionalidad de gestión. Si abrimos el archivo, lo primero que llama la atención es que en lugar de encontrarnos una maraña de código terrible para implementar la lógica de control y presentación del sistema, lo que podemos observar es bastante limpio gracias al uso de Knockout. Esta biblioteca open source es un framework de scripting que utiliza el patrón MVVM (Model-View-ViewModel) para crear interfaces dinámicos y bien estructurados, poniendo un poco de orden en la normalmente caótica capa cliente.

Archivos de vista añadidosTambién en la carpeta de vistas encontramos los siguientes archivos:
  • _Editor.cshtml, una vista parcial que define cómo será el interfaz de edición de la entidad, es decir, el formulario que aparecerá cuando vayamos a crear o editar un objeto.
  • _Grid.cshtml, la maquetación de la rejilla de datos.
  • _Paging.cshtml, la composición del mecanismo de paginación del grid.
  • _SpaLayout.cshtml, en la carpeta /Views/Shared, que es un layout específicos para este tipo de páginas (SPA). Lo único destacable del mismo es que incluye bastantes bibliotecas de script, necesarias para que funcione todo el invento.
La verdad es que el funcionamiento hay que estudiarlo a fondo para hacerse con el control de lo que ocurre por detrás. A priori, da la sensación de excesivo automatismo, y no queda claro los puntos de extensibilidad o personalización más allá del retoque de las vistas parciales generadas, puesto que se utilizan scripts generados automáticamente (como la clase ViewModel en creada en javascript a partir de la entidad del Modelo que estamos gestionando, en este caso TodoItem), upshot.js, knockout.js, nav.js., history.js, adaptadores upshot-knockout… en fin, demasiados scripts como para poder entender rápidamente el funcionamiento.

A ver si aumenta la información disponible en el sitio web, le echamos un poquito más de tiempo, y podemos llegar a verle sentido al esfuerzo que han realizado en esta dirección…

4. Cosas que más o menos siguen igual

No dudo que habrán mejorado internamente, pero sí que hay bastantes cosas que al primer vistazo siguen aproximadamente como en la developer preview:
  • El look mejorado de la plantilla de proyecto por defecto, bastante más bonita que la clásica que lleva con nosotros desde el principio de los tiempos del framework MVC, además de incluir de serie determinadas funcionalidades basadas en Ajax.
  • El DisplayMode, que sabéis que es esa característica permite crear una única aplicación y renderizar una u otra vista en función del dispositivo o las condiciones que deseemos. Siguen siendo válidos los mecanismos de switching de vistas, o el browser overriding que ya describimos cuando apareció la developer preview.
  • Seguimos teniendo la plantilla para creación de sitios específicos para móviles usando jQuery Mobile.
  • El componente de bundling (compactación y minimización) de archivos de script y de estilos, del que ya estuve hablando por aquí hace algún tiempo, sigue estando presente, y de hecho en la plantilla de proyectos se incluye por defecto la configuración del mismo (en el global.asax) y las referencias a los recursos compactados en los layouts.
  • Se siguen utilizando por defecto los proveedores universales de membresía, roles, profiles y sesiones.
  • Se mantiene compatibilidad con el SDK 1.5 de Azure de septiembre de 2011.
  • Eso sí, sigo sin ver ni rastro de las famosas recetas (recipes), que tanto se destacaron en el roadmap del producto. Ciertamente hay un SDK de recipes en Nuget, pero pocas recetas ya implementadas para echarnos a la boca.
En definitiva, se trata de un pasito más hacia la versión definitiva de ASP.NET MVC 4. ¡A ver qué sorpresas nos encontramos por el camino! ;-)

Enlaces:

Publicado en: Variable not found.
Published 16/2/2012 21:04 por José M. Aguilar
Comparte este post:
http://geeks.ms/blogs/jmaguilar/archive/2012/02/16/161-asp-net-4-beta-disponible.aspx

Comentarios

# Usando ASP.NET Web API con ASP.NET Web Forms

Revisando el siguiente articulo que hablaba sobre el uso de ASP.NET Web API y ASP.NET WebForms, me entusiasmé

Saturday, February 25, 2012 12:46 AM por Chalalo Land