Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. ASP.NET

Desarrollando una aplicación MVC4 en ASP.NET con EF y WebAPI

by
Length:LongLanguages:

Spanish (Español) translation by steven (you can also view the original English article)

El MVC en ASP.NET ha recorrido un largo camino desde que "The Gu" anotó algunas ideas durante un viaje en avión a una conferencia en 2007. En poco menos de cuatro años, ASP.NET MVC ha visto su cuarta versión, y brinda a los desarrolladores un ambiente que facilita el desarrollo, agiliza los procesos y promueve los patrones modernos.


Navegando

Lanzándose es una de las mejores maneras de manejar una nueva tecnología. ¡Sigamos adelante y sumergámonos en el codec!

Configuración

Usaré Visual Studio 2012 Release Candidate, que está disponible aquí. También recomiendo descargar SQL Server 2012 porque el nuevo Management Studio es una mejora muy necesaria respecto a las versiones anteriores.

Una vez que VS 2012 esté en funcionamiento, continúa y crea un nuevo proyecto. Ve a Archivo -> Nuevo proyecto y elige una aplicación de Internet. No es una plantilla perfecta, pero hará el trabajo.

Project Options

Nota: el código para esta aplicación de demostración se encuentra en un repositorio de Github. No iré a través de cada pieza de código en esta aplicación, pero al final de este tutorial comprenderás bien una aplicación MVC4.

Entity Framework

Voy a usar el código Entity Framework (EF) primero para el modelo de datos. El Código de EF Primero nos permite generar tablas de base de datos con nada más que unos pocos Objetos CLR Antiguos (POCO). Además, EF nos permite usar LINQ para Entidades y expresiones Lambda, lo que facilita la consulta y la emisión de comandos. ¡Una victoria ganada!

Nuestra aplicación será un sitio para revisar... cosas. Por lo tanto, el modelo de datos debe incorporar todos los bits y piezas necesarios para una única revisión. Comenzaremos con una clase llamada Review. Escribe la siguiente clase en tu propio archivo en el directorio Models:

La clase Review tiene su ID (la clave principal), la propiedad Content para almacenar la revisión, un Topic como el nombre de un restaurante (o cualquier nombre de una organización), una propiedad Email o y una bandera IsAnonymous para indicar si el crítico es anónimo. Las propiedades CategoryId y Category crean una relación de clave externa para vincular una revisión a una categoría (p. Ej., Médicos, dentistas, etc.). Y el último es una colección de objetos Comment.

Ahora escribe la clase Comment. Una vez más, agrega la nueva clase al directorio Models:

La clase de comentarios tiene una propiedad Id para la clave principal, el contenido 'Content' del comentario, una propiedad email y una marca de IsAnonymous para los usuarios. Luego están las propiedades ReviewId y Review para crear una relación de clave externa entre los comentarios y las revisiones.

La última es la clase Category. Aquí está su código:

Esta clase se explica por sí misma.

Probablemente notaste un uso extenso de la anotación de datos [Required] en las clases anteriores. Estos designan un campo no anulable en la base de datos y proporcionan validación más adelante en el futuro. También puedes crear tus propios atributos de validación personalizados si así lo deseas. Además de [Required], también usamos la palabra clave virtual para algunas propiedades; esas propiedades significan relaciones de clave externa con otras tablas.

Para crear las tablas correspondientes para estas clases, deberás crear una clase DbContext. El siguiente código crea una clase de contexto llamada ReviewedContext:

El Código de EF Primero nos permite generar tablas de base de datos con nada más que unos pocos Objetos CLR Antiguos (POCO).

Cada propiedad en esta clase corresponde a una tabla cuando se genera la base de datos. El Configuration.ProxyCreationEnabled = false; se asegura de que las entidades se recuperen como objetos de sus respectivas clases en lugar de proxies, lo que hace que la depuración sea mucho más fácil.

A continuación, configuramos un inicializador de base de datos. Un inicializador garantiza que la base de datos se crea correctamente cuando el modelo de datos sufre algún cambio. Sin un inicializador, tendrás que eliminar manualmente la base de datos si realizas un cambio en uno de tus POCO's. Hay algunos tipos diferentes de inicializadores para elegir: DropCreateDatabaseAlways y DropCreateDatabaseIfModelChanges. Los nombres se explican por sí mismos. El que vamos a utilizar es DropCreateDatabaseIfModelChanges.

Los inicializadores DropCreateDatabaseAlways y DropCreateDatabaseIfModelChanges tienen un efecto secundario: eliminan las tablas (y, por lo tanto, los datos) en la base de datos cuando cambia la estructura del modelo. Pero EF Code First proporciona una tercera forma de generar bases de datos: las migraciones. Esta nueva característica realiza un seguimiento de los cambios en la base de datos y no pierde datos a medida que cambian las clases de POCO.

Aquí está el código para nuestro inicializador:

La clase ReviewedContextInitializer anula el método Seed(). Esto nos da la capacidad de llenar nuestra base de datos con algunos datos de prueba. Ahora, necesitamos visitar el archivo Global.asax y agregar la siguiente línea al método Application_Start():

Vamos a crear algunos repositorios para recuperar datos de la base de datos, y luego procederemos a configurar la inyección de dependencias (DI) con Ninject. Si no sabes exactamente qué es DI o Inversión de control (IoC), tómate un momento para leer este artículo.

Básicamente, la idea de inyección de dependencia es inject una dependencia concreta en una clase, a diferencia de codificar la clase para que dependa de la dependencia concreta. En otras palabras, es un desacoplamiento de una clase concreta de otra. Si eso sigue siendo claro como lodo, veamos un breve ejemplo:

Este código crea una clase llamada Foo. Depende de la funcionalidad de un objeto de tipo Bar, y el objeto Bar se crea dentro de la clase Foo. Esto puede ser difícil de mantener y una prueba unitaria porque:

  • Foo y Bar están fuertemente acoplados. Como resultado, el mantenimiento es menos que ideal.
  • Foo depende de una implementación específica de Bar, lo que dificulta las pruebas unitarias.

Este código se puede mejorar con solo unas pocas modificaciones. Echa un vistazo a la clase Foo revisada:

En poco menos de cuatro años, MVC en ASP.NET ha visto su cuarta versión...

Ahora, la clase Foo no depende de una implementación específica de Bar. En cambio, un objeto de una clase que implementa la interfaz IBar se suministra a Foo a través del constructor de este último. Este enfoque mejora en gran medida la capacidad de mantenimiento, al tiempo que nos permite inyectar cualquier objeto IBar, lo que facilita la prueba unitaria de nuestro código.

Con esa breve descripción fuera del camino, pongamos a Ninject en funcionamiento. Inicia la Consola del administrador de paquetes y ejecuta Install-Package Ninject.MVC3. Esto agregará Ninject a nuestro proyecto.

El primer repositorio que crearemos es ReviewsRepository, e implementará la interfaz IReviewRepository. Aquí está la interfaz:

Esta interfaz garantiza que nuestros repositorios de revisión proporcionen las operaciones básicas de CRUD. También obtenemos la utilidad de recuperar revisiones por una categoría específica, así como de recuperar los comentarios para una revisión determinada. Ahora escribamos una clase concreta implementando esta interfaz:

WebAPI es un framework similar a MVC que podemos usar para crear fácilmente una API RESTful...

Este repositorio se basa en un objeto ReviewedContext que se almacena como una variable de clase. Esto nos permite usar LINQ en cualquiera de los métodos del repositorio, facilitando la interacción de la base de datos.

WebAPI tiene una buena característica que nos permite agregar nuestro propio framework DI. Esta función está fuera del alcance de este tutorial, así que asegúrate de leer este artículo para ayudarte a obtener esa configuración.

Una de las ubicaciones más importantes de nuestro código es la carpeta App_Start, que contiene un archivo llamado NinjectCommonWeb.cs (la instalación de Ninject agrega automáticamente este archivo a App_Start). Este archivo contiene una clase estática llamada NinjectWebCommon, y tiene un método llamado RegisterServices(). En este método, agrega el siguiente código:

Las primeras tres declaraciones unen una interfaz a una implementación concreta de la interfaz, y la cuarta línea configura el DI para WebAPI (la característica que se trata en el artículo mencionado anteriormente).

WebAPI

Ahora vamos a crear los controladores para la API. WebAPI es un framework similar a MVC que podemos usar para crear fácilmente un servicio REST, y puede ejecutarse dentro de una aplicación MVC4, en su propio proyecto, o puede ser auto hospedado fuera de IIS. Pero eso no es todo; tiene muchas otras características, tales como: negociación de contenido (para serializar automáticamente los datos en cualquier formato que se solicite), vinculación de modelos, validación y muchas más.

Primero necesitamos crear un punto final con WebAPI, y lo hacemos creando una clase que hereda ApiController. Comenzar con esto es bastante fácil. Visual Studio 2012 tiene una nueva característica que crea un nuevo controlador parcialmente con scaffolded o Scaffolding.

Create ApiController

Esto creará una clase de controlador con algunos métodos ya definidos para ti. Aquí hay un ejemplo:

Los nombres de los métodos corresponden al verbo HTTP que representan. Ahora vamos a crear la clase ReviewsController. El código es un poco largo, pero bastante sencillo.

Este código utiliza los objetos IReviewRepository e ICategoriesRepository para realizar la acción apropiada (por ejemplo: recuperar datos para solicitudes GET, agregar datos con solicitudes POST, etc.). Estos respositorios se inyectan con Ninject a través del Constructor Injection.

Si aún no tienes Fiddler, obténlo ahora, incluso si no eres un desarrollador de .NET.

Ten en cuenta que algunos de los métodos devuelven diferentes tipos de datos. WebAPI nos da la capacidad de devolver un tipo de datos no de cadena (como IEnumerable<Review>), y serializará el objeto para enviar la respuesta del servidor. También puedes usar la nueva clase HttpResonseMessage para devolver un código de estado HTTP específico junto con los datos devueltos. Una forma de crear un objeto HttpResponseMessage es llamando a Request.CreateResponse(responseCode, data).

Podemos probar adecuadamente nuestro proyecto WebAPI con una herramienta como Fiddler2. Si aún no tienes Fiddler, obténlo ahora, incluso si no eres un desarrollador de .NET. Fiddler es una fantástica herramienta de depuración HTTP. Una vez que estés ejecutando Fiddler, haz clic en RequestBuilder e ingresa la URL de la API que deseas probar. Luego elige el tipo de solicitud apropiado. Si realizas una solicitud POST, asegúrate de especificar un encabezado Content-Type: application/json y luego coloca una estructura JSON válida en el cuerpo de la solicitud. La siguiente imagen muestra una solicitud JSON POST sin procesar a la URL api/reviews:

Cuando envíes la solicitud, verás algo como la siguiente imagen:

Ten en cuenta que el código de estado de las solicitudes POST es un 201. WebAPI hace un gran trabajo al devolver el código de estado correcto para un servicio web RESTful. Diviértete con Fiddler2, ¡es una herramienta fantástica!

Con WebAPI, puedes especificar el enrutamiento para los controladores (como MVC). En MVC4, se agrega un archivo RouteConfig.cs a la carpeta App_Start. Las rutas para un proyecto WebAPI son como las rutas MVC.

La ruta DefaultApi es generada automáticamente por Visual Studio. Las otras dos rutas son personalizadas y se asignan a métodos específicos en el controlador Reviews. Hay muchos artículos y tutoriales que proporcionan buena información sobre el enrutamiento. Asegúrate de echarle un vistazo.

MVC4

Eso cubre mucho de lo que WebAPI tiene para ofrecer. A continuación, vamos a escribir algunos métodos para mostrar los datos. Consumiremos la API en un momento, pero por ahora usaremos los repositorios en nuestro HomeController. Un HomeController fue creado por Visual Studio; Solo modifiquemos sus métodos para mostrar los datos. Primero, obtengamos una lista de las categorías en el método Index.

Aquí, continuamos usando DI aceptando los repositorios como parámetros para el constructor HomeController. Ninject inyecta automáticamente las clases concretas adecuadas para nosotros. A continuación, agreguemos algo de código a la vista Index para mostrar las categorías:

Esto genera una lista de categorías en las que los usuarios pueden hacer clic. Ahora agrega un nuevo método a HomeController que recupera un Review. Llamaremos a este método Reviews, tal como se muestra aquí:

Debido a que ya existe una ruta para /{controller}/{action}/{id}, puedes usar una URL como Home/Reviews/Doctors. El motor de enrutamiento pasará "Doctors" como el parámetro id al método Reviews. Usamos el ID como la categoría y recuperamos todas las revisiones asociadas con esa categoría. Sin embargo, si no se proporciona una categoría, simplemente recuperamos todas las revisiones en la base de datos. Una vez que tenemos todas las revisiones, pasamos la lista de revisión a la vista. Veamos ahora la vista:

Este código utiliza una nueva característica de MVC4. El atributo de clase del elemento <ul> no aparecerá en el HTML si hasComments es nulo. Lee más sobre esta característica aquí.

JavaScript

Ninguna aplicación web moderna está completa sin JavaScript, y la usaremos para consumir nuestro servicio WebAPI. Usaremos Backbone.js para esto; así que, adelante y descarga Backbone y su dependencia Underscore. Coloca los archivos de JavaScript en el directorio Scripts.

Aprovecharemos otra nueva característica de MVC4 llamada agrupación de scripts. En la carpeta App_Start, encontrarás el archivo BundleConfig.cs. En este archivo, puedes configurar MVC4 para agrupar archivos JavaScript juntos. Ábrelo y agrega un nuevo paquete, como este:

Luego, en el archivo /Views/Shared/_Layout.cshtml, agrega lo siguiente en la parte inferior del body de la página:

Esto incluirá tus scripts si tu aplicación está en modo de depuración, o los dejará solos con la opción desactivada.

El código MVC4 que escribimos para recuperar la lista de revisión es una buena forma de mostrarlos, pero todo lo nuevo está usando Ajax. Así que vamos a refactorizar el código para utilizar Backbone.js. A través de JavaScript, recuperaremos las vistas de forma asíncrona después de que la página se haya cargado. Crea un nuevo archivo en la carpeta Scripts llamada home.js. Agrega el siguiente código a ese archivo:

Estos son los modelos de datos de JavaScript, cada uno correspondiente a una URL para recuperar datos del servicio WebAPI. Ahora vamos a escribir la vista:

Esta vista es para la lista completa de comentarios. Cuando se llama al método fetch() de la colección, se activa el evento reset y luego se llama a render(). El tercer parámetro pasado al método on() es el alcance, o lo que será this en la devolución de la llamada render(). En el método render(), llama al método each() de la colección, pasando el método renderItem(). Se llamará al método renderItem() en cada elemento de la colección, generando un nuevo ReviewItem para cada revisión.

El código para ReviewItem sigue:

WebAPI es una fantástica adición a la pila ASP.NET; una API basada en REST rica en características nunca ha sido tan fácil.

La vista ReviewItem es responsable de representar cada revisión individual. El método initialize() compila la plantilla utilizada para mostrar cada revisión; esta plantilla reside en un elemento <script>. Backbone saca la plantilla del elemento <script/> y la combina con la revisión.

También se configura un controlador de eventos clic para cargar los comentarios de cada revisión. Cuando se hace clic en el enlace, se llama al método getComments(), que busca los comentarios pasando un id al servicio WebAPI. El método fetch() es simplemente una abstracción del método $.ajax de jQuery, por lo que los parámetros Ajax normales, como data, se pueden pasar en la llamada fetch(). Por último, el método loadComments() se activará y creará una nueva vista CommentItem para cada comentario devuelto. El tagName en esta vista garantiza que la vista se crea con un <li> como su propiedad $el.

A continuación, veamos la vista CommentItem:

Esta es una vista simple que muestra cada comentario. Ahora vamos a modificar la vista Review.cshtml de la siguiente manera:

Observa los scripts de @section en el código anterior. Esta no es una característica nueva de MVC4, pero es una gran herramienta para representar partes específicas de JavaScript. En el archivo _layout.cshtml, también hay un @RenderSection("scripts", required: false) que representa la sección definida en la vista. Los elementos <script> son plantillas Underscore para representar contenido. Siguen una sintaxis de Ruby-esque, y cualquier cosa dentro de <% %> se evalúa como una declaración. Cualquier cosa dentro de <% =%> se enviará al HTML. Los bucles y las declaraciones condicionales se pueden utilizar de esta manera:

Esa es la plantilla. Para usarlo, haz esto:

Hay muchos frameworks de plantillas JavaScript disponibles en la Web: Handlebars.js, mustache.js y Hogan.js son muy populares. Asegúrate de revisarlos y elige el que funcione para ti.

Conclusión

WebAPI es una fantástica adición a la pila ASP.NET; una API basada en REST rica en características nunca ha sido tan fácil. Hay muchas nuevas características en MVC4. ¡Asegúrate de revisarlos! Como mencioné anteriormente, el código para este ejemplo está disponible en Github. ¡Tenlo!

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.