Ya está disponible ASP.NET MVC 1.0 Release Candidate

Hemos publicado ASP.NET MVC 1.0 Release Candidate. Aquí podéis descargarlo (nota: el enlace puede dejar de funcionar, si os ocurre esto esperad unos minutos y volved a intentarlo). Funciona tanto en Visual Studio 2008 como en Visual Web Developer 2008.

Esta es la última release de ASP.NET MVC que publicaremos antes de la versión final. Esperamos publicar ASP.NET MVC 1.0 a finales de este mes.

Además de corregir algúnos bugs, esta release incluye nuevas características. También incluye algunas mejoras de las características ya existentes según el feedback que nos habéis enviado. Por favor, leed las notas de esta release para ver la lista completa de cambios. Estas notas incluyen instrucciones muy detalladas sobre cómo actualizar las aplicaciones que se hayan hecho con la Beta.

Mejoras en las herramientas de Visual Studio.

Esta RC incluye varias mejoras en las herramientas para Visual Studio. Entre estas características están:

Comando Add Controller

Con Ctrl-M, Ctrl-C en un proyecto ASP.NET MVC, o con el botón derecho en el directorio /controller y selecccionando el menú “Add->Controller” podemos crear nuevas clases controladoras:

Aparecerá el diálogo “Add Controller” que nos permitirá indicar el nombre de la nueva clase controlador, y podremos indicarle si queremos que le añada directamente los métodos CRUD:

Si le damos al botón Add la clase se creará y se añadirá al proyecto:

Comando Add View

Con Ctrl-M, Ctrl-V en un método de acción de una clase controladora, o con el botón derecho en dicho método, si seleccionamos el menú “Add View” nos permitirá crear nuevos templates para vistas:

Aparecerá el diálogo “Add View” que nos permitirá nombrar y crear una nueva vista (se prevee el nombre de la vista que se generará en base a opciones de convención). Nos permitirá crear vistas “vacías”, o generar el código básico para la vista dependiendo del tipo de objeto que se le pase al método de acción de la clase controladora. todo lo que se genere usa reflection para crear los templates de las vistas – de manera que generara los nuevos templates basándose en cualquier POCO (Plain Old Clr Object) que se le pase. No depende de ningun ORM particular o implementación de datos.

Por ejemplo, aquí le estamos indicando que nos genere una vista para listas basándose en una secuencia de objetos de la clase Products que le pasamos al método de acción:

Cuando le demos al botón de Add se creará la vista en el directorio ViewsProducts con la implementación por defecto:

ya podemos ejecutar la aplicación y  hacer una petición a la url /products para ver la lista de productos:

Esta RC viene con un varios templates de serie: “Empty”, “List”, “Detals”, “Edit” y “Create” (Podemos añadir nuestros propios templates – ahora veremos cómo).

Por ejemplo, para tener la posibilidad de editar la información de los productos rápidamente podemos implementar la versión HTTP-GET del método de acción “Edit” en el controlador de Productos invocando al comando “Add View”:

En este diálogo podemos indicar que vamos a pasar un objeto del tipo “Product” a la vista y seleccionamos la plantilla “Edit”:

Cuando le demos al botón Add se creará la vista con una implementación por defecto en el directorio ViewsProducts:

Si ejecutamos la aplicación y pedimos la url /products/edit/1 podremos editar ese producto:

para guardar los cambios debemos implementar la versión HTTP-POST del método de acción “Edit” en el controlador de Products:

En el código anterio, en caso de error (por ejemplo: un string que no sea un número) volveremos a la vista. Los templates para la edición y creación contienen la validación HTML necesaria para asegurar que las entradas de usuario sean correctas, marcando con un asterisco rojo los errores que haya detectado:

En raras ocasiones nos bastará con esas validaciones, al final tendremos que reemplazarlas. Pero tener una implementación inicial y que funcione rápidamente, y tener una vista inicial para nuestro escenario nos permite unos altos niveles de productividad, además es muy sencillo de personalizar.

Como esta infraestructura de creación de vistas está basada en objetos POCO, podemos usar tanto cualquier modelo de objetos (inclusive los mapeados con LINQ to SQL, LINQ to Entities, nHibernate, LLBLGen Pro, Subsonic, y cualquier otra herramienta ORM) como crear clases propias para los modelos de presentación tanto de modelos como vistas.

Añadir y personalizar plantillas

La infraestructura de ASP.NET MVC  para crear plantillas de Visual Studio se ha creado con la arquitectura T4 (Scott Hanselman tiene un post muy interesante sobre esto aquí).

Podemos personalizar/sobreescribir cualquiera de las implementaciones de plantillas de ASP.NET MVC. Podemos añadir las nuestras (por ejemplo: la opción “ScottGu Crazy Look”) y mostrarla como una opción más del diálogo “Add View”.

Para personalizar estos templates a nivel de máqquina, abrimos el directorio C:Program FilesMicrosoft Visual Studio 9.0Common7IDEItemTemplatesCSharpWebMVCCodeTemplates” :

El subdirectorio “Addcontroller” contiene todas las plantillas que saldrán en el diálogo “Add controller”. En el subdirectorio “AddView” están las que saldrán en el diálogo “Add View”:

Estos archivos son tan sólo archivos de texto con la extensión “.tt”. Estos archivos contienen condico C# o VB que se ejecuta cuando se selecciona un template.

Podemos abrir y editar cualquiera de los existentes para personalizar el comportamiento de todo esto. También podemos añadir nuevos archivos con esa misma extensión – como el que tengo “Scott Crazy Look.tt”. cuando añadamos un nuevo archivo de plantilla en el diálogo “Add View” se actualizará y se incluirá automáticamente a la lista de templates disponibles:

Además de poder personalizar estos archivos a nivel de máquina, podemos hacerlo también sólo a nivel de proyecto. Con esto podemos hacer check-ins de estos archivos para poder repartirlos en un equipo.

Para personalizar estos archivos a nivel de proyecto sólo tenemos que añadir un directorio llamado “CodeTemplates”  en nuestro proyecto. Y tener los dos directorios de “AddController” y “AddView” :

Se reemplazarn cualquiera de los templates que tengamos en la máquina, si añadimos en estos directorios del proyecto un archivo .tt con el mismo nombre. Por ejemplo, en la imagen anterior estamos reemplazando el Controller.tt por defecto de la máquina, cuando usemos el dialogo “Add Controller” en este proyecto.

Podemos añadir nuevos templates par alas vistas poniéndolos en el directorio “AddView”. Por ejemplo, anteriormente añadimos el template “Yet Another Crazy Look.tt” a los templates de nuestro proyecto. Cuando usemos el diálogo “Add View” veremos la unión de los templates definidos a nivel de máquina y las de nivel de proyecto:

Nota: Cuando añadais templates .tt al directorio codeTemplates aseguraos de poner la propiedad “Custom Tool” de cada uno de ellos a vacío (si no lo hacéis dará un error si intentáis ejecutarlo). tendréis que cerrar y abrir  el proyecto para limpiar errores incómodos de la lista de errores. Publicaremos más post sobre la creación de estos archivos pronto.

Go to Controller/Go to View

En esta RC podremos navegar rápidamente entre Controladores y Vistas en nuestros proyectos.

Cuando el cursor se ponga sobre un método de acción de un controlador podemos, con Ctrl-M, Ctrl-G ir a la vista correspondiente. También podemos hacer lo mismo con el botón derecho y seleccionando la opción “Go To view”:

En el siguiente ejemplo hemos usado el comando “Go to View” en el método de acción “Edit” de la clase ProductsController. Esto hará que se habra la vista ViewsProductsEdit.aspx :

ç

En las vistas podemos usar la combinación de teclas Ctrl-M, Ctrl-G para navegar a la clase controladora correspondiente. También podemos hacer esto con el botón derecho seleccionando la opción “Go To Controller”:

MSBuild Task para compilar las vistas.

Por defecto cuando compilamos un proyecto ASP.NET MVC compila todo el código del proyecto, excepto el código de las vistas. Con la versión Beta teníamos que crear una tarea MSBuild si queríamos compilar el código que contenían las vistas. En la RC se incluye esta tarea ya definida para incluir a las vistas como parte del proceso de compilación. verificará la sintaxis y el código inline que se haya incluido en las vistas, master pages, y vistas parciales de la aplicación, y nos avisará si encuentra algún problema.

Por motivos de rendimiento no recomendamos que se active para obtener compilaciones rápidas durante el desarrollo, pero es conveniente añadir una configuración particular  para esta tarea (por ejemplo: producción y despliegue) y para uso con sistemas de integración continua. Por favor repasad las notas de la release para ver cuales son los pasos para conseguir esto.

Soporte de refactorización en Vistas

El nombre de archivos y directorios en el directorio de la aplicación Views se actualizarán automáticamente cuando renombremos o una clase controladora o un método de acción usando el comando de refactorización “Rename” de VS 2008. VS 2008 aplicará el patrón de nombrado stándar para los directorios y archivos de las vistas existentes cuando se actualize una clase Controladora.

Mejoras en las Vistas

Esta RC incluye varias mejoras sobre las vistas que hemos incorporado en base a todo el feedback que hemos recibido durante las previews anteriores.

Vistas sin archivos de código trasero.

En base al feedback que hemos recibido, hemos optado por no añadir un archivo de código trasero en una vista por defecto. Este cambio refuerza el objetivo de las vistas en una aplicación MVC (ya que se supone que las vistas sólo deben renderizar contenido y no tener ningún código que no tenga nada que ver con ese objetivo), consiguiendo eliminar de esta manera un motón de archivos el proyecto que no se van a usar.

Hemos añadido el soporte de herencia en las plantillas de las vistas con la sintaxis de C# y VB. Por ejemplo, aquí estamos usando esto con la plantilla Edit.aspx – que “hereda” atributos del tipo ViewPage<Product>:

Uno de los beneficios de no usar un archivo de código trasero es que tendremos intellisense instantáneo en las vistas cuando las añadamos al proyecto. En versiones anteriores teníamos que compilar justo después de añadir una vista para poder tener ese intelisense. La RC hace que todo este trabajo sea totalmente transparente.

Importante: Si estás actualizando un proyecto ASP.NET MVC creado con una versión anterior asegúrate de seguir los pasos que se describen en las notas de esta release – el archivo web.config que hay ene l directorio Views tiene que ser actualizado con algunas opciones para que lo anterior funcione en la RC.

Propiedad Model

En versiones anteriores, accedíamos al modelo de objetos fuertemente tipados que se le pasaban a la vista con la propiedad ViewData.Model:

La sintaxis anterior sigue funcionando, pero ahora además hay una propiedad “Model” en ViewPage que también podemos usar:

Este código hace exáctamente lo mismo que el anterior – el principal beneficio es que nos permite escribir un código más conciso. También nos permite usar el diccionario ViewData en los casos en los que queramos que la vista sólo interactúe con el modelo de objetos fuertemente tipado que le pasemos.

Poniendo el título

La plantilla de master-page por defecto que se añade a los proyectos ASP.NET MVC ahora tiene un elemento <asp:contentplaceholder/> en su sección <head>. Esto hace mucho más sencillo que las vistas puedan controlar el elemento <title> de la página HTML que se va a renderizar – y no requiere que el controlador le pase el parámetro de titulo para configurarla (que era lo que se hacía en las versiones anteriore y pensábamos que era algo cuestionable desde el punto de vista de la responsabilidad).

Por ejemplo, para personalizar la sección <title> de la vista Edit para incluir el nombre del producto que vamos a modificar, añadimos el codigo siguiente al template Edit.aspx para obtener el título directamente del modelo de objetos que le hemos pasado a la vista:

El código anterior hará que el navegador renderize el título de la página con el nombre del producto en tiempo de ejecución:

Además de poner el elemento <title>, podemos usar esta aproximación para añadir dinámicamente otros elementos al <head>. Otro escenario en el que ésto es útil es cuando configuramos los elementos <meta/> de la página para la optimización de los motores de búsqueda.

helpers HTML/AJAX fuertemente tipados

Una de las peticiones que se han estado haciendo es sobre la posibilidad de usar expresiones fuertemente tipadas (en lugar de strings) cuando nos referimos al Model usando objetos helper AJAX.

Con la beta de ASP.NET MVC esto no era posible, ya que las clases HtmlHelper y AjaxHelper no exponían el tipo en su signatura, y la gente tenía que escribir helper methods directamente fuera de la clase base ViewPage<TModel> para conseguirlo.

En esta RC se han incluido los tipos HtmlHelper<TModel> y AjaxHelper<TModel> que son expuestos en la clase Viewpage<TModel>. Estos tipos nos permiten crear extensiones fuertemente tipadas para referirnos al modelo de la vista. Por ejemplo:

Los métodos de extensión del formulario HTML del core de ASP.NET MVC V1 sigue usando expresiones basadas en strings. El asemblie “MVC Futures” (que funciona con la RC) tiene unas primeras implementaciones de algunos métodos helper con este tipo de sintaxis. Vamos a iterar en esto un poco más y consideraremos añadirlo al asembly del core de ASP.NET MVC en la próxima release.

Podéis añadir vuestros propios métodos helper (usando tanto strings como expresiones fuertemente tipadas). Los métodos helper HTML/AJAX que ya vienen pueden ser eliminados (ya que son métodos de extensión) si quieréis reemplazarlos por los vuestros.

Mejoras en Form Post

Esta RC incluye unas cuantas mejoras en las peticiones post a formularios:

[Bind/Prefix=””)] Ya no se requiere para escenarios comunes

En esta RC ya no es necesario añadir explícitamente el atributo [Bind] (o poner el prefijo a “”) para mapear parametros post en peticiones a los formularios que no tengan esos parámetros.

Para explicarlo un poco, implementaremos el escenario “Create” de nuestra ProductsController. Empezaremos creando la versión HTTP-GET del método de acción “Create”. En el código siguiente lo hacemos devolviendo una vista basada en un objeto Producto vacío:

Podemos hacer clic derecho en el método de acción y darle al menú “Add View” para crear la estructura básica necesaria basándose en un Product:

Fijáos cómo los métodos helper Html.TextBox() están referenciando a las propiedades “ProductName” y “SupplierID” del objeto Product. Esto generará un HTML como el siguiente donde el nombre de los atributos de entrada son “ProductName” y “SupplierID”:

Podemos implementar la versión HTTP-POST del método de acción “Create”. Tnedremos nuestro método de acción que tiene un objeto del tipo Product como parametro:

Con la beta de ASP.NET MVC teníamos que añadir el atributo [Bind(Prefix=””)] en lo alto del argumento Product – de otra manera la infraestructura de binding e ASP.NET MVC sólo buscaba parámetros de tipo post con un prefijo “productToCreate.” (por ejemplo: productToCreate.ProductName y productToCreate.SupplierID) y no encontraría los valores pasados al formulario (que no tienen ese prefijo).

Con esta RC, los binders por defecto siguen buscando estos parametros para mapear el valro productToCreate.ProductName del objeto que le pasemos. Si no encuentran dicho valor, ahora, mapearan “ProductName” al objeto Product. Con esto conseguimos que en el código en escenarios ene l que pasemos objetos complejos a métodos de acción sea mucho más limpio. Podemos aprovecharnos de esta característica cuando mapeemos tanto objetos de dominio (como Products)  como clases Presentation Model/ViewModel.

Una implementación completa de nuestro método de acción (incluyendo tipos básicos con validación de errores) tendría el siguiente aspecto:

La acción de creación guardará un objeto Product si todos los valores se han insertado correctamente. Cuando un usuario intente crear un producto con una propiedad inválida (por ejepmlo: un string en lugar de un número), el formulario mostrará los elementos incorrectos en rojo:

ç

Mejoras en la API ModelBinder

La infraestructura de binding de ASP.NET MVC Release Candidate ha sido refactorizada para añadir puntos de extensión que nos permitan esquemas de binding y validaciones personalizados. Podéis leer más sobre estos detalles en las notas de la release.

Podemos registar Model Binders para interfaces además de clases.

Soporte IDataErrorInfo

El binder por defecto de ASP.NET MVC soporta clases que implementen la interfaz IDataErrorInfo. Esto permite una forma de crear mensajes de error que puedan ser compartidas entre aplicaciones Windows Forms, WPF y ASP.NET MVC

Mejoras en Test Unitarios

ASP.NET MVC RC incluye algunas mejoras significativas con respecto a los test unitarios:

Cambios en ControllerContext para que no derive de RequestContext

La RC incluye una refactorización de la clase ControllerContext que simplifica muy mucho los escenarios de test unitarios. La clase ControllerContext no hereda de Requestcontext ya que encapsula su RequestContext como una propiedad. Las propiedades de ControllerContext y sus tipos derivados son ahora virtual en lugar de sealed – haciendo mucho más sencilla la creación de objetos mock.

Para ver cómo ayuda esto, consideremos un método de acción como el siguiente que usa objetos Request y User:

El test de este método en versiones anteriores de ASP.NET MVC requería la creación de objetos mock de RequestContext y ControllerContext (con algunos constructores poco obvios que también traían un objeto RouteData).

Con esta RC podemos crear los siguientes test (usando Moq para crear los ControllerContext de  nuestro controlador que nos permiten simular las propiedades Request.IsAuthenticated y User.Identity.Name):

Las mejoras de refactorización no sólo nos han alludado con los test de los controladores – sino que también nos han audado con los filtros de test, rutas, tipos personalizados, y un montón de escenarios más.

Test unitarios de AccountsController

El template ASP.NET MVC Project que se incluye en la RC tiene 25 test predefinidos para verificar el comportamiento de la clase AccountsController (que es un controlador que se añade a un proyecto por defecto para administrar el login y la adiminstración de cuentas). con esto consegumos refactorizar/actualizar la clase AccountsController más fácilmente. su implementación también ha sido moficiada para poder usar credenciales que no se basen en providers Membership.

Protección contra Cross Site Request Forgery (CSFR)

Los ataques de Cross-site request forgery (CSFR) (también definidos como XSRF) hace que los usuarios legítimos de un sitio hagan acciones no permitidas. Estos ataques se basan en que un usuario debe estar logeado en otro sitio. Un sitio web malicioso hace esto creando peticiones al sitio original (por ejemplo: enlazando a una URL usando un elemento <img src=””/> en el sitio atacante. La peticion se hace usando el navegador del usuario y usando el token de autenticación y sus credenciales. El atacante espera que la session de autenticación o cookie siga siendo válida, de manera que el atacante puede realizar cualquier accion en nombre del usuario. Podéis leer más sobre esta técnica aquí.

ASP.NET MVC RC incluye algunos métodos de protección contra este tipo de ataques. Por ejemplo, podemos usar el método Html.AntyForgeryToken() para renderizar una entrada oculta en los formularios:

Este helper usa una cookie HTTP y renderiza un elemento invisible en el formulario. Los sitios web maliciosos no serán capaces de acceder a los valores.

Luego podemos aplicar el atributo [ValidateAntiForgeryToken] en un método de acción que queramos proteger:

Con esto conseguiremos que se compruebe la existencia de los tokens apropiados y prevenir que nuestro método de accion HTTP-POST se ejecute si no conccuerdan (reduciendo las probabilidades éxito de un ataque CSFR).

Mejoras en la administración de archivos

Métodos helper FileResult y File()

Esta Rc añade la clase FileResult que se usa para indicar que se está devolviendo un archivo de un formulario ActionResult en un método de acción de un controlador. la clase base Controller también tiene un conjunto de métodos helper de File() para hacer más facil la creación y devolución de un FileResult.

Por ejemplo, supongamos que queremos crear un sitio de administración de fotos. Podemos definir una clase “Photo” que encapsule los detalles de una foto guardada:

Podríamos usar el método helper File() para implementar el método de acción “DisplayPhoto” en un controllador PhotoManager que será usada para renderizar la salida de Photo de una base de datos. En el siguiente código estámos pasando al método File() los bytes a renderizar, así como el mime-type del archivo. Si enlazamos a un elemento <img src=””/> nuestro método de acción, el navegador mostrará la foto en la siguiente página:

Si queremos que el usuario pueda descargar la foto y guardarla en local, podemos implementar el método de acción “DownloadPhoto” de la siguiente forma. Estamos pasando un tercer parámetro – que hará que ASP.NET MVC ponga una cabecera que haga que el navegador muestre el diálogo “Sabe As…” rellenado con el nombre del archivo que se le ha indicado:

Cuando el usuario haga clic en el enlace /PhotoManager/DowloadPhoto/1232 se le indicará que guarde el archivo:

Soporte para subir archivos

También se incluye un model-binder para subir archivos y contenidos multi-part.

Por ejemplo, podemos tener un <form> cuyo atributo enctype está puesto como “multipart/form-data” que haga un post a la url /PhotoManager/UploadPhoto . Si fué un elemento <input type=”file” name=”fileToUpload”/> hará que el archivo seleccionado por el usuario se le pase a nuestro método de ación como un objeto del tipo HttpPostedFileBase:

Podemos usar el objeto HttpPostedFilebase para obtener los bytes del archivo, su mime-type, y guardarlo a una base de datos o a un archivo.

Mejoras en AJAX

Intellisense de los archivos de jQuery en proyectos ASP.NET MVC

Los proyectos ASP.NET MVC que se creen incluirán tanto la librería jquery stándar (la versión completa y la comprimida), como el archivo -vsdoc necesario para soportar el intellisense (podéis aprender más sobre esto aquí):

Esto permite un intellisense muy rico de la librería de JavaScript de jQuery muy rica:

Esta RC viene con la versión jQuery 1.2.6. Estamos planeando incluir la próxima versión jQuery 1.3.1 para la release final de ASP.NET MVC 1.0, que también incluirá el intellisense correspondiente.

Propiedad Request.isAjaxRequest

La propiedad Request.IsAjaxRequest peude ser usada para comprobar cuando una peticion ha sido enviada por AJAX (es útil en escenarios en los que queramos penalizar si no está habilitado). La lógica de este método se ha actualizado en la RC para reconocer la cabecera HTTP “X-Requested-With” (además del campo de ASP.NET AJAX). Esta es una cabecera  bien conocida en las librerías de Javascript como prototype, jquery, y Dojo – y ahora permite unificar la forma de comprobar AJAx en peticiones que se le hagan a ASP.NET MVC.

Métodos helper JavaScriptResult, ActionResult y JavaScript()

La clase base Controller tiene ahora el método helper JavaScript() que devuelve un ActionResult del tipo JavaScriptResult. Con esto podremos escupir código JavaScript que se ejecutará en el cliente . Es muy útil en escenarios en los que queremos que se ejecute cierto código JavaScirpt dependiendo de cierta lógica del servidor.

Resumen

Estamos muy nerviosos debido al último sprint que nos queda para ASP.NET MVC V1. Por favor, no dudeis en reportar cualquier problema que encontréis en la RC tan pronto como podáis para que podamos resolverlo para la versión final. el equipo plane  monitorizar cualquier feedback en las próximas semanas, y esperan no encontrar problemas grandes que resolver para la próxima versión.

Espero que sirva.

Scott.

Traducido por: Juan María Laó Ramos.

Artículo original.