jueves, 16 de febrero de 2012
Bueno, 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.
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:
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
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.
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:
¿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
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.
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:
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:
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?
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,
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
Como era de esperar, en la carpeta /controllers encontraremos un controlador específico,
También en la carpeta de vistas encontramos los siguientes archivos:
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…
Enlaces:
Publicado en: Variable not found.
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.
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.
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.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.
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: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?
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()
, yDeleteTodoItem()
) 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 entidadTodoItem
, tendremos DataController.Friend.cs para la gestión de entidadesFriend
, DataController.Product.cs paraProduct
, etc. En definitiva, que dentro del controladorDataController
tendremos métodos para manipular los datos de las entidades que necesitemos desde nuestro interfaz SPA.
Tambié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.
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.
Enlaces:
Publicado en: Variable not found.
9 Comentarios:
Ya lo tengo instalado, pero cuando quiero crear un modelo, no encuentro la template entity objectgenerator EF
alguien sabe que puede llegar a ser y como se soluciona?
saludos!
Hola, Alejandro.
La verdad es que no sé muy bien a qué te refieres...
Codefirst funciona bien, al menos aparentemente. También he probado a crear un modelo EF y va bien, e incluso a agregar un elemento de generación de código sobre el modelo (eso sí, descargándolo previamente desde la galería), y también parece funcionar bien.
Qué pasos debo seguir para reproducir el problema?
gracias por tu pronta respuesta
por ej:
sobre la carpeta Models, hago click con el boton derecho, selecciono nuevo item: se abre la pantalla de las plantillas instaladas, selecciono el nodo "Datos" o "Data" y ahi es donde no encuentro la plantilla de EF Object Generetor que solia tener antes de la actualizacion...
no se si se entiende bien...
Hola de nuevo!
¿Seguro que esa plantilla te debía aparecer ahí? Me suena más como elemento de generación de código...
Prueba con esto:
Crea un "Entity data model" (o modelo de entidades de datos) de una base de datos cualquiera, y con eso crearás tu modelo, bien sea vacío o bien desde una base de datos.
Ya desde el modelo, con el botón derecho pulsas "agregar elemento de generación de código", y en el cuadro de diálogo que aparece es donde debes tener esa plantilla. Y si no la tienes en el proyecto MVC 4, simplemente descárgala de la galería.
A ver si van por ahí los tiros.
Un saludo!
es que es eso justamente lo que no puedo hacer! no puedo crear el modelo! Lo venia haciendo correctamente hasta este cambio de version....
Hola!
Pues vaya, lo siento.
Yo tenía instalada antes la preview, y tras instalar la beta todo sigue funcionándome correctamente.
A ver si a alguien más le ocurre lo mismo y puede aportar un poco de luz sobre el tema.
Un saludo!
igualmente, muchas gracias por tu ayuda!
Saludos
¡Buen resumen si señor!
Gracias JM :)
Gracias, Gis!
Enviar un nuevo comentario