Aprender ASP NET MVC Paso A Paso en 7 Días

Aprender ASP NET MVC Paso a Paso en 7 días
Este artículo es parte de Aprender paso a paso ASP.NET MVC en 7 días 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
Contenido
 ¿Por qué el code-behind en tan bueno en ASP.NET?

 Problema número 1: Testeo Unitario
 Problema número 2: La realidad de la separación del código y la UI
 Nuestro Héroe MVC (Modelo, Vista y Controlador)
 Pre-Requisitos
 Lab 01: Creando una simple Aplicacion ASP.NEt MVC “Hola Mundo”
 Lab 02: Pasando datos entre el controlador y la vista
 Lab 03: Creando un simple modelo usando MVC
 Lab 04: Creando un simple formulario de entrada de datos MVC
 Lab 05: Usando Razor para crear vistas rápidamente
Como el nombre del artículo dice, aprender MVC, la agenda es simple, vamos a aprender
ASP.NET MVC en 7 días.
La manera como aprenderemos MVC en esta serie de artículos es haciendo laboratorios,
mirando los pasos detallados de cómo se hacen esos laboratorios.
Queriendo demostrar que el concepto MVC es igual entre ASP.NET MVC y SPRING MVC es que realizare
Aprender MVC con las dos tecnologías (para los amantes de Microsoft y para los amantes del software
libre).
Pueden revisar Aprender SPRING MVC Paso a Paso en 7 días (Día 1)
¿Porque el code-behind en tan bueno en ASP.NET?

Estoy seguro que todos los desarrolladores les gusta el concepto de code-behind. La aceptación
de algo nuevo como MVC, no es nada fácil para ellos.
Cuando hablamos de construir aplicaciones ASP.NET en una arquitectura de capas, ellas se
dividen en cuatro partes: UI (paginas ASPX), code-behind (archivos ASPX.cs), capa intermedia
(clases .NET) y finalmente la capa de Datos(Data layer).
Si se mira los aspecto de la distribución del código, el mayor código el cual tiene la lógica es la
capa intermedia o el code-behind (archivos ASPX.cs). La UI (Interfaz de Usuario) o archivos ASPX
son archivos HTML, los cuales son más acerca del diseñador de la interfaz de usuario, y la lógica
de acceso a datos son más o menos componentes estándar como los Enterprise Data Blocks.
Vamos a analizar los problemas.
Problema número 1: Testeo Unitario

De los aspectos del testeo unitario podemos excluir la Lógica de data y el UI HTML. Las clases
de lógica de datos son ya componentes testeados como Enterprise Data Block, entity data
context, o LINQ data context. Nosotros ya no tenemos que incluir esfuerzos en testear
separadamente el DAL. En caso que tú tengas una capa de acceso a datos personalizado este
sería fácil de testearlo como son simples clases .NET.
No hay ninguna lógica en testear ASPX HTML, como se trata más de apariencia.
La capa intermedia es nuevamente un simple clases .NET como lógica de data que se puede
fácilmente testear usando VSTS.
Ahora viene el punto más importante: el The code-behind tiene mucho de acción y testear
esto es una de las cosas más importantes. La única manera de invocar estos códigos es
haciéndololos de forma manual, desde una perspectiva de tiempo esto no sería una gran
opción.
El code-behind de ASP.NET está completamente atado con el objeto HttpContext de ASP.NET
lo cual hace dificultoso el testeo unitario.
Problema número 2: La realidad de la separación del código y la UI

Como dije previamente, los ASPX y los ASPX.cs, no pueden ser desacoplados, lo que reduce la
reutilización. Si, Microsoft dijo primero que el code-behind es diferente de la UI, pero entonces
ellos son solo archivos físicamente separados y no pueden existir sin uno del otro.
Por ejemplo digamos que el mismo código del botón click cuando se llama via HTTP POST podría
visualizar usando displayinvoice.aspx y cuando llamo via HTTP GEt podría mostrar en un tree
view. En otras palabras deberíamos como reusar el code-behind. Justo pienso como puedo
hacer esto usando el actual code-behind.
Nuestro Héroe MVC (Modelo, Vista y Controlador)

Esto es cuando MVC llega al rescate. El code-behind es movido a una simple clase .net llamado
Controller. Cualquier usuario que solicita primero llega al la clase Controller, la clase Controller
entonces invoca el modelo, y agrega el modelo a la vista para mostrarlo al usuario final.
Como este Controlador es una simple clase .NET, podemos reusarlo y hacer testeos unitarios
facilmente. Vamos a ver cómo podemos crear Aplicación MVC usando la Plantilla MVC proveída
por Visual Studio.
Pre-Requisitos
- Visual Studio 2012 (Cualquier versión). Esto incluye ASP.NEt MVC 4
Lab 01: Creando una simple Aplicación ASP.NEt MVC “Hola Mundo”
En este laboratorio crearemos un simple programa hola mundo, utilizando la plantilla MVC.
Crearemos un simple controlador, conecta el controlador a una simple página index.aspx y ver
la página en un Browser.
Paso 01: Crear el Proyecto

Crear un nuevo proyecto seleccionando Aplicación Web de ASP.NET MVC 4 y como nombre del
proyecto MyFistHelloWorld, en la siguiente ventana seleccionamos vacío.
Una vez hecho click en Aceptar, ya tiene hecho la estructura con las carpetas apropiadas, donde
puedes agregar controladores, vistas y modelos.
Paso 02: Agregar un controlador

Ahora vamos a agregar un nuevo controlador como se muestra en la siguiente figura.
Paso 03: Agregar una vista
Ahora que tenemos el controlado necesitamos agregar la vista. Hacemos click derecho en la
función Index el cual está en el controlador y seleccionamos Add View.
En el cuadro de dialogo indica el nombre de la vista, el cual debe ser el mismo que en el
controlador (Index) u desactiva usar una página de diseño o maestra, porque no queremos que
nuestra vista herede de un Master Page.
Una vez hecho en aceptar, podremos ver una simple página ASPX con el siguiente código HTML.
Paso 04: Ejecutar la Aplicación
Si haces Ctrl + F5 verás un error. Este error es obvio, porque no invocamos apropiadamente el
controlador/accion.
Si digitas en el browser la URL debes ser capaz de ver correctamente la vista.
Lab 02: Pasando datos entre el controlador y la vista

El controlador recibe la primera carga del modelo, la mayoría de veces nos gustaría pasar del
modelo a la vista para la visualización.
Para MVC nos gustaría ver el alcance limitado al controlador y la vista, en otras palabras nos
gustaría mantener datos cuando el golpe llega al controlador y alcanza la vista y después que el
alcance de los datos debe expirar.
Ahí es donde la nueva técnica de gestión de sesiones se ha introducido en el marco de ASP.NET
MVC, es decir el ViewData.

Paso 01: Crear proyecto y definir la vista de datos.
El primer paso es crear un proyecto y un controlador. En el controlador, definir la variable
viewdata, como mostramos en el código de abajo.
Paso 02: Mostrando el view data en la vista.
Lo siguiente es mostrar data en la vista pero usando. tag porcentaje. Uno de los puntos más
importantes a notas es que la vista no tiene cod-behind. Para mostrar la vista necesitamos
usar el tag <% en la página ASPX.
Paso 03: Ejecutamos la aplicación

Presionamos Ctrl+F5 y modificamos la URL en el Browse.
Lab 03: Creando un simple modelo usando MVC
En este laboratorio crearemos un simple modelo personalizado, esto con algunos datos y
mostrarlo en la vista.
Paso 01: Creamos un simple archivo de clase

El primer paso es crear un simple modelo personalizado el cual está en blanco con tres
propiedades: code, name, y amount. Crear un simple Proyecto MVC y hacer click en la carpeta
model y clic en Add New Item y seleccionar clase y asignarle el nombre Curstomer.
Paso 02: Definimos un controlador con acción

El primer paso es crear un controlador y agregar una simple acción que muestre el Customer.
Importar el namespaces del modelo en la clase controlador, creamos un objeto de la clase
Customer con algunos datos y lo pasamos a la vista llamado “DisplayCustomer”.
Paso 03: Creamos una vista fuertemente tipada usando la clase.
Necesitamos ahora unir los puntos de MVC, mediante la creación de vistas. Hace clic derecho
en el método DisplayCustomer dentro del controlador (Con realizado en el primer laboratorio).
Nota: Previamente es necesario que se compile el proyecto

La ventaja de crear una vista fuertemente tipada es que se pueden obtener las propiedades de
las clases en la vista pero digitando model y “.” como se muestra:
Abajo está el código de la vista (sintaxis Razor) el cual muestra los valores de las propiedades
del cliente. También podemos asignar una condición IF que muestre los clientes como un cliente
privilegiado si la cantidad está por arriba de 100 y un cliente normal si está por debajo de 100.
Paso 04: Ejecuta la aplicación
Ahora para ejecutar la aplicación presiona Ctrl+F5.
Lab 04: Creando un simple formulario de entrada de datos MVC

Cada proyecto pequeño o grande necesita un formulario de entrada de datos. En este
laboratorio crearemos una simple entrada de datos para nuestro cliente como se muestra:
Tan pronto como el usuario final ingrese los detalles y envíe los datos estos serán direccionados
a la siguiente ventana como muestra abajo:
Paso 01: Creando la Página de entrada de datos
El primer paso para crear una entrada de datos es usar las etiquetas form de HTML como se
muestra en el código de abajo. Lo más importante a notar es que la acción del botón es
apuntada al método del controlador llamado “DisplayCustomer”.
Para ayudarnos de Visual Studio y como ya sabemos toda página está relacionada a una acción
del controlador en el controlador Customer vamos a crear el metodo FillCustomer.
Después siguiendo los pasos anteriores de cómo crear una vista (Click derecho y Add View)
creamos la vista FillCustomer.
Paso 02: Creando el controlador
Arriba definimos la acción del formulario hacia el controlador a la función DisplayCustomer
Necesitamos obtener los datos de los controles HTML (form), llena el objeto y enviar el objeto
a la vista.
Debajo el código de DisplayCustomer, llena el objeto customer con los datos de la colección
Request.Form y envía los objetos a la vista DisplayCustomer.
Paso 03: Creando la vista para mostrar el objeto customer

El siguiente paso es crear la vista DisplayCustomer, seleccionada la opción vista fuertemente
tipada (realizada en los pasos anteriores).
Paso 04: Finalmente ejecutar el proyecto

Presionando las teclas CTRL + F5 ejecutamos el proyecto.
Y al hacer clic ek en botón enviar muestra la vista DisplayCustomer.
Lab 05: Usando Razor para crear vistas rápidamente

En nuestros laboratorios anteriores creamos un simple formulario de entrada de datos para
customer completamos el laboratorio de forma satisfactoria pero hubieron dos problemas:
 Los Código HTML fueron escritos manualmente. En pocas palabras esto fue poco
productivo, esto es como escribir código HTML usando el notepad.
 Agregado a esto, mucho del código manual fue también escrito en el controlador para
llenar los objetos y enviarlo a la vista.
En este laboratorio veremos cómo usar clases razor para minimizar el código manual e
incrementar la productividad.
Paso 01: Creando la clase Customer

Para crear la clase Customer ir al laboratorio 03.
Paso 02: Creando la entrada de formulario HTML usando clases Razor

Las clases Razor tienen funciones el cual te permite crear controles HTML con facilidad enviar a
la vista y ver el intellisense de las clases Razor.
Usando Razor puedes crear cualquier control HTML como TextBox , Label, ListBox.
En orden para crear una etiqueta forma para HTML necesitamos usar “Html.BeginForm”
El código de arriba genera el siguiente codigo HTML:
El razor HTML “BeginForm” toma tres parámetros nombre de la acción, el nombre del
controlador y el método HTTP (GET, POST).
Vamos a crear el formulario de entradas de datos:
Paso 03: Creando una vista Fuertemente tipada

Para crear el formulario con Razor es necesario que la vista se haya creado con la opción vista
fuertemente tipada como se realizó en el laboratorio 03. Pero si no se hizo esto en la parte
superior de la vista agregamos lo siguiente y hacer la vista fuertemente tipada.
Con esto ya podemos crear nuestro formulario en la vista FillCustomer.
Paso 04: Creando el controlador

La parte final es el codigo del controlador (Customer), el codigo del controlador ahora es más
simple, el objeto customer va ser auto llenado por nuestras clase razor.
y al final ejecutar y mostrará los datos
Muy bien, ahora vamos por unas por unas cheliñas para celebrar el cumplimiento de nuestro
primer dia con ASP.NET MVC.
¿Y que hay para el segundo Día?

Para el segundo día hablaremos acerca de Routing URL, fácil manera del testeo unitario MVC,
atributos del controlador y mucho mas.Los siguientes laboratorio van a ser más avanzados a
comparado con el primer dia. asi que realiza todos los laboratorios para que estes listo para el
segundo dia.
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 días y puedes revisarlo en los link siguientes:

 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?
¿Cómo 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 aún más confusión.
Así 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 hemos creado
en MVC (Modelo Vista Controlador) del día 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 tú 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 entonces 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 deberías 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 envía un requerimiento 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 día 1

Vamos a tomas el mismo proyecto de Customer (MyFisrtHelloWorld) que hemos desarrollado en la sección
anterior.
Paso 2: Cambiar Global.asax.cs

Todas las asignaciones de rutas son almacenadas 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 tú 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 qué 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 función acción invocada
será DisplayCustomer.
En caso su controlador tome parámetros, puede usar el {(llaves).Por ejemplo en el siguiente pedazo de código,
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 código, el cual significa cuando llamamos a http:/localhost/view/ViewCustomer esto

invocará al controlador Customer y llamara la función 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á estructurado 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 son
proporcionados por la URL.
Sería 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 en los laboratorios
anteriores. Así 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 más 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.
Contenido
 ¿Cuál es la Agenda?
 Lab 10: Vistas Paciales
 Lab 11: Validación usando Anotación de Data
 Lab 12: MVC4: Razor
 Lab 13: Seguridad en MVC(Windows Authentication)
 Lab 14: Seguridad en MVC(Forms Authentication)
 ¿Qué hay para el Cuarto Día?

En este día 3 veremos los siguientes cinco laboratorios:
 Vistas paciales
 Validación usando anotaciones de data
 Razor (MVC 4)
 MVC Windows Authentication
 MVC Forms Authentication
 Lab 10: Vistas Parciales
Cuando hablamos acerca de aplicaciones web, reusabilidad es la clave. Como desarrolladores MVC estaríamos
gustosos para crear vistas reusables. Nosotros gustaríamos crear vistas reusables como Vistas de cabecera y
pie de página y usarlos dentro de una vista MVC grande.
La vistas reusables podrían se logrados creando “Vistas Parciales”.

Paso 1: crear una simple vista
Para desarrollar este laboratorio vamos a crear un nuevo proyecto vacío MVC (MvcTercerDia).
El primer paso será crear una simple vista con un controlador. Puedes ver en la siguiente captura, Ahí hay una
simple vista llamada “Index.aspx” el cual será invocada vía HomeControlles.aspx.
Paso 2: Crear una simple vista parcial

Ahora que hemos creado la vista principal, es tiempo de crear una vista parcial el cual puede ser consumido
desde la vista “Index”. En orden para crear la vista parcial, click derecho sobre la carpeta view y agregar vista,
marcar el check box “Crear como vista parcial” como se muestra en la siguiente figura.
Paso 3: Llamar a la vista parcial en la principal.
Ingresar algo de texto o lógica en la vista parcial
Paso 4: Llamar a la vista parcial en la principal.

Finalmente llamar la vista parcial en la vista principal usando la función “Html.RederPartial” y pasar el nombre
de la vista en la función como se muestra en el siguiente código.
Tambien asegurarse que la vista parcial este en el mismo folder donde está su vista principal. Es caso de que
no este, entonces necesitaras pasar el path en la función RenderPartial. Puedes ver la siguiente figura se ha
movido la vista parcial en el folder Views/Home.
Paso 5: Ejecutar el programa ara ver la acción

Finalmente presionar Ctrl+F5, y veras como se carga la vista parcial.
Lab 11: Validación usando Anotación de Data

La validación de data es una de las principales cosas en cualquier aplicación web. Como desarrollador deberías
ejecutar la validación en el cliente (browser) y en el servidor. Así que probablemente le gustaría escribir la
validación de una vez y luego esperar el framework de validación para generar la lógica de validación en ambos
extremos.
Buenas noticias, esto es posible pero usando anotaciones de data. En MVC validas los valores del modelo.
Cada vez que la data llega desde el modelo tu preguntaras al modelo diciendo, es este la propiedad proveída?,
son los valores dentro del rango?.
Las Anotaciones de data son metadata el cual puedes aplicar en el modelo en el framework MVC validara
usando la metadata proveída.
En este laboratorio vamos a enfocar la validación usando anotaciones de datos. Lo primero que vamos a hacer
es, en el mismo proyecto (MVCTercerDia), crear una clase modelo Customer y una vista fuertemente tipada
de entrada de datos llamada Home.cshtml.
Asumiendo que tienes creado el modelo y la vista fuertemente tipada, vamos a empezar a aplicar Anotaciones
de Data.
Paso 1: Decorar el modelo con Anotación de Data.

Importante importar el espacio de nombres DataAnnotations como se muestra en el código de abajo.
Vamos a decir que tenemos un modelo Customer y queremos asegurar que el campo código es obligatorio.
Entonces aplicar el atributo “Required” como se muestra en el siguiente código. Si la validación falla y le
gustaría mostrar un mensaje de error, puedes pasar el “ErrorMessage” también.
Paso 2: Cambiar el codigo Home.cshtml

Ahora hay algunos cambios de código que deberíamos hacer en el código Home.cshtml. Dentro del body nos
gustaría mostrar el mensaje de error si la data no es correcto es es hecho usando el siguiente código.
También necesitamos codificar nuestro formulario de ingreso de datos. A continuación se muestra el

fragmento de código para el mismo. Note que la funcion “EditorForModel” automáticamente generara los
controles UI de acuerdo a las propiedades del modelo. Entonces no necesitamos crear el control de forma
individual como se hizo en los laboratorios anteriores.
Paso 3: Ahora en la clase controlador Customer.
Ahora en la clase controlador Customer agregamos la validación, cuando el formulario llama un post sobre el
controlador, te gustaría conocer si el estado del modelo es correcto o no. Esto puede hacerse verificando con
la propiedad ModelState.Isvalid. Si la propiedad es válida entonces llama a procedimiento de guardar o
muestra la vista “PostCustomer” (Solo muestra los datos del formulario), en caso sea falso entonces retorna
a la vista original “Home”, a continuación se muestra el código del controlador.
Paso 4: Probando la Aplicación.

Finalmente presionar Ctrl +F5, y al enviar el control en blanco mostrar el mensaje de error, pero esta validación
se realiza en el servidor, porque el controlador es quien valida.
Nota: Note que se ejecutó la acción post al método del controlador PostCustomer
Paso 5: Habilitando la validación en el cliente

En los pasos anteriores las validaciones se realizan en el lado del servidor, esto significa que al
momento de enviar el formulario que contiene errores de validación, el control pasa al servidor solo para
regresar con mensajes de error. Para evitar esta ida y vuelta se puede agregar capacidades del lado del cliente
en la vista Home.cshtml.
La validación en el cliente se puede realizar con jQuery Unobtrusive Validation, para lo cual hay que
referenciarlo en nuestro proyecto. Ejecutar el siguiente comando en Package Manager Console
(Herramientas/Administrador de paquetes de Biblioteca): PM> Install-Package
jQuery.Validation.Unobtrusive.
Ahora, ubicar el archivo web.config abrirlo y asegurar que existen las siguientes teclas de la sección
<appSettings> las claves ClientValidationEnabled y UnobtrusiveJavaScriptEnabled asignar el valor true:
Utilizar el ayudante Url.Content () para obtener las direcciones URL de los tres archivos de script, a saber.
jquery-1.4.4.js, jquery.validate.js y jquery.validate.unobtrusive.js. Estos archivos son necesarios para llevar a
cabo la validación del lado del cliente (home.cshtml).
Paso 6: Probando la Aplicación.
Finalmente presionar Ctrl +F5, entonces la al presionar el botón enviar la validación lo realizará en el cliente
sin ir al servidor.
Otros atributos de anotación de datos
La prueba resultaría:
Lab 12: MVC 4 – Razor
Hasta ahora este artículo ya estuvo usando Razor. Qué es Razor? sola para dar una respuesta corta. Este es
un tipo de vista para MVC. El problema desde el punto de vista Web Form este no se hizo pensando en MVC,
por lo que la sintaxis es un poco pesada.
Paso 1: Practica con sintaxis Razor

Ahora que ya tenemos una idea de lo que es Razor vamos ejecutar algunas sintaxis comunes Razor y tratar a
tener una idea de lo fácil que es Razor comparado con las vistas ASPX.
Práctica 1: Simple línea de código

Si quieres mostrar una simple variable puedes hacer algunas cosas como se muestra en el código de abajo.
Todos la sintaxis Razor empieza con @. Si tiene una simple línea de código no necesitas “{”. Razor se da cuenta
de la conclusión lógica.
Si comparas la sintaxis de arriba con una vista ASPX, necesitas tipear el código siguiente. Así que ¿No es una
sintaxis más simple, ordenado y ligero?.
Práctica 2: Múltiples líneas de código
Práctica 3: bucle Foreach y condición If

para bucles y condiciones if llega a ser más simple como se muestra en el siguiente código:
Práctica 4: No te preocupes por @

Si estás pensando si Razor es confuso con @ de Razor y @ de una dirección email, no te preocupes, Razor
entiende la diferencia. Para instanciar en la siguiente línea, la primera línea Razor ejecutará como un código
y la segunda línea de código lo entiende solo como una dirección email.
Práctica 5: Mostrar @
En caso quieras mostrar “@” solo tipea esto cada vez como se muestra en el siguiente código. Se mostrará a
la siguiente imagen.
Práctica 6: Mostrar HTML con Razor
En caso quieras mostrar HTML en el browser. Para instanciar una simple variable llamada como link el cual
tiene código HTML. Estoy mostrando la variable link en el browser.
Si ejecutas el código de arriba, te sorprenderías ver que este no se muestra como HTML, sino como una simple
pantalla como se muestra a continuación. Ahora como se muestra a continuación, Ahora eso no es lo que
esperamos. Nos esperábamos una pantalla HTML adecuado. Esto se hace mediante Razor para evitar ataques
XSS (Hablaremos de esto en secciones posteriores).
Pero no te preocupes, el equipo de Razor se ha hecho cargo de esto. Puedes usar ”Html.Raw” para mostrar,
la misma que se muestra en el siguiente código:
Lab 13: Seguridad MVC(Windows Authentication).

La seguridad es una de las cosas más importantes en cualquier aplicación independientemente, quien los
desarrolla, en cualquier tecnología, lo mismo puede decirse de MVC.
Antes de empezar este laboratorio una cosa que necesitamos entender es que MVC al final del día se
encuentra en el motor ASP.NET.
Nota: En este artículo no vamos a estar buscando en los fundamentos de la autenticación de windows y forms.
Vamos a implementar autenticación Windows en una aplicación MVC 4.
Ahora, una manera de implementar autenticación windows es realizando algunos cambios en nuestro
proyecto.
Paso 1: Habilitar la autenticación Windows.

El primer paso es habilitar la autenticación Window. Esto lo realizamos en el archivo de configuración
Web.config usando la etiqueta authentication y authorization que se muestra a continuación:
Paso 2: Solo algunos defectos.

En la plantilla MVC 4, hay un pequeño defecto. Esto ejecuta la autenticación Forms por defecto. Establezca las
etiquetas debajo de la etiqueta appsetings para evitar problemas.
Paso 3: Aplicando etiquetas de autorización en las acciones del controlador.

Una vez que tienes habilitado la autenticación Windows en el Web.config, usar la etiqueta “[Authorize]” y
especificar cuáles usuarios pueden tener acceso a los controladores y sus acciones.
Por favor note que el usuario debería estar presente en su windows Active Directory o su grupo local (en mi
caso uso windows 8 y en el administrador de usuarios y grupos- click derecho en Equipo-> Administrar), como
en mi caso el usuario ronald es mi usuario de grupo local.
Paso 4: Crear Aplicación en el Servidor IIS 8( Internet Information Server)

Tienes que asegurarte que tienes instalado el IIS en su equipo para lo cual lo puede verificar en el Panel de
Control-> Agregar o quitar Programas-> Activar características de windows.
Una vez agregado la característica anterior, ahora vamos a crear la aplicación en el IIS con la habilitación de
autenticación Windows solamente.
Cargamos en administrador de IIS y agregamos aplicación con el nombre MvcTercerDia, creamos un directorio
MVC_WINDOWS en donde se publicaran nuestra aplicación desde Visual Studio (esto lo veremos en el
siguiente paso).
Habilitamos la autenticación Windows en nuestra aplicación creada, seleccionando la opción Autenticación.
Paso 5: Publicando nuestra Aplicación

Una vez que ha creado la aplicación en IIS, es tiempo de publicar la aplicación a la carpeta de aplicación web.
Para lo cual hacemos click derecho sobre el proyecto (Explorador de proyectos de Visual Studio) y
seleccionamos Publicar.
Le damos la ruta (creada en el paso anterior, cuando creamos la aplicación en IIS) y le damos en publicar.
Paso 6: Ejecutar el controlador y la acción
Finalmente ejecutar el controlador y la acción (en el navegador digitarlo directamente) y ver como el cuadro
de autenticación Window para el ingreso del usuario y la contraseña. Esto validará de acuerdo a la autorización
que se asignó en el controlador Home.
Si las credenciales son ingresadas apropiadamente, deberías ser capaz de ver lo siguiente:
Lab 14: Seguridad MVC (Forms Authentication)

En el laboratorio anterior vimos cómo hacer autenticación windows. La autenticación Windows es ideal para
sitios web de intranet. Pero como pronto hablaremos acerca de sitios web para internet, crear y validar
usuarios de windows Active Directory/trabajar con grupos de usuarios no es una opción factible. Entonces en
este tipo de escenarios “Forms authentication” es la manera a seguir.
Paso 1: Definir la página Login y su controlador.

La primera cosa que necesitamos es definir el controlador el cual invocará la vista login.
Así tengo creado una simple acción index el cual invoca una vista llamado Login. Esta vista Login tomará
entradas como username y password.
Paso 2: Creando la vista Login.

El siguiente paso es crear el formulario Login el cual tomará el username y password. Para crear el formulario
y he usado la vista razor y las clases HTML helperñ En caso tu eres nuevo en clases HTML helper por favor
revisar el Lab 12.
Este formulario HTML hace un post a la acción “Login” del controlador “Home” y es usa el método Post. Así
cuando los usuarios presionan el botón enviar, este lanzara la acción “index”.
Paso 3: Validar las credenciales.

En la acción Index la primera cosa que necesitamos hacer es verificar si el usuario es correcto o no. Por ahora
tenemos en código el usuario y contraseña. Esto puede siempre ser reemplazado por consultas del servidor
SQL u otra fuente.
Una vez que hemos verificado las credenciales el siguiente paso es usar la famosa clase “FormsAuthentication”
y asignar la cookie diciendo que el usuario en correcto.
De modo que en la siguiente solicitud cuando el usuario llegue no tendrá que ser validado una y otra vez.
Después de que la cookie se establece es redireccionado a la vista “About” o de lo contrario te quedes en la
vista Login.
Paso 4: Atributo Authorize
También necesitamos usar el atributo “[Authorize]” dentro los controladores, los cuales queremos restringir
para los usuarios no autorizados.
Por ejemplo se puede ver el siguiente código para la acción “Index” del controlador “Home” que está decorada
con el atributo “Authorize”.
Si cualquier usuario no autorizado, accede directamente a cualquiera de estos controladores ellos serán
enviados a la vista Login es decir detrás del Index.
Paso 5: Cambiar el archivo web.config

Finalmente necesitamos hacer cambio en el famoso archivo “web.config” es decir habilitar la seguridad
“Forms”. La parte más importante en el código de abajo es la propiedad “LoginUrl”.
Paso 6: Vemos la acción en Autenticación Forms.

Si ahora llamas a index este directamente se muestra la vista Login, este test prueba que la autenticación
“Forms” está trabajando.
¿Que hay para el cuarto día?
En el cuarto día veremos una introducción a Jquery, Json, Controlador Asíncrono y diferencia entre variables
Viewdata y Tempdata, Viewbag y Session.
Contenido
 Lab 15: JSON, MVC y JQuery

 Lab 16: Gestión de Sesiones en MVC(ViewData, ViewBag, TempData y Variables Sesión)
 Lab 17: Controles Asíncronos
 ¿Que hay para el quinto día?

Lab 15: JSON, MVC y JQuery

En caso seas nuevo en JSON por favor lee esto antes empezar con este laboratorio, Acerca de JSON.
En este laboratorio vamos a exponer un simple objeto “Customer” de MVC en formato JSON y consumimos el
mismo usando Jquery.
Para este laboratorio por favor asegurarse que el proyecto el nombre del proyecto se MvcCuartoDia y crearse
use la plantilla de proyecto básico esto es necesario para incluir las librerías Jquery en el proyecto MVC.
Paso 1: Crear un simple modelo Customer

El primer paso es crear una simple clase modelo “Customer” en el proyecto.
Paso 2: Exponer el objeto “Customer” como JSON
Ahora agregamos un controlador “Customer”, para exponer el objeto customer en formato JSON necesitamos
usar “JsonResult” como se muestra en el siguiente código.
Por favor, ejecute el controlador con la acción JSON anterior para comprobar que el resultado JSON se muestra
correctamente. Si estas usando Chrome el resultado se muestra en el navegador, si este es Internet Explorer
este descargara un archivo.
Paso 3: Consumiendo el controlador JSON en Jquery

En caso seas nuevo en Jquery, por favor leer esto ¿Que es Jquery?
El siguiente paso es consumir los datos JSON usando una vista MVC. Asi que adelante Añadimos una vista con
el nombre AprenderJquery.cshtml
Lo primero es agregar la referencia a la librería Jquery en la parte superior de la página. en caso no encuentras
jquery en el proyecto esto significa que no has creado el proyecto usando la plantilla basica o si no puedes
instalarlo de forma manual usando la Consola de Administración de paquetes de Visual Studio, esto lo explico
al detalle en el artículo cargar vistas parciales en ASP.NET MVC usando Jquery Ajax o también usando CDN
como lo explico es este tips de CDN.
Usando sintaxis html
Usando sintaxis razor
Puedes entonces hacer una llamada al controlador que está exponiendo en formato JSON usando el método
“getJson” como se muestra más abajo. Este toma tres parámetros:
El primer parámetro en “getJson” es el URL MVC JSON con el formato de estructura controller/action.
El segundo parámetro es la data a ser pasada. Por ahora esto es nulo como estamos más interesados en
obtener datos JSON en lugar de publicar los datos.
El último parametro es el método de devolución de llamada “Display” el cual será invocado cada vez que
obtengamos datos JSON del controlador. La función ”Display” también está disponible en el siguiente código.
Estoy asignando una alerta con la propiedad name. Puedes ver como solamente tipeo data.CustomerCode,
no convierto los datos JSON estos son automáticamente convertidos a objetos javascript.
El código completo en la vista MVC lo mostramos abajo. Se creado un simple botón HTML y dentro el evento
click en donde se está llamando al método javascript “getJson” el mismo que hace una llamada al controlador
JSON y muestra la data JSON en una alerta javascript.
La vista anterior es invocada usando el método “MostrarJson” del controlador Customer creado
anteriormente.
Paso 4: Ejecutar la aplicación y ver el dato

Después de haber hecho todos los pasos es hora de ejecutar el proyecto(Ctrl+F5) y digitar en la url
http://localhost:50360/Customer/mostrarJson para ver la belleza JSON en ejecución.
Lab 16: Gestión de Sesion en MVC (ViewData, ViewBag, TempData y variables sesión)
La meta principal en MVC es crear aplicaciones web y aplicaciones web usando el protocolo HTTP. Cuando
envías una solicitud a la aplicación MVC se atiende la solicitud y se olvida de la solicitud. La próxima vez que
el mismo usuario envía la solicitud MVC lo trata como una completa nueva solicitud.
Ahora piensa en la siguiente situación:
 El usuario final envía la solicitud al sitio MVC

 MVC envía una página de logueo
 El usuario ingresa detalles adecuados y envía los datos a la aplicación MVC.
 MVC valida el usuario y enviar la página inicial del sitio. La aplicación MVC ahora se olvida todo lo
relacionado con el usuario ya que es apátrida.
 El usuario hace clic en uno de los link de la página inicial. Esto es enviado a la aplicación MVC y porque
la aplicación MVC se ha olvidados de todo lo relacionado con el usuario, le envía una página de inicio
de sesión para la autenticación de nuevo… el usuario se sentirá extraño.
Este resumen necesitamos tener algunos tipos de mecanismos el cual nos ayudara a recordar estados entre
la solicitud y la respuesta de MVC.
Hay 3 maneras de mantener estados en MVC y estas maneras pueden ser usadas dependiendo de qué capa a
qué capa se navegas.
Temp Data: Ayuda a mantener los datos sobre las redirecciones para una única solicitud y respuesta. Ahora la
redirección puede ser de controlador a controlador o de controlador a vista.
View Data: Ayuda a mantener datos cuando se mueve de controlador a la vista.
View Bag: Este es un contenedor dinámico alrededor de vista de datos. Cuando usamos el tipo “viewbag” la
conversión no es requerida. Utiliza una clave dinámica interna.
Variables sesión: Usando variables sesión podemos mantener datos hasta cerrar el navegador.
Demostraremos los fundamentos anteriores con una demostración.
Paso 1: Crear dos controladores “Default1” y “Default2”.

Agregar dos controladores Default1 y Default2.
Paso 2: Establecer Sesion, tempdata, viewdata y viewbag
En el controlador “Default1” dentro del método “Index” asignamos valores a sesión, tempdata, viewdata y
viewbag como se muestra en el siguiente código. Una vez que hemos asignado los valores hacemos una
redirección a la acción “AlgunaOtraAccion” el cual pertenece al controlador “Default2”.
Paso 3: Leer valores sesión, tempdata, viewdata y viewbag

En el controlador “Default2” capturamos para leer valores asignados en el controlador “Default1”. Una vez
que los valores son leídos invocamos a la vista llamada “VistaDatos”.
Por favor note que se está asignando “ViewData” y “ViewBag” antes de redireccionar a la vista.
La vista “VistaDatos” solo muestra los datos presentados en “TempData”, “Viewdata”, “ViewBag” y “Session”.
Vamos a habilitar un punto de depuración en las acciones de ambos controladores y vamos a ir al controlador
Defualt1 y a su método Index http://localhost:50360/default1/index. En esta acción la sesión, tempdata,
viewdata y viewbag son cargadas. Debajo podemos ver como se muestran los datos.
Ahora de aquí vamos a redireccionar al controlador “Default2” acción “AlgunaOtraAccion”.
En el controlador podemos ver que obtenemos las variables “TempData” y “Session” pero no “ViewData y
“ViewBag”(Ver str3 y str4 con asignados null). En otras palabras “ViewData” y “ViewBag” no hacen
persistencia de datos en redirección mientras “TempData” y “Session” si lo hacen.
Cuando la vista se invoca podemos ver todos los datos. En otras palabras los datos “ViewData” y “ViewBag”
persistieron del controlador a la vista. Y también los datos “TempData” y “Session” persistieron.
Ahora cuando la vista vista invocada he agregado un HiperlInk “Hazme Click” el cual invoca a la acción “Index”
del controlador “Default1”. Esto es para simular una nueva solicitud.
Cuando se hace click en el hipervínculo. Todas las otras variables se apagan, solo la variable “Session” persiste.
Lo podemos ver en la figura siguiente. Esto significa que las variables “Session” pueden persistir entre
solicitudes.
Debajo está una tabla resumen que muestra los diferentes mecanismos de persistencia.
Lab 17: Controler Asíncronos

Las aplicaciones MVC al final del día son aplicaciones web los cuales son hospedados dentro de IIS. Ahora
cuando cualquier solicitud llega al controlador MVC este genera un hilo del hilo pool y sirve a esta petición.
En otras palabras el servidor Web IIS mantiene un grupo de hilos en lugar de crear hilos a partir de cero una y
otra vez para obtener beneficios de rendimientos.
Vamos asumir que un servidor web ha creado un pool de hilos de tamaño 2. Ahora esto es solo una suposición
porque un pool de tamaño 2 es muy hipotético. Pero para hacer cosas simples consideramos que los pool de
hilos son de tamaño 2.
Vamos a decir primero que la solicitud llega al sitio, IIS tira un objeto de pool de hilo ya realizado y empieza a
servir la petición. Mientras tanto vamos a decir llega la segunda solicitud en lo que de nuevo el IIS se tira un
hilo del pool de hilo y empieza a servir la segunda petición.
Ahora lo divertido empieza cuando llega la tercera solicitud. El servidor IIS no tiene más objetos de hilos en el
pool como ya ya han sido servidos a “request1” y “request2”. Asi que el servidor solo mueve la tercera solicitud
a un modo de espera o el servidor puede enviar un mensaje ”503 ocupado” para el cliente.
Esta situación es denominada como “Thread Starvation”. La situación Thread Starvation se pueden superar al
hacer la solicitud “Asincrona”. Así que la petición llega e inmediatamente la solicitud se procesa de manera
“Asincrona” y soltando el hilo que sirva la solicitud inmediatamente.
Así que para evitar esto podemos lograr lo mismo, haciendo nuestros controladores “Asincronos”.
Ahora vamos a entender paso a paso como implementar controladores asíncronos en MVC.
Paso 1: Heredar de la clase AsyncController

Considerando la siguiente clase controlador “HeavyController” el cual tiene una acción “AlgunMetodoHeavy”
y esta acción espera 20 segundos. Así que vamos a entender cómo podemos hacer este simple controlador
Asynch.
Así que el primer paso es heredar de la clase “AsyncController”.
Paso 2: Marcar métodos con el anexo Async

El siguiente paso es añadir la palabra Async después de los métodos. Asi como podemos observar
“AlgunMetodoHeavy” ha sido cambiado a “AlgunMetodoHeavyAsync”.
La lógica de código de Heavy es decir “Thread.Sleep()” is movido a un metodo diferente y este método es
invocado usando la tarea de la librería paralela de “AlgunMetodoHeavyAsync”.
Cada vez que una “Task” o un “Thread” es iniciado nosotros incrementamos el contador de
OutstandingOperations pero usando “AsyncManager” y cada vez que una tarea multi-threaded es completada
decrementamos el contador.
Paso 3: Crear el método completado

Ahora una vez todas las tareas multi-threaded completadas y el OutstandingOperations está cero necesitamos
retornar la vista. Así para el mismo necesitamos crear un método ActionResult con la palabra Completed
anexada. Este método se llama cuando todas OutstandinOperations son cero.
Paso 4: Asegurarse de crear la vista “AlgunMetodoHeavy.cshtml”

También asegurarse de agregar la vista “AlgunMetodoHeavy” con el siguiente texto dentro.
Paso 5: Ejecutar y disfrutar
Ahora digitar en el navegador “http://localhost:50360/heavy/AlgunMetodoHeavy” y ver la salida.
¿Que hicimos en los últimos 4 días?
Este artículo es la continuación de Aprender paso a paso ASP.NET MVC en 7 días y puedes revisarlo en los link
siguientes:

Cuál es la agenda
En el día 5, veremos la manera de empaquetar y minificar para maximizar el rendimiento de las
aplicaciones MVC. También veremos el concepto y ventajas del modelo de vista que no es sino
un puente entre el modelo y la vista.
 Lab 18: Empaquetamiento y Minificación en MVC

 Lab 19: Modelo vista en MVC
 Lab 20: Manejo de Excepciones
 Lab 21: Área MVC
 ¿Que hay para el sexto día?
Lab 18: Empaquetado y Minificación en MVC

Ambos conceptos empaquetado y minificación ayudan a incrementar el rendimiento
Entendiendo el Empaquetado
Siempre los proyectos Web necesitan archivos CSS y JavaScript. Normalmente se realiza una
petición al servidor por cada archivo CSS y JavaScript, y si se tienen varios de estos archivos hace
que la carga de las páginas sea lentas. Empaquetarlos nos ayuda a combinar múltiples archivos
JavaScript y CSS en un solo objeto en tiempo de ejecución, combinando así múltiples solicitudes
en una sola solicitud que a su vez ayuda a mejorar el rendimiento.
Por ejemplo considere la solicitud de una página en la siguiente imagen. Las solicitudes son
capturadas usando la Herramienta de desarrollo de Chrome. Esta página consume 2 archivos
“Javascript1.js” y “Javascript2.js”. Cuando esta página es solicitada esta hace tres peticiones al
servidor.
 Primera para la página “Index”
 Segunda solicitud para el archivo JavaScript “Javascript1.js”
 Tercera solicitud para el archivo JavaScript “Javascript2.js”
Ahora si piensas un poco en el escenario de arriba puede llegar a ser peor si tenemos muchos
archivos javascript (especialmente archivos JQuery) resultado múltiples solicitudes que
reducirían el rendimiento.
Si somos capaces de combinar de alguna manera todos los archivos JS en un solo paquete y se
soliciten como una única unidad, esto se traduciría en un mayor rendimiento (ver la siguiente
imagen que tiene una sola petición).
Entendiendo la Minificación
La minificación reduce el tamaño de los archivos script y CSS, eliminando espacios en blanco,
comentarios, etc. Para el ejemplo de abajo tenemos un simple código javascript con
comentarios.
Después de aplicar la minificación los códigos javascript se verán como en la imagen de abajo.
Puedes ver como son eliminados los espacios en blanco y comentarios para minimizar el tamaño
del archivo e incrementar el rendimiento debido a que el tamaño del archivo ha sido reducido
y comprimido.
Vamos a demostrar un simple ejemplo de empaquetado y minificación con MVC paso a paso.
Paso 1: Crear un proyecto con la plantilla en blanco
Para entender el empaquetado y minificación, vamos a seguir adelante y crearemos un
proyecto MVC en blanco. En este vamos a agregar una carpeta “Script” y dentro de este, vamos
a agregar dos archivos javascript como se muestra en la siguiente figura.
El siguiente código es para el archivo “JavaScript1.js”
El siguiente código es para el archivo “JavaScript2.js”
Paso 2: Crear un controlador que llame a una vista

Ahora vamos a seguir y crear a un controlador el cual llame a una vista llamada “MiVista” es
cual consume ambos archivos javascript.
Agregamos la vista MiVista y consumimos los archivos javascript.
Paso 3: Ejecutar y ver como se hacen multiples llamadas

Ahora ejecutamos la aplicación MVC en Google Chrome, Presione la combinación de teclas
Ctrl+Shift+I para ver la siguiente salida. Puedes observar que hay tres solicitudes.
Paso 4: Referenciando a “System.Web.Optimization”

El empaquetado y minificación es hecho por el namespace “System.Web.Optimization”. Ahora
este DLL no es parte del framework .NET o ASP.NET. Necesitamos usar NUGET para descargar
esta DLL. Vamos a NUGET y buscar ASPNET.Web.Optimization.
NUGET es una herramienta cliente, que se agrega al Visual Studio y nos permite administrar y
consumir paquetes. La galería de NUGET es un repositorio central usado por todos los autores
de paquetes.
Paso 4: El archivo de configuración de paquete

Ahora este paso depende de qué tipo de plantilla MVC hemos seleccionado a la hora de crear
nuestro proyecto. Si hubiéramos seleccionado la plantilla “Basic” entonces el archivo
“BundleConfig” ya se crearía y como nosotros hemos seleccionado la plantilla “Blanco”
entonces tenemos mucho trabajo que realizar.
Entonces sigamos y agreguemos la clase “BundleConfig” y creemos un método

“RegisterBundles” como se muestra en el siguiente código. En el código de abajo “bundles.add”
dice que agregue todos los archivos javascript que están dentro de la carpeta “Scripts” a un
paquete llamado “Bundles”.
Nota importante: No olvidar importar el namespaces “System.Web.Optimization” o de lo

contrario se genera un error.
Paso 6: Llamar el archivo de configuración del empaquetado desde el archivo global.asax.cs
En este paso no es necesario si se ha creado el proyecto utilizando la plantilla MVC “Básico””.
Pero como nosotros hemos creado el proyecto utilizando la plantilla MVC “Blanco”, entonces
tenemos que abrir el archivo global.asax.cs y en el inicio de la aplicación llamar el método
“RegisterBudles” como se muestra en el siguiente código.
Paso 7: Enlazar el empaquetado en la vista

Una vez que el empaquetado es hecho necesitamos eliminar el tag “script” y llamar la dll
“Optimization” para enlazar el empaquetado.
Debajo está el código en la cual empaquetaremos ambos archivo javascript en un único objeto,
evitando así llamada de solicitud múltiple por cada archivo javascript. En el empaquetado
completo se agrega la vista MVC.
Paso 8: Mirar el empaquetado y minificación en tiempo real.
Para mostrar el empaquetado y minificación en tiempo real. Ejecutamos nuestro proyecto en
Google Chrome y presiona la combinación de teclas CTRL+SHIFT+I(Herramienta del
Desarrollador) y puedes ver la magia ahí en donde se muestra una sola llamada para ambos
archivos javascript.
I hacemos click en la pestaña Preview podemos ver que ambos archivos JavaScript han sido
unificados. Si la minificacion también se ha realizado Recordemos nuestro archivo java script
original.
Como puedes ver en la salida de abajo, los comentarios han sido eliminado, los espacios en
blanco son removidos y el tamaño del archivo se reduce y es más eficiente.
Lab 19: Modelo Vista MVC
Teoría
Una vista modelo es una simple clase que representa datos a ser mostrados en la vista.
Por ejemplo abajo esta un simple objeto CustomerModel con propiedades “CustomerName” y
“Amount”.
Pero cuando el modelo de objeto “Customer” es mostrado en la vista MVC esta muestra algo
como se puede observar en la siguiente figura. Este tiene “CustomerName”, “Amount” y un
campo plus “Customer Buyin Level”.
“Customer Buying Level” (Nivel de compra de clientes) es un indicador de color el mismo que
indica que tan agresivo es la compra de los clientes.
El color de “Customer buying Level” depende del valor de la propiedad “Amount”. Si la cantidad
es mayor que 2000 entonces el color es rojo, si la cantidad es mayor que 1500 entonces el color
es anaranjado y el caso contrario es color es amarillo.
En otras palabras “Customer Buying Level” es una propiedad extra el cual es calculado en base
de la la cantidad (cantidad).
Por lo que la clase viewmodel “Customer” tiene tres propiedades
 El textbox “TxtCustomerName” toma datos de la propiedad “CustomerName”

 El textbox “TxtAmount” toma datos de la propiedad “Amount” del modelo como este
es
 “CustomerBuyingLevelColor” muestra el valor del color dependiendo del valor
“Amount”.
¿Qué tipo de lógica contendrá la clase view model?
La clase view model puede tener los siguientes tipos de lógica:
 Lógica de transformación de color: Por ejemplo tú tienes una propiedad “Grado” en el

modelo y te gustaría mostrar en la UI el color rojo para el nivel de grado alto, color
amarillo para el nivel de grado bajo y verde para el grado OK.
 Lógica de transformación de formato de datos: Si tu modelo tiene una propiedad
“Estado” con el valor “Casado” y “Soltero”. En la UI te gustaría mostrarle como un
checkbox el cual es marcado si “casado” y desmarcado si es”soltero”.
 Lógica de agregación: Tienes dos clases modelo diferentes “Cliente” y “Direccion” y
tienes una vista el cual muestra ambos datos “Cliente y “Dirección” en una sola vez.
 Estructura Downsinzing: Tienes un modelo “Cliente” con propiedades “NombreCliente”
y “CodigoCliente” y quieres mostrar solo”NombreCliente”. puedes crear un modelo
contenedor alrededor y exponer las propiedades necesarias.
Vamos hacer un pequeño laboratorio para entender el concepto modelo de vista MVC usando
la siguiente muestra el cual hemos discutido previamente.
Usare el enfoque de arriba hacia abajo para crear la pantalla de arriba:
 Paso 1: Crear el modelo “Customer”

 Paso 2: Crear el ViewModel
 Paso 3: Consumir la ViewModel en la vista.
Paso 1: Creando el modelo Customer

Así vamos a seguir adelante y crear un modelo “Customer”, en nuestro proyecto
“MVCQuintoDia”, con las propiedades de abajo.
Paso 2: Creando la vista modelo
Lo siguiente es crear una clase ViewModel el cual contendrá al modelo “Customer” y agregara
propiedades de UI. Asi que vamos a crear una carpeta “ViewModels” y en esta agregar una clase
“CustomerViewModel”.
Abajo va el código para la clase “CustomerViewModel”. Ahora algunos puntos importantes

acerca de la clase view model:
 Puedes ver en la clase de abajo como la clase “CustomerviewModel” contiene la clase

“CustomerModel”.
 También un punto iimportante que hemos de crear propiedades el cual va con la
convención de nombres de UI (txtName, txtAmount, lblCustomerLevelColor,etc).
 Ahora para lo más importante mirar el codigo para a propiedad “CustomerlevelColor”,
este muestra el color dependiendo de la cantidad (Amount) de ventas del cliente
(Customer). Una “ViewModel” existe para este tipo de código puente, el cual conecta
el modelo y la vista.
Paso 3: Consumiendo el ViewModel en la vista

El siguiente paso es crear un controlador, el mismo que pasa algunos datos como se muestra
en el siguiente código.
El siguiente paso es crear vista fuertemente tipada, donde podamos consumir la clase
ViewModel. En caso no estes enterado de vistas fuertemente tipadas en MVC por favor revisar
Aprender ASP.NET MVC Dia 1, Laboratorio 04.
Como puedes ver la vista no está decorada o se puede decir enlazada con la clase modelo. Lo
más importante es mirar que la vista está limpia. Esto no tiene código para la toma de decisiones
para la codificación de colores. Estos códigos se han incluido dentro de la clase ViewModel. Esto
hace que View Model sea un componente esencial de MVC.
Paso 4: Probando la Aplicación
Una vez terminado es momento de probar la aplicación para lo que presionamos Ctrl+F5.
ViewModel sería Composición o Herencia

Muchos arquitectos cometen errores creando una clase ViewModel como herencia. Si tú ves
arriba la clase ViewModel es creada por composición y no por herencia.
¿Porque composición tiene más sentido? si visualizas nosotros nunca decimos “esta pantalla es
hijo de los objetos de negocio”, eso sería una declaración extraña.
Nosotros decimos “esa pantalla usa esos modelos”. Asi que es muy claro que sea una relación
usando y no una relación es un (padres e hijos).
Algunos escenarios donde la herencia fallara:
 Cuando tú no quieres algunas propiedades del modelo en tu vista.

 Cuando tú tienes una vista el cual usa múltiples modelos.
Así que no sean atraídos por la idea de la creación de un ViewModel mediante herencia de un
modelo que puede terminar en un problema Liskov.
Esto se parece a un pato, patito como un pato, pero no es un pato. Parece que un modelo tiene
propiedades como un modelo, pero no es exactamente un modelo.
Imagen de http://tomdalling.com
Ventajas de ViewModel
Reusabilidad. Ahora que el código ha sido objeto de una clase. Se puede crear el objeto de esta
clase en cualquier otra tecnología (WPF, Windows, etc) fácilmente.
Testeo: No necesitamos testear manualmente para probar la apariencia de la UI. Porque
nuestro código de UI ha sido movido a la librería de clase, podemos crear un objeto de esta
clase y realizar testeo unitario. Debajo un simple código de testeo unitario, el cual demuestra
el testeo unitario de la apariencia de UI y la lógica. Puedes ver como las pruebas de color es
realizado automáticamente en lugar de algunos testeos manuales.
Lab 20: Manejo de Excepciones
Introduccion
Cuando se trata de manejo de excepciones, el bloque try...catch es la opción favorita de los
desarrolladores .NET. Por ejemplo en el siguiente código hemos envuelto el código dentro de
try..catch y si hay excepciones invocamos a una vista “Error” en el bloque catch.
El gran problema con el código de arriba es la reusabilidad del manejo del código excepciones.
MVC proporciona a reutilizar el código de manejo de excepciones en tres niveles:
A través de acciones dentro del mismo controlador: Puedes usar el evento “OnException”
donde escribes la lógica el mismo que puede ser reutilizado a través de “Acciones” dentro del
mismo controlador.
A través de cualquier controlador: En MVC podemos usar “FilterConfig” para crear un atributo
el cual será aplicado a cualquier controlador y cualquier accion.
A nivel de proyecto: manejando UsingApplication_Error en Global.asax. Así que cuando la
excepción se genera desde cualquier parte del proyecto MVC, este será ruteado a un manejador
de error central.
Vamos paso a paso a demostrar las 3 maneras de arriba del manejo de errores en MVC.
Paso 1: Agregar un controlador y la acción que lanza el error

Así que lo primero es agregar un simple controlador y la acción que lance algunos tipos de
excepciones. En el siguiente código puedes ver que hemos agregado un controlador
“TesteandoControlador” con una acción “TestearMetodo”, donde hemos lanzado una
excepción de división por cero.
Por lo que si ejecutar la acción anterior terminará con un error como se muestra en la siguiente
figura.
Paso 2: Crear una vista Error
Ahora una vez que el error es capturado por cualquiera de los tres métodos descritos
anteriormente nos gustaría lanzar una página de error para mostrar el propósito. Por lo que
vamos a crear una simple vista por nombre “Error” como se muestra en la siguiente imagen.
Ahora que tenemos un error y también una vista “Error” es tiempo de hacer la demostración
usando las tres maneras. Por lo que primero vamos a empezar con “OnException” es decir
código reutilizable en acciones pero dentro del mismo controlador.
Paso 3: Reutilizar a través de acciones dentro del mismo controlador (OnException)

Para implementar la excepción vamos al controlador “TesteandoController” y sobrescribimos
el método “OnException” como se muestra en el siguiente código. Este método se ejecuta
cuando ocurre cualquier error en cualquier acción del controlador “TesteandoController”.
El nombre de vista es decir “Error” es asignado a la propiedad result del objeto “FilterContext”
como se muestra en el siguiente código.
Ahora si ejecutas la aplicación (CTRL+F5), llamando a “TestearMetodo” del controlador
“TesteandoController”, se verá la vista “Error” como la siguiente imagen (Ojo en entorno de
desarrollo se lanzará el error en Visual Studio, pero en entorno de ejecución se lanzará la vista
“Error”, pasar por alto en Visual Studio para ver el error).
El método “OnException” ayuda a proporcionar manejador de excepciones para un controlador

específico pero que si queremos reutilizar la lógica de excepción a cualquier otro controlador y
cualquier acción esto no se podría. Es donde tenemos que utilizar “FilterConfig” una manera en
la cual hablaremos en el siguiente paso.
Paso 4: Reutilizar a cualquier acción y cualquier controlador (FilterConfig)
Dentro de Web.Config simplemente habilitamos “CustomErro rs” como sigue.
Dentro de la carpeta App_Start abrimos FilterConfig.cs y nos aseguramos que
HandleErrorAttribute es agregado a GlobalFilterCollection.
HandleErrorAttribute en el nivel global confirma que la excepciones lanzadas por cada acción
en todos los controladores serán manejados.
En el archivo Global.asax dentro de Application_Start el método RegisterGlobalFilters es
invocado.
Esto hace que todas las excepciones lanzadas por cualquier método dentro de todos los
controladores retornen la vista “Error” presente dentro la carpeta Shared.
Manejo de error a nivel de controlador, en donde todos los errores presentes en las acciones
del controlador “TesteandoController” serán administrados.
Para hacer que nuestra vista “Error” una vista fuertemente tipada del Modelo
System.Web.Mvc.HandleErrorInfo y entonces usar la palabra clave @Model para acceder a sus
miembros. Uno de sus miembros es el objeto Exception.
El resultado sería el detalle de la vista Error.

Paso 5: Manejo de error a través de proyecto (Application_Error).
Para administrar errores a través de proyecto MVC, podemos usar numerar al evento
“Application_Error” dentro del archivo Global.asax y escribir la lógica de manejo de error dentro
el mismo.
Application_Error es un evento a nivel de aplicación, podemos definir dentro del archivo
Global.asax. El mismo será ejecutado cada vez que hay una excepción no controlada en la
aplicación.
Si este es el punto, ¿Porque no usar Application_Error siempre?
Aquí están las ventajas de HandleError sobre Application_Error:
 Con HandleErrorAttribute obtenemos más control sobre el manejo de excepciones.

HandleError nos permite administrar errores diferentes para diferentes controladores
y acciones fácilmente donde en Application_Error para obtener esta característica se
toma la ayuda del bucle interruptor.
 Una vez que esté en Application_Error estas fuera de MVC y perderás ControllerContext
y entonces no puedes hacer cosas fácilmente posibles con HandleError.
Lab 21: Área MVC
¿Qué es un área y porque área?

En ASP.NET MVC tenemos un concepto de áreas el cual nosotros podemos partir nuestro
sistema en módulos y organizar nuestro proyecto de una mejor manera.
Asumo que tenemos un sistema el cual consiste de dos módulos Customer y Order Processing.
Normalmente cuando creamos un proyecto ASP.NEt MVC nuestra estructura consiste de 3
carpetas (Controller, Model y Views). Entonces la estructura sería como esto.
Como puedes ver no está organizado. Cuando se trata de administrar código será muy difícil.
La imagen presenta una estructura de proyecto con e módulos. Imagina una situación donde
tengamos cientos de módulos en nuestro sistema.
Ejemplo de áreas en el mundo real

Los países están divididos por estados para que el desarrollo y la administración sean fácil.
Justo como el mundo real usaremos el concepto de área en ASP.NET MVC para dividir nuestro
sistema en módulos. Un área representa un módulo pero significa agrupación lógica de
controladores, modelos y vistas.
¿Cómo Usar Áreas?
Paso 1: Agregar Áreas usando una Plantilla MVC

Para agregar área hacer click derecho en el proyecto y seleccionar Add>>Área como se muestra
en la imagen siguiente:
Paso 2: Comience ubicando archivos pertinentes a áreas pertinentes.
Ubicar todos los archivos relacionado a áreas respectivas como se muestra en la siguiente
figura. Dentro de la figura de abajo se puede ver que hemos creado dos áreas “Customer” y
“Order”, Y cada uno de estas áreas tiene sus propias Vistas, Controladores y Modelos.
Nota: El Área es una agrupación lógica no física, por lo que no se crean dlls separadas por cada
área.
¿Cuál es la diferencia entre áreas y carpetas?

Uno se puede hacer la pregunta porque debemos usar para nuestro sistema áreas para separar
en módulos cuando podemos simplemente utilizar las carpetas. En pocas palabras, la respuesta
para esta pregunta es “Para evitar el enorme trabajo manual”.
Para lograr la misma funcionalidad utilizando carpetas se tiene que hacer las siguientes cosas.
 Crear la estructura del módulo manualmente( Una carpeta por cada módulo, Tres
carpetas adicionales por cada módulo llamado COntroller, Views y Model, un archivo
Web.Config por cada módulo)
 Crear una ruta personalizada por cada módulo Controller.
 Crear un motor de vista personalizada para cada módulo para buscar la vista en lugares
personalizados en lugar de ubicaciones predefinidas (Views/{Controller} ó
Views/Shared).
Buscar Vista por defecto
Buscar vista Personalizada
¿Que hay para el sexto día?

¿Que hicimos en los últimos 5 días?
Este artículo es la continuación de Aprender paso a paso ASP.NET MVC en 7 días y puedes revisarlo en los link
siguientes:

¿Cuál es la agenda para este dia 6?

Para el día 6 tenemos 5 grandes laboratorios:
 Lab 22: Modos de Visualización(MVC para móviles).- Soporte móvil usando la

característica “DisplayMode”
 Lab 23: Proveedor MVC OAuth.- Integrar la aplicación usando Facebook, Twitter o
cualquier otros sitios usando “OAuth”.
 Lab 24: Enlazador de Modelo MVC: Uso de enlazadores de modelos para enlazar la
interfaz de usuario y las clases del modelo, si los nombres de propiedad son diferentes.
 Lab 25: Diseño Razor.- Sintaxis Razor
 Lab 26: Métodos de ayuda Html Personalizado.- Creando tu propio motor de vista
personalizado.
 ¿Que hay para el último día?
Lab 22: Modos de Visualización (MVC para móviles)
Introducción
Este es un mundo de pequeños dispositivos es decir móviles. Como un desarrollador MVC se
espera un gran apoyo de la plantilla MVC de Microsoft para el mismo. Ahora las pantallas de
escritorio y pantallas de móviles tienen una alta variación en tamaño.
Si nos gustaría crear diferentes pantallas para escritorio y diferentes pantallas para móviles. Por
ejemplo crearíamos “Home.aspx” para escritorio normal y “Home.mobile.aspx” para móvil. Si
MVC puede automáticamente detectar el tipo de dispositivo y redireccionar a la página
apropiada esto salvaría mucho trabajo. Esto es automatizado usando “MVC Display Mode”.
Cuando cualquier solicitud HTTP llega a la aplicación web esta solicitud HTTP tiene un valor
llamado “User Agent”. Este valor “User Agent” es usado por el modo de visualización MVC (MVC
display mode) y la vista apropiada es recogido y redireccionado por el dispositivo. Vamos hacer
una demo y ver en directo.
Paso 01: Crear Paginas apropiadas

Así que vamos a crear un proyecto de ejemplo MVC con el nombre MVCSextoDiay y de tipo
Básico. Luego vamos agregar 2 vistas “index.aspx” para escritorio y “Index.Mobile.cshtml” para
móvil como se muestra en la siguiente figura.
Nota: El nombre de la vista “Index.Mobile” tiene que ser igual para que lo reconozca como una
vista para dispositivos móviles. Adicionalmente en esta vista se debe introducir un texto
identificativo por ejemplo: “Este es para Pantallas Pequeñas Móviles”.
También vamos agregar un controlador llamado”Inicio” en cual invocará a la vista “index”.
Nota: Puedes ver en el siguiente código que hemos creado un action result como index. Porque
nuestro nombre de vista y nombre de acción son los mismos, nosotros no necesitamos pasar el
nombre de la vista dentro de “return view()”.
Paso 02: Eso es todo, así que vamos a probar

Y esto es todo lo que necesitamos hacer. Ahora vamos a ir y probar si el modo de visualización
MVC hace honor a su promesa.
Ahora si vas e ingresar el controlador y la acción en el navegador verás como la imagen izquierda
de abajo. Si ingresas el mismo controlador y acción usando el emulador de móviles android tu
verás la pantalla de la imagen derecha.
Nota: Para probar simulación para móviles en este laboratorio hemos usado el simulador
“Opera Mobile”. Tú puedes descargar el emulador de
http://www.opera.com/es/developer/mobile-emulator
Paso 03: Más personalización y control

Pero que si queremos más personalización y control.
Si el escritorio muestra “Index.cshtml”
Si el móvil muestra “Index.mobile.cshtml”
Si el móvil Android muestra “Index.Android.cshtml”
Tenemos ya implementado las primeras dos condiciones. Ahora para la tercera condición
necesitamos realizar algunos pasos extras. Relájate son absolutamente pequeños y fáciles pero
con gran resultado final.
Primer paso es agregar una página más “Index.Android.cshtml” especialmente para Android en
la carpeta Vista como se muestra en la siguiente imagen.
El siguiente pasó el hacer más cambios en el archivo “Global.asax.cs”.
a. El primer paso es agregar el espacio de nombre “System.Web.WebPages” como se muestra
en la siguiente figura.
b. Segundo paso es usar la clase “DisplayModeProvider” y agregar una entrada “Android”

dentro de la colección “Modes” como se muestra en el código de abajo. El siguiente código
busca para la cadena “Android” y si encuentra esto captura y redirecciona a la página
“Index.Android.cshtml”.
Paso 04: Probar la personalización de Móviles

Ahora si ejecutas el simulador de Opera Mobile con Android como un usuario agente como se
muestra en la siguiente imagen, veras la página Android (Index.Android.cshtml) redireccionado.
Lab 23: Proveedor MVC OAuth
Una de los más procesos aburridos para un usuario final es registrase en un sitio. Algunas veces
esos largos formularios y correos de validación sólo posterga el usuario. Entonces cómo hacer
las cosas fáciles mediante la validación de los usuarios utilizando sus cuentas existentes de
Facebook/Twitter/Google/LinkedIn/etc. Entonces el usuario usa algo que ya tiene mientras el
sitio asegura que este usuario es un usuario propietario.
Esto es logrado usando MVC OAuth(Open Standard for Authorization).
Para implementar OAuth esto es en un proceso de tres pasos.

 Registrar la aplicación y obtener el ID y Clave.
 Realizar la autenticación con el sitio de terceros.
 Una vez autenticado hace navegar el sitio.
Paso 1: Registrar la aplicación y obtener el ID y la Clave

Entonces el primer paso es registrar la aplicación con el sitio de terceros. Para este laboratorio
usaremos Google para la autenticación abierta. Por favor nota este paso varía para Twitter,
Facebook y otros sitios. Ir a https://console.developers.google.com/ , crear un proyecto
Seleccionar el proyecto y en la columna lateral izquierda la opción Credentials
En el siguiente apartado especificamos el tipo de aplicación, en nuestro caso una aplicación web
e indicamos que la URL es http://localhost.
Pulsamos el botón “Create Cliend ID” y nos llevará al panel de control donde podremos ver el
API Key generado que tendremos que configurar más adelante en nuestra aplicación.
Paso 2: Crear un sitio MVC para autenticación con OAuth
Ahora que tenemos el ID sigamos adelante y crear una Aplicación de Internet. Estamos creando
una aplicación de internet para que podamos obtener algo ya hecho o se puede decir código
plantilla para OAuth.
Una vez que el proyecto es creado abrir la clase “OAuthConfig.cs” del folder “App_start”.
En este archivo de configuración encontrarás el método “RegisterAuth”, lo habilitamos para

GoogleCliente.
Paso 3: Iniciar el navegador
Esto es todo lo que hay que hacer, ahora ejecutar la aplicación y dar click en “Iniciar Sesion”
La siguiente pantalla presenta dos opciones, en el lado izquierdo donde puedes loguearte de
forma local usando la autenticación “Forms” y en la derecha dispones de proveedor de terceros.
Clickear en el botón Google e ingresar las credenciales de la cuenta.
Lab 24: Enlazador de Modelo MVC
Introducción
El siguiente código es un simple formulario HTML hace un post a “SubmitCustomer”
La acción “SubmitCustomer” está dentro de un objeto Customer. Este objeto “Customer” es

producido automáticamente con los datos que son llenados en los cuadros de texto, sin ningún
tipo de unión o asignaciones.
¿Conoces porque el objeto Customer llena automáticamente? Esto es porque el nombre de los
cuadros de textos y la propiedad nombre de la clase “Customer” son iguales.
Pero que si los nombres de los cuadros de texto no son iguales a los nombres de las propiedades
de la clase “Customer”.
En otras palabras el nombre del textbox HTML es “txtCustomerCode” y el nombre de
la propiedad de la clase es “CustomerCode”. Aquí es donde los enlazadores de modelo entran
como se puede ver en la siguiente imagen.
Model binder mapea los elementos HTML del formulario al modelo. Este actúa como un puente
entre la interfaz de usuario HTML y el modelo MVC. Así que vamos hacer algunos manejos para
ejercicio con “ModelBinder”.
Paso 1: Crear “EnterCustomer.cshtml” y el controlador

El primer paso es crear una vista “EnterCustomer.cshtml” dentro de nuestro proyecto ya creado
“MVCSextoDia”, el cual tomará datos de “Customer”
Para invocar este formulario necesitamos una acción en el controlador “Customer” porque no
podemos invocar directamente a una vista en MVC, necesitamos hacerlo vía un controlador.
Paso 2: Crear el modelo Customer
El siguiente paso es crear un modelo “Customer”. Por favor nota la propiedad nombre de la
clase “Customer” y el nombre de los cuadros de texto de la UI HTML son diferentes.
Paso 3: Crear el enlace que hace el mapeo

Ahora debido que los nombres de los elementos de la UI y la clase “Customer” tienen diferentes
nombres necesitamos crear el enlazador “Model”. Para crear la clase enlazador de modelo
necesitamos implementar la interfaz “IModelBinder”. Pa lo cual agregamos una clase
“CustomerBinder” dentro de la carpeta Controller. En el siguiente código puedes ver cómo
hemos escrito el código de mapeo dentro del método “BindModel”.
Paso 4: Conectar el mapeador con la acción
Ahora que tenemos en conector, tenemos la UI HTML entonces es tiempo de conectarlos.
Miramos en la acción “SubmitCustomer” del siguiente código.
El atributo “ModelBinder” conecta con el objeto “Customer”.
Paso 5: Disfruta la salida
Ahora al ingresar la acción “EnterCustomer” el cual invoca formulario de entrada de Customer.
Cuando llenas los datos y haces click en el botón Enviar, veras que se llena el objeto “Customer”
con un punto de interrupción, con en la siguiente imagen.
Lab 25: Diseño Razor

Introducción
Layouts son como paginas maestras en ASP.NET web form. Páginas Maestras dan como un
aspecto estándar para las vistas Web Form (ASPX) mientras que layout dan una vista estándar
para las vistas Razor (CSHTML). En caso seas nuevo en Razor ver el Lab 12: Vistas Razor MVC.
En este laboratorio veras como implementar Diseño Razor.
Paso 1: Crear una página de diseño

Lo primero que nosotros necesitamos crear es una página de diseño. Dentro de nuestro
proyecto web MVCSextoDia, vamos a la carpeta vista y hacemos click derecho, agregar nuevo
elemento y seleccionar la plantilla “Página de Diseño de MVC 4” como se muestra en la siguiente
imagen.
En la página de diseño MC necesitamos definir la estructura común el cual será aplicado a todas
las páginas razor. Puedes ver en la siguiente diseño de página tenemos tres secciones Cabecera,
cuerpo y pie. La cabecera y el pie son secciones personalizados mientras “RenderBody” es algo
que viene de MVC y muestra en el contenedor body.
Paso 2: Crear vista y aplicar el diseño

Ahora una vez que hemos creado el diseño los siguiente es aplicar esto a las vista.
Para aplicar el diseño de página, seleccione el botón “...” como se muestra en la anterior
imagen, y seleccione el diseño de página como se muestra en la siguiente imagen.
Una vez que la vista es creada la primera línea de código indica que diseño de página está
usando. Esto se ve como el siguiente código.
Ahora lo final es en la vista llenar todas las secciones. Las secciones Pie y cabecera son secciones
personalizadas así que necesitamos usar el comando @section seguido por el nombre de la
sección y despues lo que queramos asignar en esas secciones. Todos los otros textos son parte
del body(@RenderBody).
Paso 3: Crear un controlador y ver el diseño en acción

Ahora que tenemos todo asignado es tiempo de crear un controlador y método para invocar la
vista.
Deberías ver una cosa como se ve en la siguiente imagen. Puedes ver como la plantilla de diseño
es aplicado a la vista.
Lab 26: Métodos Personalizados HTML Helper

Introducción
En el día 1 hablamos acerca de clases MVC Helper. Esto nos ayuda a trabajar con controles de
ingresos de una manera más eficiente. Cuando tipeas “@Html” en una vista MVC Razor se
consigue algo como esto en IntelliSense.
El método Html Helper nos crea controles de entrada Html como Textbox, Radio button,
Checkbox, Text Area de una manera fácil y rápido. En este laboratorio vamos a dar un paso
adelante y crear métodos Helper personalizados.
Para crear método Html Helper Personalizados, necesitamos usar extensión de métodos.
Extensión de métodos es un concepto que fue introducido en .NET 3.5.
Paso 1: Agregar una simple clase

Vamos a trabajar con nuestro proyecto proyecto MVCSextoDia. Agregar un controlador llamado
EjemploHelper y un método llamado Index. Crear una nueva carpeta dentro del proyecto MVC
llamado ExtensionClases.
Paso 2: Marcar la clase como estática y agregar métodos.

Para el método de extensión necesitamos agregar una clase como estática.
En este clase vamos a crear un nuevo método estático llamado “HolaMundoLabel” el cual
retornará un valor de tipo MvcHtmlString y aceptando un parámetro HtmlHelper.
Nota: Asegurar agregar la palabra “this” antes de declarar el primer parámetro porque el
objetivo es crear un método extensión para la clase HtmlHelper.
Paso 3: Usa la clase Helper
El paso final es importar el espacio de nombres “System.Web.Mvc.Html”. Necesitamos importar
este espacio de nombre, porque por defecto TextBoxFor, TextAreaFor y otros métodos de
extensión de HTML Helper estén disponibles dentro de este espacio de nombres. Se requiere
solo si vamos a usar uno de estos métodos de extension.
Simplemente escribimos el siguiente código en la vista y construir el proyecto.
Nota: Note que en la parte superior se asignó la sentencia using que referencia a la clase
extensión creada previamente.
Construya la aplicación, presionando F5 y probar la aplicación.
¿Que hay para el último dia?

El último día será principalmente en cómo integrar los Framework JavaScript de Angular y KO
con MVC.

Aprender ASP NET MVC Paso A Paso en 7 Días

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Aprender ASP NET MVC Paso A Paso en 7 Días

Uploaded by

Copyright:

Available Formats

Aprender ASP NET MVC Paso a Paso en 7 días

 Dia 1: Controladores, vistas fuertemente tipadas y clases helper

 ¿Por qué el code-behind en tan bueno en ASP.NET?

¿Porque el code-behind en tan bueno en ASP.NET?

Problema número 1: Testeo Unitario

Problema número 2: La realidad de la separación del código y la UI

Nuestro Héroe MVC (Modelo, Vista y Controlador)

Paso 01: Crear el Proyecto

Paso 02: Agregar un controlador

Lab 02: Pasando datos entre el controlador y la vista

MVC, es decir el ViewData.

Paso 03: Ejecutamos la aplicación

Paso 01: Creamos un simple archivo de clase

Paso 02: Definimos un controlador con acción

Nota: Previamente es necesario que se compile el proyecto

Lab 04: Creando un simple formulario de entrada de datos MVC

Paso 03: Creando la vista para mostrar el objeto customer

Paso 04: Finalmente ejecutar el proyecto

Y al hacer clic ek en botón enviar muestra la vista DisplayCustomer.

Lab 05: Usando Razor para crear vistas rápidamente

Paso 01: Creando la clase Customer

Paso 02: Creando la entrada de formulario HTML usando clases Razor

El código de arriba genera el siguiente codigo HTML:

Vamos a crear el formulario de entradas de datos:

Paso 03: Creando una vista Fuertemente tipada

Con esto ya podemos crear nuestro formulario en la vista FillCustomer.

Paso 04: Creando el controlador

¿Y que hay para el segundo Día?

 Dia 1: Controladores, vistas fuertemente tipadas y clases helper

 Escribiendo Testeos Unitarios en Proyectos MVC.

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

 ¿Cómo hacemos para crear los objetos sender y eventargs?

Paso 1: Crear un simple proyecto las mostrar Customer.

Paso 2: Agregando un simple proyecto de testeo unitario.

Paso 3: Agregar referencias apropiadas al proyecto

Paso 4: Escribir la prueba unitario

Paso 5: Finalmente ejecutamos la prueba unitaria

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

Lab 7: Entendiendo el ruteo MVC

Por ejemplo cuando un usuario envía un requerimiento de URL como

Paso 1: Tomar el proyecto MVC creado en el día 1

Paso 2: Cambiar Global.asax.cs

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

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

Ingresamos el siguiente código, el cual significa cuando llamamos a http:/localhost/view/ViewCustomer esto

Paso 3: Ejecuta la aplicación

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

Paso 1: Creando un simple modelo Customer.

Paso 2: Creando la clase controlador

 Id debería siempre ser numérico

Paso 4: Probando si esto trabaja

Lab 9: Entendiendo URLs salientes en MVC

Paso 1: Creando el controlador para las vistas

Paso 3: proveyendo acciones en los link.

Para la Vista Home:

Para la vista About:

¿Qué hay para el tercer día?

 Dia 1: Controladores, vistas fuertemente tipadas y clases helper

En este día 3 veremos los siguientes cinco laboratorios:

La vistas reusables podrían se logrados creando “Vistas Parciales”.

Paso 2: Crear una simple vista parcial

Paso 4: Llamar a la vista parcial en la principal.

Paso 5: Ejecutar el programa ara ver la acción