TUT: Aprender ASP .NET MVC Paso a Paso en 7 dias(Dia 2)

Contenido 

• ¿Cuál es la Agenda? 
• Lab 06: Testeo Unitario en Proyectos MVC 
• Lab 07: Entendiendo el Ruteo en MVC 
• Lab 08: Validando y Asignando Valores por defecto a las URLs en MVC 
• Lab 09: Entendiendo URLs Salientes en MVC 
• ¿Qué hay para el Tercer Día? 

¿Cuál es la Agenda?

Este artículo es la continuación de Aprender paso a paso en 7 dias y puedes revisarlo en los link siguientes: 

• Dia 1: Controladores, vistas fuertemente tipadas y clases helper
• Dia 2: Testeo unitario, ruteo de URL saliente 
• Dia 3: Vistas parciales, anotaciones de datos, Razor, Autenticacion y Autorizacion 
• Dia 4: JSON, JQuery, administrador de sesiones y controladores asíncronos
• Dia 5: Empaquetamiento, Minificacion , ViewModel , Manejo de excepciones y Areas
• Dias 6: Modos de Visualización, Proveedor MVC OAuth, Enlace Modelo MVC

En este dia 2 veremos los siguientes cuatro laboratorios: 

• Escribiendo Testeos Unitarios en Proyectos MVC. 
• Configurar Rutas en MVC 
• Validación de Rutas en MVC 
• Configurando Rutas de salida en MVC 

Lab 06: Testeo Unitario en Proyectos MVC

Cuando empezamos toda la serie MVC(Dia 1) empezamos con dos problemas relacionados al code-behind. 

¿Cómo podemos hacer testeos unitarios en ASP.NET code behind?

¿Como podemos reusar el code behind de ASP.NET con diferentes interfaces de usuarios?

En esta sección vamos a concentrarnos en el primer punto, es decir, Testeo Unitario.

Solo una rápida recapitulación si necesitamos hacer testeo unitario al siguiente método btngenerateinvoices_click de Code behind de ASP.NET, tenemos los siguientes problemas: 

• ¿Cómo hacemos para crear los objetos sender y eventargs? 
• El código de abajo se ejecuta bajo el objeto HttpContext, ¿Cómo puedo imitarlo? 
• ¿Qué pasa con los controles de interfaz de usuario de ASP.NET, Cómo accedo a estos? 
• ¿Qué pasa con otros objetos de ASP.NET como objeto sesion,y aplicacion, cómo accedo a estos? 

Muchos desarrolladores podrían hablar acerca de mock tests, rhino mocks,etc. pero todavía esto es desapercibido y la compliacion aumenta con las variables de sesion, objetos de data view, controles ASP.NET UI, creando aun mas confusión.

Asi que lo que haremos en esta sección es crear una simple aplicación MVC y haremos teste unitario en aplicaciones ASp.NEt usando el testeo unitario de Framework VSTS.

Paso 1: Crear un simple proyecto las mostrar Customer.

El primer paso es crear un simple proyecto MVC. Usaremos el mismo proyecto el cual nosotros temos creado en MVC(Modelo Vista Controlador) del dia 1(MyFirstHelloWorld). En caso no tengas el proyecto mencionado, por favor crea uno usando el enlace de arriba.

La clase controlador al final del día 1 es una simple clase .NET. Por ejemplo, si miras el código del proyecto cercanamente, puedes ver fácilmente la clase controlador de Customer con se muestra a continuación: 

En simples palabras este es una simple clase .NET podemos fácilmente instanciar la clase y crear automáticamente testeos unitarios para el mismo. Esto es exactamente lo que vamos hacer en nuestros siguientes pasos:

Paso 2: Agregando un simple proyecto de testeo unitario.

Vamos a usar nuestro testeo unitario del framework de VSTS para testear la clase controlador. Agrega un nuevo proyecto a su solución usando la plantilla Proyecto Prueba Unitaria.

Paso 3: Agregar referencias apropiadas al proyecto

Necesitamos agregar un referencia a la aplicación MVC en nuestro proyecto de prueba unitaria(MVCUnitTest), para que podamos controlar la clase Controlador.

Una vez agregado la referencia , deberías ver en la aplicación MVC e la referencia de proyecto como se muestra en la siguiente imagen:

Paso 4: Escribir la prueba unitario

Una vez que tengas agregado la referencia, abre la clase de prueba unitaria,es decir UnitTest1.cs. En esta clase crear un simple método de teste llamado DisplayCustomer el cual es atribuido por el atributo TestMethod como se muestra en el siguiente código.

Si tu ves el siguiente pedazo de código estamos creando un objeto de la clase controlador, invocando la acción del controlador, es decir, DisplayCustomer y entonce verificamos si el nombre de la vista es DisplayCustomer. Si ellos son igual esto significa el paso de la prueba o en caso contrario esto es fallido.

Paso 5: Finalmente ejecutamos la prueba unitaria

Una vez escrito la prueba es tiempo de ejecutar caso de prueba para lo cual vamos hacer click en el menú Prueba->Ventanas-> Explorador de Pruebas.

En el Explorador de pruebas hacer click derecho y seleccionar Ejecutar Pruebas Seleccionadas.

Si las cosas van bien tu deberias ver una indicación de color verde que indica que la prueba ha pasado o caso contrario deberías ver un color rojo con el detalle indicando porque la prueba ha fallado.

Lab 7: Entendiendo el ruteo MVC

Introducción

Al final del día, MVC no es nada más que una dirección de URL asignada a los controladores y los controladores asignados a acciones.

Por ejemplo cuando un usuario envia un requerimientio de URL como http://www.maninformatic.com/UbicaProducto del navegador, estas acciones son asignadas con los controladores de MVC, y los controladores de MVC finalmente invocan esas funciones.

Lo siguiente es una simple tabla el cual muestra cómo todo esto se ve así.

Añadiendo aún más a la complicación que podemos tener varias direcciones URL asignadas a un controlador o se puede tener más de un controlador asigna a una sola URL. Por ejemplo, puedes tener www.maninformatic.com/contactenos y www.maninformatic.com/conocenos asignada a un solo controlador llamado ConocenosController

.

Sería muy bueno si tenemos algún tipo de mecanismo por el cual podemos configurar estas asignaciones. Eso es lo que exactamente MVC routing significa. El enrutamiento MVC ayuda a configurar y asignar la dirección URL con los controladores fácilmente.

Paso 1: Tomar el proyecto MVC creado en el dia 1

Vamos a tomas el mismo proyecto de Customer( MyFisrtHelloWorld) que hemos desarrollado en la seccion anterior.

Paso 2: Cambiar Global.asax.cs

Todas las asignaciones de rutas son almacenados en el archivo de código fuente RouteConfig.cs. Así que como primer paso es que tenemos que ir a cambiar este archivo.

Todas las asignaciones de rutas son almacenadas dentro de la colección llamada routes. Esta colección pertenece al namespaces System.Web.Routing. Para agregar una ruta tu necesitas llamar el método MapRoute y pasar tres parámetros name, url y defaults.

Debajo está una captura de retazo de código de la función MapRoute.

• Name es el nombre principal por la cual la ruta será identificada dentro la colección. 
• URL define que tipo de formato de URL queremos conectar con el controlador.En el pedazo de código siguiente decimos que el formato URL es View/ViewCustomer. 
• Defaults define la clase controlador y las funciones de accion los cuales serán invocados cuando la URl es llamada. Por ejemplo, en el código siguiente, decimos que cuando View/ViewCustomer es llamado, este invocará la clase controlador Customer y la funcion acción invocada sera DisplayCustomer. 

En caso su controlador tome parámetros, puede usar el { (llaves).Por ejemplo en el siguiente pedazo de codigo, nosotros hemos usado { para especificar que podemos tener un parámetro id. Si quieres definir los parámetros como opcionales puedes usar el enum UrlParameter.Optional.

Lo primero es comentar el código de asignación predeterminada. Vamos a explicar el código de asignación predeterminada más tarde.

Ingresamos el siguiente codigo, el cual significa cuando llamamos a http:/localhost/view/ViewCustomer esto invocará al controlador Customer y llamara la funcion DisplayCustomer.

Paso 3: Ejecuta la aplicación

Si ejecutas la aplicación deberias ver lo siguiente:

Nota: No muestra ningún nombre, porque esto tiene que ser enviado del formulario, y puedes probar cambiando el la propiedad action del formulario(view/viewCustomer).

Si recuerdas nosotros comentamos la entrada de ruta por defecto(default), vamos a entender qué significa exactamente ese código.

“{controller}/{action}/{id}” define este que la URL será automáticamente llamado con la convención Controlador(nombre/función) accion (nombre/valor). si tienes una clase controlador con Customer y función acción como Search entonces el URL será estructurada automáticamente como htt://www.maninformatic.com/Customer/Search.

Lab 8: Validando y asignando valores por defecto a URLs de MVC

MVC tiene que ver con la acción que se produce a través de la URL y los datos para esas acciones también es proporcionado por la URL.

Seria bueno si pudiéramos validar los datos que se transmiten a través de estas URL de MVC.

Por ejemplo vamos a considerar la URL MVC http://localhost/Customer/ViewCustomer si quieres ver el detalle para el código del customer 1001, necesitas ingresar

http://localhost/Customer/ViewCustomer/1001.

El código de Customer es un número natural. En otras palabras, cualquier persona que ingrese una URL MVC como http://localhost/Customer/ViewCustomer/Shiv es inválido. El framework MVC provee un mecanismo de validación por el cual podemos comprobar en la propia URL si el dato es apropiado. En este laboratorio veremos cómo validar datos el cual es ingresado en la URL MVC.

Paso 1: Creando un simple modelo Customer.

En este primer paso vamos a trabajar con nuestra simple clase modelo Customer ya creada en los pasos anteriores.

Paso 2: Creando la clase controlador

En el siguiente paso vamos a utilizar la clase controlador Customer ya creada en pasos anteriores agregando una colección de Customers en el constructor.

El controlador tiene una simple función DisplayCustomer el cual muestra los clientes usando el valor ID. Esta función toma el valor Id y encuentra en la colección customer.

Si miras en la función DisplayCustomer esta toma un valor id el cual es numérico. Deberíamos tomar como una validación el campo ID el cual indica lo siguiente:

• Id debería siempre ser numérico
• Este debería ser entre 0 y 99

Paso 3: Aplicando Validación usando regex en la ruta MVC

La validación descrito en el paso 2 puede ser logrado aplicando expresiones regulares en el mapeo de ruta(MapRoute). Si vamos al archivo RouteConfig.cs y vemos la función maproute., la entrada a esta función es el constraint como se muestra es la figura de abajo.

En este orden para acomodar la validación necesitamos especificar el regex constraint es decir ‘\d{1,2}’ en la función maproute como se muestra abajo. ‘\d{1,2}’ en regex significa que la entrada debería ser numérico y ser un máximo de 1 o 2 es decir entre 0 y 99.

Puedes especificar los valores por defecto diciendo id=0 como se muestra en el código de abajo. En el caso de que ID no este especificado este tomara el valor 0 por defecto.

Paso 4: Probando si esto trabaja

Ahora que estamos haciendo la validación usando la función maproute, es tiempo de probar si esta validación trabaja. La primera prueba tenemos que especificar 1 y veremos que el controlador es correcto y la data es mostrada.

Si especificamos un valor mayor a 99, deberíamos obtener un error como se muestra abajo. Por favor note que el error es confuso pero es el efecto de la validación regex el cual especifica la función maproute.

El punto más importante a notar es que esta validación se ejecuta antes que la solicitud a la función del controlador.

Lab 9: Entendiendo URLs salientes en MVC

Introducción

Cuando hablamos de aplicaciones web, los usuarios finales estarían como navegando de una página a otra página. Como desarrollo simple primeramente estarías pensando en dar justo los nombres de la aginas como se muestra en la figura de abajo.

Por ejemplo si quieres ir y mostrar de home.aspx a about.aspx darás el enlace al nombre de la página y las cosas deberían ser bien.

Pero haciendo esto estas violando los principios de MVC. Los principios MVC dicen que la llamada debería primeramente llegar al controlador, pero especificando <a href=”home.aspx” a> la primera llamada es a la vista. Este inconveniente es completamente lógica del controlador y tu arquitectura MVC falla.

Lo ideal es que las acciones deberían direccionar a las páginas. Los enlaces deberían tener acciones en la etiqueta anchor(<a>) y no nombres de páginas es decir nombres de vistas.

Paso 1: Creando el controlador para las vistas

Definimos las acciones que invocaran estas vistas. En el siguiente codigo tenemos definido tres acciones: GotoHome( esta invoca a la vista Home), AboutUs(Este invoca a la vista about), y SeeProduct(Este invoca a la vista product).

Paso 2: Creando vistas

Ahora vamos a crear las vistas para los tres métodos definidos en el controlador Site(About, Home, Product).

Ahora vamos a crear una simple navegación entre estas simples páginas como se muestra abajo. De la vista Home nosotros estaríamos navegando a las vistas About y Product. De las vistas About y Product estaríamos navegando atrasa la vista Home.

Paso 3: proveyendo acciones en los link.

Para invocar las acciones relacionadas a las vistas necesitamos especificar las acciones en la etiqueta anchor como se muestra en el siguiente código.

El código de arriba fue para la vista Product, pues hacer lo mismo para las vistas About y Home.

Para la Vista Home:

Para la vista About:

Paso 4: Disfrutando su navegación

Antes de probar la navegación, es necesario modificar el mapeo de ruta modificado el los laboratorios anteriores. Asi vamos al archivo RouteConfig.cs. y lo dejamos con en un inicio:

Ahora si tienes especificado las acciones dentro el enlace, navegas entre las paginas Home, about y product.

Mientras navegas puedes ver como el URL son dirigidos a las acciones mas que a los nombres de las paginas como home.aspx, aboutus.aspx el cual viola completamente los principios MVC.

¿Qué hay para el tercer día?

Es la tercera sesión, hablaremos acerca de vistas parciales, validación usando notaciones de data, Razor(MVC4), Autenticación avanzada en MVC, Autenticación de formularios en MVC y mucho más. Los siguientes laboratorios podrían ser mucho más avanzados comparados al segundo día.