02 Programador JR de Aplicaciones ASP - Net MVC

Microsoft .NET Programador Jr. de aplicaciones ASP.
NET MVC
ASP.NET MVC Manual de estudiante
Programador Jr. de
aplicaciones ASP.NET
MVC
Manual de estudiante
Primera edición
Febrero de 2018
Soporte técnico:
soporte@mail.ticapacitacion.com
https://ticapacitacion.com/curso/mvcjr
Este manual fue creado por TI Capacitación para uso personal de:
Carlos Valenzuela
genius192002@hotmail.com
1 https://ticapacitacion.com/curso/mvcjr
Microsoft .NET Programador Jr. de aplicaciones ASP.NET MVC
Contenido
Acerca del curso ........................................................................................................................... 7
Audiencia ..........................................................................................................................................7
Objetivos ..........................................................................................................................................7
Requerimientos ................................................................................................................................8
Contenido del curso .........................................................................................................................8
Módulo 1: Explorando ASP.NET MVC .......................................................................................... 12
Acerca del módulo ........................................................................................................................ 13
Objetivos ....................................................................................................................................... 13
Lección 1 Visión general de las tecnologías Web Microsoft ............................................................ 14
Objetivos de la lección .................................................................................................................. 14
Introducción a las tecnologías Web de Microsoft......................................................................... 15
Visión general de ASP.NET ............................................................................................................ 19
Tecnologías Web del lado del Cliente ........................................................................................... 23
Internet Information Server .......................................................................................................... 26
Microsoft Azure ............................................................................................................................. 29
Lección 2 Visión general de ASP.NET ............................................................................................... 31
Aplicaciones Web Pages ................................................................................................................ 32
Aplicaciones Web Forms ............................................................................................................... 34
Aplicaciones MVC .......................................................................................................................... 36
Características compartidas .......................................................................................................... 39
Lección 3 Introducción a ASP.NET MVC ........................................................................................... 42
Modelos, Vistas y Controladores .................................................................................................. 43
Explorando una aplicación MVC Demostración .......................................................................... 45
Características importantes de ASP.NET MVC .............................................................................. 46
Módulo 2: Diseñando aplicaciones Web ASP.NET MVC ................................................................ 48
Objetivos ....................................................................................................................................... 49
Carlos Valenzuela (genius192002@hotmail.com)
Lección 1 Planeación en la fase de diseño del proyecto .................................................................. 50

Metodologías de desarrollo de Proyectos .................................................................................... 51
Recopilación de Requerimientos .................................................................................................. 55
Planificando el Diseño de la Base de Datos................................................................................... 58
Planificación de Aplicaciones Distribuidas .................................................................................... 61
Planificando la Administración de Estado ..................................................................................... 64
Planificando la Globalización y Localización ................................................................................. 68
Lección 2 Diseñando Modelos, Controladores y Vistas ................................................................... 70
Diseñando Modelos ...................................................................................................................... 71
Diseñando Controladores.............................................................................................................. 75
Diseñando Vistas ........................................................................................................................... 77
Módulo 3: Desarrollando Modelos ASP.NET MVC ........................................................................ 79
Objetivos ....................................................................................................................................... 80
Lección 1 Creando Modelos MVC .................................................................................................... 81
Desarrollo de Modelos .................................................................................................................. 82
Uso de Anotaciones de Datos de Visualización y Edición sobre las propiedades ......................... 85
Validando la entrada de usuario con Anotaciones de Datos ........................................................ 86
¿Qué son los Enlazadores de Modelo (Model Binders)? .............................................................. 88
Extensibilidad de Modelo .............................................................................................................. 91
Creando una Anotación de Datos de Validación personalizada ................................................... 92
Creando Enlazadores de Modelo personalizados ......................................................................... 94
Lección 2 Trabajando con datos ....................................................................................................... 96
Conectando a una base de datos .................................................................................................. 97
Conectando una aplicación Web MVC a una base de datos ......................................................... 99
Entity Framework ........................................................................................................................ 100
Agregando un Contexto de Entity Framework............................................................................ 101
LINQ to Entities ........................................................................................................................... 103

Utilizando LINQ to Entities .......................................................................................................... 104
Acceso a datos en Modelos y Repositorios ................................................................................. 105
¿Cómo separar las clases Modelo y Repositorio? ....................................................................... 106
Módulo 4: Desarrollando Controladores ASP.NET MVC .............................................................. 108
Acerca del módulo ...................................................................................................................... 109
Objetivos ..................................................................................................................................... 109
Lección 1 Planeación en la fase de diseño del proyecto ................................................................ 110
Objetivos de la lección ................................................................................................................ 110
Respondiendo a las peticiones del Usuario ................................................................................ 111
Escribiendo Acciones del Controlador ........................................................................................ 113
Acciones que responden a peticiones HTTP POST ...................................................................... 115
Tipos derivados de ActionResult ................................................................................................. 117
Acciones hijas (Child Actions) ...................................................................................................... 119
Utilizando Parámetros................................................................................................................. 120
Pasando información a las Vistas ................................................................................................ 121
¿Qué son las Fábricas de Controladores? ................................................................................... 123
Creando una Fábrica personalizada de Controladores ............................................................... 125
Lección 2 Creando Filtros de Acción............................................................................................... 127
¿Qué son los Filtros? ................................................................................................................... 128
Creando y Utilizando Filtros de Acción ....................................................................................... 130
Módulo 5: Desarrollando Vistas ASP.NET MVC .......................................................................... 132
Objetivos ..................................................................................................................................... 133
Lección 1 Creando Vistas con sintaxis Razor .................................................................................. 134
Objetivos de la lección .................................................................................................................... 134
Agregando Vistas......................................................................................................................... 135
Diferenciando el código del servidor y el código HTML .............................................................. 137
Características de la Sintaxis Razor ............................................................................................. 139
Enlazando Vistas a Modelos ........................................................................................................ 141
Generando código HTML accesible ............................................................................................. 143

Motores de Vistas alternativos ................................................................................................... 145
Creación de Motores de Vista Personalizados ............................................................................ 147
Lección 2 Utilizando HTML Helpers ................................................................................................ 148
Utilizando Helpers Action ............................................................................................................ 149
Utilizando Helpers Display .......................................................................................................... 151
El Helper BeginForm .................................................................................................................... 152
Utilizando Formularios para subir archivos................................................................................. 153
Utilizando Helpers de edición ..................................................................................................... 154
Utilizando Helpers de Validación ................................................................................................ 156
Codificación HTML....................................................................................................................... 158
Creación de Helpers HTML personalizados ................................................................................. 159
Lección 3 Reutilizando código en Vistas......................................................................................... 161
Creando Vistas Parciales ............................................................................................................. 162
Utilizando Vistas Parciales........................................................................................................... 164
Módulo 6: Probando, Depurando y Solucionando problemas en aplicaciones Web ASP.NET MVC
................................................................................................................................................ 165
Objetivos ..................................................................................................................................... 166
Lección 1 Realizando pruebas unitarias de los componentes MVC ............................................... 167
¿Por qué realizar Pruebas Unitarias? .......................................................................................... 168
Principios del Desarrollo Guiado por Pruebas ............................................................................ 171
Creando Componentes MVC débilmente acoplados (Loosely-Coupled) .................................... 173
Laboratorio: Creando Pruebas Unitarias para componentes MVC ................................................ 175
Objetivos ..................................................................................................................................... 175
Requisitos .................................................................................................................................... 175
Ejercicio 1: Creando Pruebas Unitarias ...................................................................................... 177
Tarea 1: Crear un proyecto de pruebas .................................................................................. 177
Tarea 2: Configurar el proyecto de pruebas ........................................................................... 179

Tarea 3: Preparar la aplicación Web ....................................................................................... 181
Tarea 4: Escribir las pruebas.................................................................................................... 182
Tarea 5: Implementar la funcionalidad para aprobar las pruebas .......................................... 192
Tarea 6: Probar clases Modelo y de Lógica de Negocio .......................................................... 196
Ejercicio 2: Creando Interfaces Repositorio ............................................................................... 201
Tarea 1: Crear un Repositorio ................................................................................................. 201
Tarea 2: Implementar el Repositorio para utilizarlo en producción y desarrollo ................... 203
Tarea 3: Refactorizar el Controlador para utilizar el Repositorio ........................................... 209
Tarea 4: Implementar el Repositorio Doble de Prueba .......................................................... 220
Tarea 5: Refactorizar las Pruebas Unitarias para utilizar el Repositorio de simulación .......... 226
Tarea 6: Agregar pruebas adicionales ..................................................................................... 233
Resumen ...................................................................................................................................... 240
Lección 2 Implementando una estrategia para el manejo de Excepciones ................................... 241
Disparando y atrapando excepciones ......................................................................................... 242
Configurando el manejo de Excepciones .................................................................................... 246
Utilizando Visual Studio IntelliTrace en MVC .............................................................................. 248
Registro de Excepciones .............................................................................................................. 251
Monitoreo de salud en ASP.NET (ASP.NET Health Monitoring).................................................. 253
Laboratorio: Implementando una estrategia para el manejo de Excepciones .............................. 256
Objetivos ..................................................................................................................................... 256
Requisitos .................................................................................................................................... 256
Ejercicio 1: Disparando y atrapando Excepciones ...................................................................... 257
Tarea 1: Disparar una excepción personalizada...................................................................... 257
Tarea 2: Atrapar excepciones con bloques Try/Catch ............................................................ 261
Tarea 3: Atrapar excepciones de Controladores con el método OnException ....................... 266
Tarea 4: Atrapar excepciones de Controladores con la anotación HandleError..................... 270
Tarea 5: Atrapar excepciones adicionales ............................................................................... 278
Resumen ...................................................................................................................................... 281
Acerca del curso

Este entrenamiento, describe las distintas tecnologías disponibles para desarrollar aplicaciones Web
ASP.NET, enfocándose principalmente en el desarrollo de aplicaciones Web utilizando el patrón
Model-View-Controller (MVC). Se compara ASP.NET MVC con ASP.NET Web Forms para que los
participantes puedan decidir en qué escenarios deben o pueden ser utilizadas esas tecnologías.
El entrenamiento describe la estructura de una aplicación Web ASP.NET MVC para poder diseñar y
crear Modelos, Controladores y Vistas de aplicaciones Web que accedan a bases de datos utilizando
Entity Framework.
El entrenamiento incluye una introducción al desarrollo de Pruebas Unitarias para los componentes
MVC y describe la forma de implementar una estrategia para el manejo de excepciones en
aplicaciones Web ASP.NET MVC.
Audiencia
Este curso está diseñado para personas con un perfil de desarrolladores web y que utilizan ambientes
de desarrollo individual o en equipo. Los candidatos a este curso son personas Interesadas en
desarrollar aplicaciones web básicas y que desean administrar comprensivamente la presentación
visual de HTML separando la interfaz de usuario, el acceso a datos y la lógica de la aplicación.
Para un buen aprovechamiento de este entrenamiento, es recomendable que los participantes
cuenten con un mínimo de 3 meses de experiencia en el uso del .NET Framework, el lenguaje de
programación C# y Visual Studio.
Objetivos
Al finalizar este entrenamiento, los participantes contarán con las habilidades y conocimientos para:
• Describir las distintas tecnologías Web de Microsoft y seleccionar la apropiada para utilizarla
en el desarrollo de una aplicación determinada.
• Diseñar la arquitectura y la implementación de una aplicación Web que cumpla con un
conjunto de requerimientos funcionales, requerimientos de interfaz de usuario y que se
adapte a modelos de negocios.
• Crear Modelos MVC y escribir código que implemente la lógica de negocios con los métodos,
propiedades y eventos del Modelo.
• Agregar Controladores a una aplicación MVC para manejar la interacción de usuario,
actualizar los Modelos y seleccionar y devolver las Vistas apropiadas.
• Crear Vistas en una aplicación MVC que muestren y editen datos además de interactuar con
Modelos y Controladores.
• Ejecutar pruebas unitarias y herramientas de depuración en una aplicación web con Visual
Studio para encontrar y solucionar problemas.
Requerimientos
Para poder practicar los conceptos y realizar los ejercicios del curso, se recomienda contar con lo
siguiente:
• Sistema Operativo Windows 8 o posteriores. Puede descargarse la versión de evaluación en

https://technet.microsoft.com/es-mx/evalcenter/hh699156.aspx
• Microsoft WebMatrix 3. Puede descargarse gratuitamente en
http://www.microsoft.com/web/webmatrix/
• Visual Studio 2013 o posteriores. Puede utilizarse la versión gratuita Visual Studio
Community que puede descargarse en http://www.visualstudio.com/en-us/products/visual-
studio-community-vs.aspx
• SQL Server 2012 o posteriores. Puede descargarse la versión gratuita en
http://www.microsoft.com/en-us/download/details.aspx?id=42299
Contenido del curso

El contenido de este entrenamiento consta de 6 módulos.
Módulo 1. Explorando ASP.NET MVC
En este módulo se presenta un resumen del conjunto de tecnologías Web de Microsoft para poder
seleccionar la tecnología apropiada para utilizarla en el desarrollo de una aplicación determinada. Se
describen los tres modelos de programación disponibles en ASP.NET tales como Páginas Web, Web
Forms y MVC. En este módulo, también se presenta una introducción a ASP.NET MVC incluyendo
nuevas características y configuración.
Al finalizar este módulo, los participantes podrán:
• Describir el papel de ASP.NET en el Stack de tecnologías Web y como utilizar ASP.NET para
construir aplicaciones Web.
• Describir los tres modelos de programación disponibles en ASP.NET: Web Pages, Web Forms
y MVC para seleccionar el modelo apropiado para un proyecto específico.
• Distinguir entre un Modelo MVC, Controlador MVC y una Vista MVC.
Los temas que forman parte de este módulo son:
• Lección 1: Visión general de las tecnologías Web de Microsoft.

• Lección 2: Visión general de ASP.NET.
• Lección 3: Introducción a ASP.NET MVC.
Módulo 2: Diseñando aplicaciones Web ASP.NET MVC
En este módulo, se describe el proceso de diseño típico que los arquitectos deben completar cuando
planean el desarrollo de una aplicación y MVC ha sido seleccionado como el modelo de
programación más apropiado. Se describe el detalle de una aplicación Web MVC tal como su
arquitectura, Controladores, Vistas, Modelos y Rutas.
• Planear la arquitectura de una aplicación Web MVC y considerar aspectos tales como el
manejo de estado.
• Planear los Modelos, Controladores y Vistas que son requeridos para implementar un
conjunto de requerimientos funcionales proporcionado.
• Lección 1: Planeación en la fase de diseño del proyecto.

• Lección 2: Diseñando Modelos, Controladores y Vistas.
Módulo 3. Desarrollando Modelos ASP.NET MVC
En este módulo se muestra la forma de crear Modelos en una aplicación Web MVC que implemente
la lógica de negocio necesaria para satisfacer los requerimientos de funcionalidad de la aplicación.
Este módulo también describe la forma de implementar una conexión a una base de datos o a un
almacenamiento alterno de datos utilizando Entity Framework y LINQ.
• Agregar un Modelo a una aplicación MVC y escribir el código en el Modelo para implementar
la lógica de negocios.
• Crear una nueva base de datos SQL Database en Windows Azure para almacenar los datos de
la aplicación Web.
• Lección 1: Creando modelos MVC.

• Lección 2: Trabajando con datos.
Módulo 4. Desarrollando Controladores ASP.NET MVC
En este módulo se muestra la forma de crear Controladores en una aplicación Web MVC y la forma
de implementar Acciones que respondan a la entrada de los usuarios y de otros eventos. Se muestra
la relación entre el Controlador y el Modelo, así como la forma de implementar Acciones del
Controlador que definan las Vistas utilizadas para mostrar o editar datos. En este módulo también se
describe la forma de escribir Filtros de Acción (Action Filters) para ejecutar código antes o después de
las Acciones en el Controlador. Se definen las situaciones en que los Filtros de Acción son útiles.
• Agregar un Controlador a una aplicación Web que responda a las acciones del usuario
especificadas en el diseño del proyecto.
• Escribir código en Filtros de Acción que se ejecute antes o después de una Acción del
Controlador.
• Lección 1: Creando Controladores y Acciones.

• Lección 2: Creando Filtros de Acción.
Módulo 5. Desarrollando Vistas ASP.NET MVC
En este módulo se describe el papel de las Vistas en las aplicaciones Web ASP.NET MVC, así como su
interacción con los Modelos y Controladores para poder mostrar datos y permitir su edición. Se
describe la sintaxis de una Vista Razor que define la estructura y funcionalidad de la presentación de
datos. Se describe la funcionalidad de los principales HTML Helpers, la reutilización de código
mediante la definición de Vistas parciales y los Razor Helpers.
• Crear una Vista MVC y agregar código Razor para mostrar datos a los usuarios.
• Utilizar HTML Helpers en una Vista para generar el código de los controles, enlaces y otros
elementos HTML.
• Reutilizar Código Razor en múltiples ubicaciones de una aplicación.
• Lección 1: Creando Vistas con sintaxis Razor.

• Lección 2: Utilizando HTML Helpers.
• Lección 3: Reutilizando código en Vistas.
Módulo 6. Probando, Depurando y Solucionando problemas en aplicaciones Web ASP.NET MVC
En este módulo se describe la forma de realizar Pruebas Unitarias de cada uno de los componentes
de una aplicación MVC y la forma de implementar una estrategia de manejo de Excepciones para la
aplicación.
Se describe también la forma de mejorar la calidad de una aplicación localizando y corrigiendo

errores de código y otros resultados inesperados a través de las herramientas de depuración
disponibles en Visual Studio.
• Ejecutar pruebas unitarias sobre los componentes MVC tales como las clases del Modelo.
• Localizar errores potenciales en los componentes MVC.
• Construir una aplicación MVC que maneje Excepciones de una forma robusta y eficiente.
• Lección 1: Realizando pruebas unitarias de los componentes MVC.

• Lección 2: Implementando una estrategia para el manejo de Excepciones.
Programador Jr. de
MVC
Modulo 1: Explorando ASP.NET MVC
Acerca del módulo

Microsoft ASP.NET MVC y las otras tecnologías Web del .NET Framework ayudan a crear y alojar
aplicaciones web dinámicas, potentes y extensibles.
ASP.NET MVC soporta desarrollo ágil, basado en pruebas y los últimos estándares Web tal como
HTML5.
Para crear aplicaciones Web robustas, es necesario estar familiarizados con las tecnologías y los
productos de la pila Web de Microsoft.
Necesitamos también saber cómo funcionan las Aplicaciones ASP.NET con IIS, Visual Studio, SQL
Server, Microsoft Azure y Microsoft Azure SQL DataBase para ofrecer páginas Web atractivas a los
visitantes del sitio.
Para elegir un lenguaje de programación que mejor se ajuste a un conjunto de requisitos de negocio,
necesitamos saber cómo las aplicaciones del Modelo-Vista-Controlador (MVC) difieren de los otros
modelos de programación ASP.NET: Páginas Web y Formularios Web.
Objetivos
Al finalizar este módulo, los participantes contarán con las habilidades y conocimientos para:
• Describir el papel de ASP.NET en la pila de tecnologías web de Microsoft y cómo utilizar

ASP.NET para construir aplicaciones Web.
• Describir los tres modelos de programación disponibles en ASP.NET: Páginas Web,
Formularios Web y MVC.
• Seleccionar un modelo apropiado para un proyecto determinado.
• Distinguir entre un Modelo MVC, un Controlador MVC y una Vista MVC.
Los temas que se cubren en este módulo son:
• Lección 1: Visión general de las tecnologías Web Microsoft

• Lección 2: Visión general de ASP.NET
• Lección 3: Introducción a ASP.NET MVC
Lección 1
Visión general de las tecnologías Web Microsoft
Antes de empezar a trabajar con ASP.NET MVC, es necesario conocer donde se ubica Microsoft
ASP.NET en el contexto de la pila de tecnologías Web de Microsoft. Debemos conocer cómo se alojan
los sitios Web ASP.NET en Internet Information Server (IIS) o Microsoft Azure. Debemos conocer la
forma en que las aplicaciones Web ejecutan código del lado del servidor en los servidores Web y el
código del lado del cliente en los navegadores Web para ayudar a proporcionar contenido atractivo y
rico en interfaz de usuario.
Objetivos de la lección
Al finalizar esta lección, seremos capaces de:
• Proporcionar una visión general de las tecnologías Web de Microsoft.

• Proporcionar una visión general de ASP.NET.
• Proporcionar una visión general de las tecnologías Web del lado del cliente, tales como, AJAX
y bibliotecas JavaScript.
• Describir el papel de IIS en la pila de tecnologías Web de Microsoft.
• Describir el papel de Microsoft Azure en la pila de tecnologías Web de Microsoft.
Introducción a las tecnologías Web de Microsoft

Microsoft ofrece una amplia gama de tecnologías que se pueden utilizar para crear aplicaciones Web
enriquecidas y publicarlas en Intranets y en Internet.
Además de la publicación de las aplicaciones Web, podemos utilizar estas tecnologías para
desarrollar y alojar páginas Web que ejecuten código tanto en el servidor Web como en el navegador
Web del usuario.
Las tecnologías que forman parte de la pila Web de Microsoft pueden agruparse en 3 categorías:
herramientas de desarrollo, tecnologías de hospedaje y tecnologías de ejecución de código.
Herramientas de desarrollo
Podemos crear sitios web simples con texto e imágenes usando un editor de texto como el Bloc de
notas, sin embargo, la mayoría de los sitios Web requieren que sean realizadas acciones complejas
del lado del servidor, tales como operaciones de base de datos, envío de correo electrónico, cálculos
complejos o procesamiento de gráficos. Para crear ese tipo de sitios web complejos, altamente
funcionales y atractivos de forma rápida y sencilla, Microsoft ofrece herramientas de desarrollo:
• WebMatrix. Podemos utilizar WebMatrix para crear páginas HTML estáticas y páginas
dinámicas con ASP.NET, PHP y Node.js. WebMatrix es una herramienta de desarrollo gratuito
que puede instalarse a través del Microsoft Web Platform Installer el cual puede
descargarse desde el sitio Web de Microsoft. WebMatrix permite desarrollar sitios web
personalizados basados en aplicaciones Web populares como Orchard, Umbraco CMS y
WordPress. Orchard está desarrollado con ASP.NET mientras que WordPress está escrito con
PHP. Con WebMatrix, podemos crear aplicaciones ASP.NET Web Pages pero no podemos
crear aplicaciones ASP.NET Web Forms o aplicaciones ASP.NET MVC.
• Microsoft Visual Studio. Podemos utilizar Visual Studio, un ambiente de desarrollo

integrado o IDE para crear aplicaciones personalizadas basadas en las tecnologías de
Microsoft, independientemente de si estas aplicaciones se ejecutan en la web, en equipos de
escritorio, en dispositivos móviles o mediante el uso de Servicios de nube de Microsoft.
Visual Studio ofrece muchas facilidades para diseñar, codificar y depurar cualquier aplicación
web ASP.NET, incluyendo aplicaciones ASP.NET MVC.
• Microsoft Visual Studio Express for Web. Podemos utilizar Visual Studio Express para Web
para crear aplicaciones Web Forms o aplicaciones Web MVC. Esta es una herramienta
gratuita que no incluye todas las características de las ediciones de Visual Studio, sin
embargo, se puede utilizar para crear sitios web MVC completamente funcionales.
• Microsoft Visual Studio Community. Visual Studio Community es una herramienta gratuita
que incluye toda la funcionalidad de Visual Studio Professional, diseñada y optimizada para
desarrolladores individuales, estudiantes, contribuidores de Open Source y equipos
pequeños de trabajo. Se puede utilizar Visual Studio Community para crear aplicaciones
gratuitas o pagadas. Visual Studio Community remplaza a la versión Express de Visual Studio.
Tecnologías de hospedaje
Independientemente de la herramienta que utilicemos para construir una aplicación Web, debemos
utilizar un servidor web para alojar la aplicación.
Cuando los usuarios visitan nuestro sitio web, el servidor responde generando código HTML y lo
entrega al navegador del usuario para su visualización.
El servidor de hospedaje puede consultar una base de datos antes de que genere el código HTML y
puede realizar otras acciones, como el envío de mensajes de correo electrónico o guardar los
archivos subidos por el usuario.
Es necesario probar la funcionalidad de las acciones de los usuarios en un servidor Web.
Al crear una aplicación Web utilizando Visual Studio, es posible utilizar el servidor Web IIS Express
incorporado a Visual Studio para ejecutar la aplicación, sin embargo, IIS Express no está diseñado
para hospedar aplicaciones Web en producción, por lo tanto, cuando se termina la construcción de la
aplicación Web y está lista para que los usuarios accedan a ella en una Intranet o en Internet, se debe
utilizar un servidor Web completamente funcional.
De las tecnologías de hospedaje del Stack Web de Microsoft tenemos:
• Microsoft Internet Information Server (IIS). IIS es una tecnología avanzada de alojamiento
web. Podemos instalar servidores IIS en nuestra red local o en la red perimetral o utilizar
servidores IIS alojados por un Proveedor de Servicios de Internet (ISP). IIS puede alojar
cualquier sitio web ASP.NET, PHP, o Node.js. Podemos escalar IIS para alojar sitios web
grandes y concurridos mediante la configuración de granjas de servidores que contengan
múltiples servidores IIS, todos dando servicio al mismo contenido.
• Microsoft Azure. Microsoft Azure es una plataforma en la nube que ofrece servicios sobre
demanda para construir, implementar, hospedar y administrar aplicaciones Web a través de
centros de datos administrados por Microsoft. Cuando utilizamos los servicios de Microsoft
Azure, debemos pagar sólo por los recursos que el sitio Web consume. Además, no tenemos
por qué preocuparnos por la construcción de una infraestructura escalable ya que Microsoft
Azure agrega recursos de forma automática a medida que el sitio Web crece.
Es importante mencionar que hay muchas otras tecnologías que no son de Microsoft y que podemos
utilizar para alojar sitios web. El más popular, por ejemplo, es Apache. Apache se ejecuta con mayor
frecuencia en los servidores Linux y a menudo se combina con MySQL para gestionar bases de datos
y PHP como un Framework Web basado en servidor. Esta configuración se conoce a menudo como la
pila Web Linux-Apache-MySQL-PHP (LAMP).
Microsoft Azure y IIS pueden alojar sitios Web escritos en ASP.NET, PHP, o Node.js. Los servidores
Web Apache se pueden utilizar para hospedar una serie de tecnologías Web del lado del servidor,
incluyendo PHP, Node.js y Python, pero los servidores Web Apache no se pueden utilizar para alojar
sitios Web ASP.NET aunque de manera NO oficial podemos encontrar foros donde los usuarios
comentan que han podido hospedar aplicaciones ASP.NET sobre Apache modificado algunos archivos
de configuración de Apache (Apache.exe.config y httpd.default.conf). Para más información, puede
consultarse el siguiente enlace: http://forums.asp.net/t/962964.aspx.
La mayoría de los sitios Web requieren alojar una base de datos para gestionar datos, como los
detalles del producto, información del usuario o temas de discusión de un foro. Podemos seleccionar
alguna de las siguientes tecnologías Microsoft para administrar los datos:
• Microsoft SQL Server. Microsoft SQL Server es una tecnología de Microsoft para alojar y
administrar datos. SQL Server es un servidor de base de datos de alta calidad que se puede
utilizar para almacenar cualquier base de datos desde las más simples hasta las más
complejas. SQL Server puede escalar para soportar bases de datos de gran tamaño y un gran
número de usuarios. Podemos construir clústeres de SQL Server para asegurar la mejor
disponibilidad y fiabilidad. Muchas de las organizaciones más grandes del mundo confían en
SQL Server para alojar datos.
• Microsoft Azure SQL Database. Base de datos SQL de Microsoft Azure es una plataforma de
base de datos en la nube y una parte de Microsoft Azure. Usando SQL Database, podemos
desplegar una base de datos y pagar sólo por las operaciones y el almacenamiento de los
datos que utilicemos. No debemos preocuparnos por la administración de nuestra
infraestructura de base de datos ya que la base de datos escala de forma automática según
crezca nuestro sitio Web.
Tecnologías de ejecución de código

El código que escribimos en una aplicación Web con una herramienta de desarrollo, debe ejecutarse
en uno de dos lugares:
• En el servidor Web. El código que se ejecuta en el servidor Web tiene acceso completo a los
recursos del servidor Web y a cualquier base de datos asociadas a él. Puede acceder a la
base de datos con rapidez, enviar mensajes de correo electrónico y generar páginas Web.
• En el navegador Web del Usuario. El código que se ejecuta en el navegador Web del usuario
responde rápidamente a las acciones del usuario, tales como clics del ratón, pero está más
limitado en lo que puede hacer sin interactuar con el servidor Web.
Es necesario utilizar diferentes tecnologías para ejecutar código en el servidor y el código en el

cliente.
Ejecución del lado del Servidor
Microsoft ASP.NET es un entorno Web del lado del servidor que ejecuta código .NET del lado del
servidor, código que podemos escribir en Visual Studio o WebMatrix. El código puede acceder a una
base de datos, generar las páginas HTML y entregarlas al navegador Web. El modelo de
programación MVC es una parte de ASP.NET. Otras tecnologías No Microsoft del lado del servidor
son PHP y Node.js.
Ejecución del lado del Cliente
La mayoría de los navegadores Web pueden ejecutar código escrito en el lenguaje JavaScript. Este
código es enviado al navegador como texto dentro de la página HTML generada o en un archivo .js
separado. Debido a que JavaScript se ejecuta de forma local en el navegador, puede responder
rápidamente a las acciones del usuario tales como al hacer clic, apuntar o arrastrar el puntero del
mouse.
Muchas bibliotecas JavaScript están disponibles para acelerar el desarrollo del código del lado del
cliente. Por ejemplo, la popular biblioteca jQuery hace que sea fácil de acceder a elementos de la
página y manipularlos mediante el cambio de su estilo o contenido. Al utilizar estas bibliotecas,
podemos escribir funciones con pocas líneas de código que de otro modo requerirían cientos de
líneas de nuestro propio código JavaScript.
Las aplicaciones ASP.NET también pueden utilizar la tecnología Asynchronous JavaScript and XML
(AJAX) en la computadora del cliente. Podemos utilizar AJAX para actualizar una pequeña sección de
una página HTML en lugar de volver a cargar la totalidad de la página desde el servidor. Las
actualizaciones parciales de página ayudan a crear páginas Web más responsivas y atractivas.
Visión general de ASP.NET

Podemos utilizar ASP.NET para desarrollar sitios Web con acceso a bases de datos, altamente
funcionales, dinámicos y escalables que utilicen código en el lado del cliente y código en el lado del
servidor. Se pueden crear diferentes tipos de sitios Web con ASP.NET, por ejemplo, portales Web,
sitios de compras en línea, blogs y wikis entre otros.
Modelos de programación
Cuando utilizamos ASP.NET para construir una aplicación, no estamos limitados a un solo estilo de
programación, por el contrario, podemos elegir entre tres modelos de programación diferentes. Cada
modelo de programación tiene una estructura particular en el entorno de desarrollo y almacena el
código en diferentes lugares de la jerarquía Web.
• Web Pages. El modelo de programación ASP.NET Web Pages es un modelo de programación

simple y fácil de aprender y es adecuado para sitios simples de acceso a datos.
Crear una aplicación Web con este modelo es tan sencillo como crear una página HTML y
agregar el código que deseamos que el motor ASP.NET ejecute del lado del servidor para
procesar los datos de una base de datos, responder a un envío (post) de un formulario o
realizar otras acciones.
El código del lado del servidor puede ser escrito con el lenguaje de programación C# o con
VB.NET. Si el código esta en C#, el nombre del archivo debe tener la extensión CSHTML y si el
código es Visual Basic, la extensión debe ser VBHTML.
El modelo de desarrollo Web Pages es similar al de las páginas ASP anterior a .NET donde se
mezclaba en un solo archivo código HTML con código para ejecutarse del lado del servidor
con Visual Basic Scripting Edition.
• Web Forms. Cuando construimos un sitio Web mediante el uso de ASP.NET Web Forms,
empleamos un modelo de programación con controles ricos del lado del servidor y un ciclo
de vida de página similar al desarrollo de aplicaciones de escritorio. Los controles integrados
incluyen botones, cuadros de texto y Grids para mostrar datos en forma tabular. También
podemos agregar controles de terceros o crear controles personalizados. Para responder a
las acciones del usuario, podemos asociar a los controles del lado del servidor, controladores
de eventos conteniendo código. Por ejemplo, para responder a un clic en un botón
podríamos escribir código en el controlador del evento Click del botón.
• MVC. Cuando construimos un sitio mediante ASP.NET MVC, separamos el código del lado del
servidor en tres partes:
o Modelo: Un modelo MVC define un conjunto de clases que representan los tipos de
objetos que la aplicación Web administra. Por ejemplo, el modelo de un sitio de
comercio electrónico podría incluir una clase modelo Producto que defina
propiedades tales como la descripción, número de catálogo, precio y otros. Los
Modelos suelen incluir lógica de acceso a datos que lee datos desde una base de
datos y escribe datos a esa base de datos.
o Vistas: Una vista MVC es un componente que construye las páginas Web que
conforman la interfaz de usuario de la aplicación Web. Los controladores suelen
pasar una instancia de una clase del Modelo a una Vista. La Vista muestra las
propiedades de la clase Modelo. Por ejemplo, si el controlador pasa un objeto
Producto, la vista puede mostrar el nombre del producto, una imagen y su precio.
o Controladores: Un controlador MVC es una clase que se encarga de la interacción del

usuario, crea y modifica clases del Modelo y selecciona las Vistas correspondientes.
Por ejemplo, cuando un usuario solicita detalles completos acerca de un producto en
particular, el controlador crea una nueva instancia de la clase modelo Producto y la
pasa a la Vista de detalles para que la muestre al usuario.
Esta separación de código de Modelo, Vista y Controlador garantiza que las aplicaciones MVC
tengan una estructura lógica, incluso para los sitios más complejos. También mejora la
capacidad de prueba de la aplicación. En última instancia, ASP.NET MVC proporciona un
mayor control sobre el código HTML en comparación con Web Pages y Web Forms.
¿Cuál de los tres modelos de programación proporciona el máximo control

sobre el código HTML y JavaScript que se envía al navegador?
MVC y Web Pages proporcionan un alto nivel de control sobre el código

HTML y JavaScript mediante el uso de las Vistas.
La API ASP.NET
Sea cual sea el modelo de programación que elijamos, tenemos acceso a las clases de la API ASP.NET.
Estas clases están incluidas en el .NET Framework en espacios de nombre dentro del espacio de
nombre System.Web y pueden ser utilizadas para implementar rápidamente funcionalidades Web
comunes, tales como:
• Configuración. Utilizando archivos web.config, podemos configurar la aplicación Web

independientemente del modelo de programación. Los archivos web.config son archivos
XML con etiquetas y atributos específicos que el motor en tiempo de ejecución de ASP.NET
reconoce. Por ejemplo, podemos configurar conexiones de base de datos y páginas de error
personalizadas en el archivo web.config. En el código, se puede acceder a la configuración a
través de clases del espacio de nombres System.Web.Configuration.
• Autenticación y autorización. Muchos sitios Web requieren que los usuarios inicien sesión
mediante la introducción de un nombre de usuario y una contraseña, o proporcionando
información adicional. Podemos utilizar proveedores de membresía de ASP.NET para
autenticar y autorizar a los usuarios y restringir el acceso al contenido. También podemos
crear páginas que permitan a los usuarios registrar una nueva cuenta, restablecer una
contraseña, recuperar una contraseña perdida o realizar otras tareas de administración de
cuentas. Los proveedores de membresía pertenecen al espacio de nombres
System.Web.Security.
• Almacenamiento en caché. Para generar el código HTML de una página Web compleja que
puede requerir múltiples consultas de base de datos o llamadas a servicios Web externos,
ASP.NET puede demorarse un tiempo largo. Podemos utilizar el almacenamiento en caché
para atenuar este retraso. ASP.NET almacena en memoria caché una página ya generada,
para que pueda devolver la misma página a solicitudes posteriores de los usuarios sin tener
que generarla de nuevo desde el principio. De una manera similar, también se pueden
almacenar en caché los objetos del .NET Framework. Se puede acceder a las páginas en
caché mediante el espacio de nombres System.Runtime.Caching y configurar el
almacenamiento en caché en el archivo web.config.
Compilación del código ASP.NET

Debido a que el código del lado de servidor ASP.NET utiliza el .NET Framework, debemos escribir
código en un lenguaje de programación .NET administrado como C# o Visual Basic. Antes de ejecutar
el código, este debe ser compilado a código nativo para que el CPU del servidor pueda procesarlo.
Este es un proceso de dos etapas:
• La primera etapa es la compilación a código MSIL. Cuando se construye un sitio Web en

Visual Studio, el compilador de ASP.NET crea archivos .dll con todo el código compilado en
Microsoft Intermediate Language (MSIL). Este código es independiente tanto del lenguaje
que se utilizó para escribir la aplicación como de la arquitectura del CPU del servidor.
• En la etapa 2, se realiza la compilación a código nativo. Cuando se solicita una página por
primera vez, el Common Language Runtime (CLR) compila el código MSIL a código nativo del
CPU del servidor.
Este proceso de compilación de dos etapas permite a los componentes escritos en diferentes
lenguajes trabajar juntos y permite la detección de muchas fallas en tiempo de compilación.
Debemos tener en cuenta, que las páginas pueden tardar más tiempo para generarse la primera vez
que se solicitan después de reiniciar el servidor. Para evitar este retraso, podemos pre-compilar el
sitio Web.
Cuando utilizamos el modelo de compilación predeterminado, los retardos pueden aparecer la

primera vez que un usuario solicita una página. Esto es debido a que ASP.NET debe compilar la
página antes de enviarla al navegador Web. Para evitar estos retardos y al mismo tiempo proteger el
código fuente, debemos utilizar la pre-compilación. Cuando pre-compilamos un sitio Web, todos los
archivos ASP.NET, incluyendo Controladores, Vistas y Modelos, son compilados en un simple archivo
.dll.
Para obtener más información sobre el proceso de compilación de ASP.NET, puedes

consultar los siguientes enlaces:
ASP.NET Compilation Overview

https://msdn.microsoft.com/en-us/library/ms178466.aspx
ASP.NET Web Site Precompilation

https://msdn.microsoft.com/en-us/library/ms228015.aspx
How to: Deploy a Web Project Using One-Click Publish in Visual Studio
https://msdn.microsoft.com/en-us/library/dd465337(v=vs.110).aspx
Tecnologías Web del lado del Cliente

Originalmente, en ASP.NET y tecnologías similares como PHP, todo el código se ejecutaba en el
servidor Web. Este enfoque es tradicionalmente práctico ya que el servidor Web por lo general tiene
acceso inmediato a la base de datos y mayor poder de procesador y memoria que un equipo cliente.
Sin embargo, en este enfoque, cada acción del usuario requiere un viaje de ida y vuelta entre el
cliente y el servidor Web y muchas acciones requieren una recarga completa de la página. Esto
puede requerir de un tiempo considerable. Para responder de forma rápida y proporcionar una
mejor experiencia de usuario, podemos complementar el código de servidor con el código del lado
del cliente que se ejecute en el navegador Web.
JavaScript
Uno de los lenguajes más utilizados para escribir código que se ejecute del lado del cliente es
JavaScript.
JavaScript es un lenguaje simple de scripting que tiene una sintaxis similar a C# y es soportado por la
mayoría de navegadores Web. Un lenguaje de scripting no es compilado. En lugar de eso, un motor
de scripts interpreta el código en tiempo de ejecución para que el navegador Web pueda ejecutar
dicho código.
Es importante mencionar que además de JavaScript, Internet Explorer soporta VBScript. Existen otros
lenguajes de scripting, pero JavaScript es soportado por prácticamente todos los navegadores Web y
no es el mismo caso de cualquier otro lenguaje de scripting.
Diferentes navegadores interpretan JavaScript de manera diferente. Cuando desarrollamos un sitio

Web para Internet, desconocemos que navegadores utilizarán los usuarios que visiten nuestro sitio
Web. Por consiguiente, debemos escribir código JavaScript el cual es soportado por prácticamente
todos los navegadores.
Podemos incluir código JavaScript en nuestras páginas ASP.NET independientemente del modelo de
programación que elijamos. JavaScript es un lenguaje poderoso, pero puede requerir muchas líneas
de código para lograr efectos visuales o llamadas a servicios externos.
Existen bibliotecas de scripts que contienen funciones JavaScript pre-construidas que ayudan a
implementar acciones comunes que podríamos querer realizar en el código del lado del cliente.
Podemos utilizar una biblioteca de scripts en lugar de construir todo por nosotros mismos desde
cero. El uso de una biblioteca de scripts ayuda a reducir el tiempo y esfuerzo de desarrollo.
jQuery
jQuery es una de las bibliotecas JavaScript más populares. jQuery proporciona funciones para
interactuar con los elementos HTML de la página y con estilos CSS. Por ejemplo, podemos buscar
todos los elementos <div> en una página Web y cambiar su color de fondo usando una sola línea de
código. Para lograr el mismo resultado utilizando únicamente JavaScript, tenemos que escribir varias
líneas de código y un ciclo de programación para recorrer cada elemento. Además, el código que
escribamos puede ser diferente para diferentes navegadores. Utilizando jQuery, es más fácil escribir
código para responder a las acciones del usuario y crear animaciones simples. jQuery también
maneja las diferencias entre navegadores. Podemos utilizar jQuery para invocar a los servicios Web
en equipos remotos y actualizar la página Web con los resultados devueltos.
El proyecto jQuery también incluye otras dos bibliotecas JavaScript que extienden a la librería base
jQuery:
• jQuery UI es una biblioteca que cuenta con un conjunto de widgets o controles que podemos
utilizar para apoyarnos en la construcción de una interfaz de usuario. Contiene widgets para
seleccionar fechas, spinners, cuadros de texto de autocompletar, cuadros de diálogo, y otros
widgets. Es posible también aplicar temas a los widgets de jQuery UI para integrar sus
colores y estilos con los colores que identifican al sitio Web.
• jQuery Mobile es una biblioteca que hace que sea fácil proporcionar una interfaz de usuario
a los dispositivos móviles, tales como teléfonos y tabletas. jQuery Mobile genera código
HTML utilizando mejoramiento progresivo. El mejoramiento progresivo es una estrategia
particular de diseño web que acentúa la accesibilidad en una manera adecuada que permite
que cada cliente tenga acceso al contenido y a la funcionalidad básica de una página Web,
usando cualquier navegador web o conexión a Internet al mismo tiempo que permite a otros
clientes con un mayor ancho de banda o un navegador Web más avanzado, experimentar
una versión mejorada de la página. Por ejemplo, utilizando jQuery Mobile, podemos mostrar,
controles ricos avanzados en dispositivos móviles avanzados como smartphones con
pantallas de gran tamaño al mismo tiempo que podemos mostrar una interfaz de usuario
más simple con la misma funcionalidad a los dispositivos móviles más viejos con pantallas
más pequeñas.
Es importante mencionar que existen muchas otras bibliotecas JavaScript tales como AngularJS,
Prototype, Enyo, Ext y el Toolkit Dojo entre otros. Si encontramos alguno de estos Frameworks más
apropiado para una tarea en particular o si tenemos experiencia desarrollando aplicaciones Web
mediante alguna de estas bibliotecas, podemos incluirla en las páginas ASP.NET en lugar de jQuery.
AJAX
AJAX es una abreviatura de Asynchronous JavaScript and XML. AJAX es una tecnología que permite a
los navegadores comunicarse con los servidores Web de forma asincrónica utilizando el Objeto
XMLHttpRequest sin actualizar completamente la página.
Podemos utilizar AJAX en una página para actualizar una parte de la página con nuevos datos, sin
tener que recargar toda la página. Por ejemplo, podríamos utilizar AJAX para obtener los últimos
comentarios sobre un producto sin actualizar la página entera del producto.
AJAX es implementado completamente en JavaScript. ASP.NET, de forma predeterminada, se basa en

la biblioteca jQuery para administrar las solicitudes y respuestas AJAX. El código se ejecuta de forma
asíncrona, lo que significa que el navegador Web no se congela mientras espera una respuesta AJAX
desde el servidor. En un principio, los desarrolladores utilizaban XML para formatear los datos
devueltos por el servidor, sin embargo, en la actualidad los desarrolladores utilizan JavaScript Object
Notation (JSON) como un formato alternativo a XML.
Internet Information Server

Cada sitio Web debe estar alojado en un servidor Web. Un servidor Web recibe peticiones de
contenido Web de los navegadores, ejecuta cualquier código del lado del servidor y devuelve páginas
Web, imágenes y otros contenidos. Se utiliza HTTP para la comunicación entre el navegador Web y el
servidor Web.
Internet Information Server es un servidor Web que se puede escalar desde un pequeño sitio Web
que se ejecuta en un único servidor Web hasta un gran sitio Web ejecutándose en una granja de
múltiples servidores Web. Internet Information Server está disponible en las versiones Servidor y
Escritorio de Windows.
Características de Internet Information Server

Internet Information Server está estrechamente integrado con ASP.NET, Visual Studio y el sistema
operativo Windows. Incluye las siguientes características:
• Protocolos de publicación. El protocolo avanzado Web Deploy, que se encuentra integrado

en Visual Studio, administra automáticamente el despliegue de un sitio Web con todas sus
dependencias. Alternativamente, podemos utilizar FTP para publicar contenido.
• Administración centralizada de Granjas Web. Cuando se ejecuta un sitio Web de gran

tamaño, podemos configurar una granja de carga de trabajo balanceada de varios servidores
IIS para escalar a grandes tamaños. Las herramientas de administración del IIS facilitan la
publicación de sitios a todos los servidores de la granja y administrar los sitios después de la
implementación.
• Caché de alto rendimiento. Podemos configurar ASP.NET para hacer un uso óptimo del
caché de IIS para acelerar las respuestas a las peticiones de usuario. Cuando IIS sirve una
página u otro contenido, este se puede almacenar en caché de memoria para que
posteriores solicitudes idénticas se puedan servir más rápido.
• Autenticación y seguridad. IIS soporta los estándares más comunes para la autenticación,
incluyendo la autenticación de tarjeta inteligente y la autenticación integrada de Windows.
También podemos utilizar SSL para encriptar comunicaciones sensibles de la seguridad, tales
como las páginas de inicio de sesión y páginas que contienen números de tarjetas de crédito.
• Soporte ASP.NET. IIS es el único servidor Web que soporta totalmente a ASP.NET.
• Otras Tecnologías del lado del servidor. Es posible alojar en IIS sitios Web desarrollados en
PHP y Node.js.
Escalamiento del IIS

Un solo servidor Web tiene una escalabilidad limitada ya que está limitado por la velocidad del
procesador, la memoria, la velocidad del disco, y otros factores. Además, los servidores Web
individuales son vulnerables a fallas de hardware y cortes de corriente eléctrica. Por ejemplo, cuando
un único servidor Web está desconectado, el sitio Web no está disponible para los usuarios.
Podemos mejorar la escalabilidad y la capacidad de recuperación de un sitio Web hospedándolo en

una granja de varios servidores. En estas granjas de servidores, varios servidores comparten el
mismo nombre de servidor. Por lo tanto, todos los servidores pueden responder a las peticiones del
navegador. Un sistema de balanceo de carga, tal como Windows Network Load Balancing o un
sistema basado en hardware, distribuyen las peticiones de manera uniforme entre los servidores de
la granja de servidores. Si un servidor falla, otros servidores están disponibles para responder a las
peticiones, y por lo tanto, la disponibilidad del sitio Web no se interrumpe. Los servidores IIS están
diseñados para trabajar en este tipo de granjas de servidores e incluyen herramientas avanzadas de
administración para implementación de sitios y administración de los servidores miembros.
Redes perimetrales
Los servidores Web, incluyendo IIS, son frecuentemente colocados en una red perimetral. Una red
perimetral cuenta con un segmento de red que está protegido de Internet a través de un cortafuegos
que valida y permite peticiones HTTP entrantes. Un segundo cortafuegos, que permite las peticiones
sólo desde el servidor Web, separa la red perimetral de la red interna de la organización. Los
servidores de apoyo, tales como servidores de bases de datos, normalmente se encuentran ubicados
en la red interna de la organización.
En esta configuración, los usuarios de Internet pueden acceder al servidor IIS para solicitar páginas y
el servidor IIS puede acceder el servidor de base de datos para ejecutar consultas. Sin embargo, los
usuarios de Internet no pueden tener acceso al servidor de base de datos o cualquier otra
computadora interna de manera directa. Esto evita que usuarios malintencionados ejecuten ataques
y asegura un alto nivel de seguridad.
IIS Express
Internet Information Server Express no ofrece todas las características de Internet Information
Server. Por ejemplo, no se puede crear granjas de servidores con equilibrio de carga de trabajo
utilizando Internet Information Server Express. Sin embargo, tiene todas las características necesarias
para hospedar sitios Web ricos de ASP.NET y otros sitios Web en un único servidor. Internet
Information Server Express se empezó a incluir con Windows 8. También se puede instalar en
Windows Server 2012, Windows Server 2008, Windows 7 y Windows Vista SP1 y posteriores
descargando y utilizando el Instalador de plataforma Web (Web PI).
IIS Express es el servidor Web predeterminado para proyectos de aplicaciones Web en Visual Studio y
es el que se recomienda utilizar cuando el sitio Web se hospedará en IIS pero no deseamos utilizar la
versión completa de IIS mientras estamos en el ambiente de desarrollo.
Otros servidores Web

Además de IIS de Microsoft, se encuentran disponibles otros servidores Web que no son de
Microsoft como por ejemplo nginx (se pronuncia engine-x) y Apache.
Apache es un servidor Web popular que puede ser instalado en Windows Server o computadoras con
cliente Windows para alojar sitios Web durante el desarrollo o para despliegues de producción. Sin
embargo, Apache no proporciona un soporte completo para alojar sitios Web ASP.NET.
Para mayor información sobre otros servidores Web, puedes consultar los siguientes
enlaces:
NGINX
http://nginx.org/
Apache
http://httpd.apache.org
Microsoft Azure
Microsoft Azure es un conjunto de servicios en la nube de Microsoft para hospedar sistemas críticos
de negocio. Cuando se ejecuta el código en Microsoft Azure, el código se ejecuta en servidores de los
centros de datos administrados por Microsoft ubicados en todo el mundo.
Microsoft Azure es una plataforma en la nube abierta y flexible que permite compilar, implementar y
administrar aplicaciones rápidamente, en una red global de centros de datos administrados por
Microsoft.
Tenemos dos principales ventajas cuando utilizamos Microsoft Azure para alojamiento y despliegue
de aplicaciones Web:
• Escalado flexible. A medida que las necesidades de una aplicación Web y su base de datos
crecen, recursos adicionales en el servidor son asignados automáticamente. No es necesario
hacer planes para granjas de servidores o sistemas de balanceo de carga ya que estos están
integrados en Microsoft Azure.
• Precio flexible: Con Microsoft Azure, podemos elegir un modelo de precios pago por uso
(pay-as-you-go), lo que significa que sólo pagamos por los recursos que utilizamos. Esto hace
que Microsoft Azure sea muy eficiente en costo para los sitios Web pequeños. También hace
que los costos sean predecibles para sitios Web grandes.
Podemos usar Microsoft Azure para hospedar lo siguiente:
• Sitios Web. Podemos hospedar un sitio web completo en Microsoft Azure. Microsoft Azure
soporta sitios Web desarrollados en ASP.NET, PHP, o Node.js. También podemos desplegar
sitios Web en Microsoft Azure directamente desde Visual Studio o WebMatrix.
• Servicios Web. Un servicio Web no incluye una interfaz de usuario como un sitio Web. En su
lugar, se compone de un conjunto de métodos que se pueden invocar desde otro software.
Podemos invocar a servicios Web desde dispositivos móviles, aplicaciones de escritorio y de
código del sitio Web ejecutándose en el lado del cliente o del lado del servidor.
• Bases de datos. Cuando utilizamos Internet Information Server para hospedar un sitio Web,
podemos utilizar SQL Server para almacenar la base de datos del sitio Web. Cuando alojamos
un sitio Web en Microsoft Azure, podemos utilizar SQL Database, que es un servicio de base
de datos en la nube basado en SQL Server para alojar la base de datos.
• Servidores virtuales. Podemos aprovisionar servidores virtuales enteros en Microsoft Azure

para ejecutar software crítico de negocio o utilizar los servidores virtuales como entornos de
prueba. Los servidores virtuales de Microsoft Azure pueden ejecutar los sistemas operativos
Windows Server o Linux.
• Servicios móviles. Si desarrollamos aplicaciones para dispositivos móviles, como teléfonos y

tabletas, podemos utilizar Microsoft Azure para hospedar servicios que las sustentan. Tales
servicios pueden proporcionar almacenamiento de preferencias del usuario,
almacenamiento de datos y otras funciones.
• Servicios de medios (Media Services). Cuando se utiliza Microsoft Azure para hospedar
medios, tales como audio y video, estos se hacen disponibles automáticamente para muchos
tipos de dispositivos, tales como ordenadores, teléfonos móviles y tabletas. Los medios son
codificados en distintos formatos, tales como formatos de Windows Media y MP4.
Para más información sobre Microsoft Azure, puedes consultar los

siguientes enlaces:
Prueba gratuita de un mes de Microsoft Azure

http://azure.microsoft.com/es-es/pricing/free-trial/
Microsoft Azure
http://azure.microsoft.com/es-es/
Lección 2
Visión general de ASP.NET
ASP.NET nos ayuda a crear sitios Web dinámicos que utilizan código del lado del cliente y del lado del
servidor. Además, con ASP.NET, no estamos limitados a un solo estilo de programación, sino que
podemos elegir entre tres diferentes modelos de programación: Web Pages, Web Forms y MVC.
Estos modelos de programación difieren entre si y tienen sus propias ventajas y desventajas en
diferentes escenarios. ASP.NET también ofrece diversas características que podemos utilizar
independientemente del modelo de programación que elijamos.
• Describir el modelo de programación Web Pages.

• Describir el modelo de programación Web Forms.
• Describir el modelo de programación MVC.
• Determinar cuál modelo utilizar, Web Pages, Web Forms o MVC dependiendo de las
necesidades de los Clientes.
• Describir las características que pueden ser utilizadas en todas las aplicaciones ASP.NET
independientemente del modelo de programación seleccionado.
Aplicaciones Web Pages

Web Pages o en español, Páginas Web, es el modelo de programación más simple que podemos
elegir para crear una aplicación Web en ASP.NET. Podemos utilizar este modelo para crear un sitio
Web de forma rápida y con poco conocimiento técnico.
Es posible utilizar Visual Studio o WebMatrix para crear aplicaciones Web Pages.
Hay un único archivo asociado con cada página Web que los usuarios pueden solicitar. Dependiendo
del lenguaje que deseamos utilizar, la extensión del archivo puede ser .cshtml para Visual C# o
.vbhtml para Visual Basic.
Para cada página, escribimos código HTML, código del lado del cliente y código del lado del servidor,
todo en el mismo archivo.
El símbolo @ se utiliza para distinguir entre el código del lado del servidor y, el código HTML y
JavaScript. Cuando los usuarios solicitan la página, el motor en tiempo de ejecución de ASP.NET
compila y ejecuta el código de servidor para generar código HTML y enviar el código HTML al
navegador Web para su visualización.
Supongamos que deseamos crear una página Web que nos permita mostrar el Catálogo de
Categorías de productos de un almacén utilizando un componente .NET existente.
Para que podamos utilizar el Assembly, debemos crear una carpeta bin en la raíz de sitio Web y ahí
copiar el Assembly para que de esta forma podamos consumirlo en la Web Page.
El siguiente ejemplo muestra el código del lado del servidor que permite crear una instancia de una
clase llamada Repositorio y obtener el valor de la propiedad Categorias.
@{
var Repositorio = new Data.Repositorio();
var Categorias = Repositorio.Categorias;
}
El siguiente ejemplo, muestra el código HTML combinado con código C# que se ejecutará del lado del
servidor para mostrar el nombre de cada categoría con un enlace a la página que muestra su detalle.
<body>
<h2>Categorías de productos disponibles</h2>
@foreach(var c in Categorias)
{
<a href="@(c).cshtml">@c</a><br/>
}
</body>
Ventajas y desventajas del modelo Web Pages

El modelo de programación Web Pages tiene varias ventajas:
• Es fácil de aprender.
• Proporciona un control preciso sobre el código HTML generado.
• Puede ser escrito en WebMatrix o Visual Studio.
El modelo de programación Web Pages también tiene algunas desventajas:
• No proporciona control sobre las direcciones URL que aparecen en la barra de direcciones
para permitir el uso de URLs amigables.
• Los sitios Web grandes requieren un gran número de páginas, cada una de las cuales debe
ser codificada individualmente.
• No hay separación entre la lógica de negocio, la lógica de entrada, y la interfaz de usuario
Aplicaciones Web Forms

Web Forms es otro modelo de programación que podemos elegir en ASP.NET. WebMatrix no soporta
Web Forms, por lo que debemos utilizar Visual Studio para desarrollar una aplicación Web Forms.
Archivos de código en aplicaciones Web Forms

En una aplicación Web Forms, el código HTML y etiquetas de los controles se almacenan en archivos
con extensión .aspx. El código del lado del servidor se suele escribir en un archivo asociado con
extensión .cs para Visual C# o .vb para Visual Basic. Este archivo de código se conoce como code-
behind. Por ejemplo, una página con nombre Default.aspx por lo general tiene un archivo code-
behind llamado Default.aspx.cs o Default.aspx.vb dependiendo del lenguaje C# o Visual Basic
utilizado.
Las aplicaciones Web Forms también pueden contener archivos de clases con extensión .cs o .vb.
Controles Web Forms

Una aplicación Web Forms se caracteriza por controles que se pueden arrastrar desde la caja de
herramientas de Visual Studio hacia cada página web. Este método de crear una interfaz de usuario
es similar al método utilizado en aplicaciones de escritorio.
ASP.NET proporciona una amplia variedad de controles altamente funcionales que se pueden utilizar
en las aplicaciones Web Forms. Los controles disponibles incluyen:
• Controles de entrada, como cuadros de texto (TextBox), botones de opción (RadioButton) o

casillas de verificación (CheckBox)
• Controles de visualización, tales como cajas de imagen (Image), mapas de imágenes
(ImageMap) y rotadores de anuncios (Ad Rotator)
• Controles de visualización de datos como vistas de cuadrícula (GridView), vistas de
formulario (FormView) y gráficos (Chart)
• Controles de validación que comprueban los datos introducidos por el usuario
• Controles de navegación, como los menús (Menu) y vistas de árbol (TreeView)
También podemos crear nuestros propios controles personalizados para encapsular funcionalidad
personalizada. Después de agregar un control a una página, podemos escribir código para responder
a los eventos de usuario. Por ejemplo, podemos utilizar código en el evento clic de un botón para
procesar la entrada del usuario en un formulario.
El siguiente ejemplo, muestra el código que se ejecuta cuando el usuario da clic en un botón de
comandos.
protected void btnSumar_Click(object sender, EventArgs e)

{
lblR.Text = Operaciones.Suma(
int.Parse(txtA.Text),
int.Parse(txtB.Text)).ToString();
}
Enlazando controles a Datos

En las aplicaciones Web Forms, podemos mostrar fácilmente datos enlazando los controles a las
fuentes de datos. Esta técnica elimina la necesidad de hacer ciclos a través de renglones de datos y
construir presentaciones línea por línea. Por ejemplo, para enlazar un control GridView a una tabla
de una base de datos SQL Server, podemos abrir la ventana Server Explorer, establecer la conexión a
la fuente de datos y arrastrar una tabla de la base de datos hacia el formulario Web. Cuando la
página sea solicitada, ASP.NET ejecutará la consulta en el origen de datos y combinará los registros
devueltos de datos con la página Web.
Ventajas y desventajas del modelo Web Forms

El modelo de programación Web Forms tiene varias ventajas:
• La página puede diseñarse visualmente utilizando controles de servidor y la Vista de Diseño.

• Es posible utilizar una amplia gama de controles altamente funcionales que encapsulan una
gran cantidad de funcionalidad.
• Es posible mostrar datos sin tener que escribir muchas líneas de código del lado del servidor.
• La interfaz de usuario en el archivo .aspx está separada de la lógica de entrada y de negocio
en archivos de código subyacente (code-behind).
El modelo de programación Web Forms también tiene desventajas:
• El ciclo de vida de la página ASP.NET Web Forms es una capa de abstracción a través de HTTP
y puede comportarse de formas inesperadas. Debemos tener una comprensión completa de
este ciclo de vida con el fin de escribir código en los controladores de eventos correctos.
• No se tiene un control preciso sobre el código HTML generado por los controles de servidor.
• Los controles pueden añadir a la página HTML generada grandes cantidades de código HTML
y de información para manejo de estado. Esto incrementa el tiempo necesario para cargar las
páginas.
Aplicaciones MVC
MVC es otro modelo de programación disponible en ASP.NET. Para crear aplicaciones MVC debemos
utilizar Visual Studio ya que WebMatrix no cuenta con plantillas para crear aplicaciones MVC.
Las aplicaciones MVC se caracterizan por una fuerte separación de la lógica de negocio, la lógica de
interacción con el usuario y la interfaz de usuario. La lógica de negocios corresponde al Modelo, la
lógica de interacción con el usuario corresponde al Controlador y la lógica para crear la interfaz de
usuario corresponde a la Vista.
Modelos
Cada sitio Web presenta información sobre diferentes tipos de objetos a los visitantes del sitio. Por
ejemplo, un sitio Web de una empresa ficticia llamada NorthWind que vende productos puede
presentar información sobre el catálogo de Categorías y Productos. Una Categoría puede incluir
propiedades como Nombre y Descripción. Un Producto puede tener propiedades tales como
Nombre, Categoría asociada, Precio unitario y Unidades en existencia. Cada Categoría está ligada a
uno o más Productos.
Cuando desarrollemos un sitio Web MVC para esta empresa, debemos crear un modelo con una
clase para representar Categorías y una clase para representar Productos. Estas clases del modelo
incluirían las propiedades descritas y pueden incluir métodos tales como "ComprarProducto" o
"MostrarProductosDeUnaCategoria". Si las Categorías y los Productos son almacenados en una base
de datos, el modelo puede incluir el código de acceso a datos para poder leer y modificar registros.
El Modelo tradicionalmente se incluye en un Assembly propio, externo a la aplicación Web MVC. Sin
embargo, también podemos utilizar la carpeta Models para agregar las clases que componen el
modelo.
Los modelos son clases .NET personalizadas y almacenan código en archivos .cs o .vb dependiendo el
lenguaje de desarrollo seleccionado. Podemos utilizar Entity Framework para crear el Modelo de una
aplicación Web ASP.NET MVC.
Controladores
Cada sitio Web debe interactuar con los usuarios cuando realicen alguna petición, por ejemplo,
cuando hagan clic en botones y enlaces. Los controladores son los encargados de interactuar con el
usuario. Los controladores responden a las acciones del usuario, cargan datos desde un modelo y lo
pasan a una vista para que esta genere una página Web. Por ejemplo, en el sitio de la empresa
NorthWind, cuando el usuario solicite a través de un Url ver el catálogo de productos, un Controlador
atenderá la petición. Una técnica común al crear aplicaciones MVC es crear un Controlador por cada
clase modelo que se desee exponer. Por ejemplo, el controlador ProductController atenderá las
peticiones sobre el catálogo de Productos expuesto a través de la clase modelo Product. El nombre
del controlador lleva el nombre de la clase Modelo y el sufijo Controller. De manera predeterminada,
MVC utiliza una convención de nombres, pero nosotros podemos personalizarla de acuerdo con
nuestras necesidades. La convención de nombres predeterminada de MVC requiere del sufijo
Controller. El nombre es de nuestra elección.
Los controladores son clases .NET que heredan de la clase System.Web.Mvc.Controller y almacenan
código en archivos .cs o .vb dependiendo del lenguaje de desarrollo seleccionado. Cuando el usuario
solicite a través de un Url ver el catálogo de productos, el Controlador recibirá la solicitud del usuario
a través de un método de acción por ejemplo “Index”.
El siguiente ejemplo muestra el código de un método de acción Index que carga los datos de los
Productos desde el Modelo y los pasa a la Vista encargada de generar una página Web que muestra
esos datos.
public ActionResult Index()

{
List<Models.Product> Productos;
using (var Context = new Models.NorthwindEntities())
{
Productos = Context.Products.ToList();
}
return View(Productos);
}
Los controladores implementan la lógica de entrada y enlazan los modelos a las vistas correctas.
Vistas
Cada sitio Web debe generar páginas HTML que un navegador pueda mostrar. Esta generación de
páginas HTML es realizada por las Vistas. Por ejemplo, en el sitio de nuestra empresa NorthWind, una
Vista puede recibir por parte del Controlador, los datos de una colección de Productos extraídos del
Modelo y presentarlos en una página Web para que el usuario pueda verlos.
En las aplicaciones MVC, las Vistas crean la interfaz de usuario. Las Vistas son páginas que almacenan
código HTML en archivos .cshtml o .vbhtml dependiendo del lenguaje de desarrollo que estemos
utilizando. Esto quiere decir que son como Web Pages, pero sólo incluyen código de la interfaz de
usuario.
Ventajas y desventajas del modelo MVC

El modelo de programación MVC tiene varias ventajas:
• Las vistas permiten al desarrollador tomar el control preciso del código HTML que se genera
• Podemos utilizar el motor de enrutamiento para tener un control preciso de las direcciones
URL
• La lógica de negocio, la lógica de entrada y la lógica de la interfaz de usuario están separadas

en Modelos, Controladores y Vistas.
• El Modelo MVC facilita las técnicas de pruebas unitarias y Test Driven Development (TDD)
El modelo de programación MVC tiene algunas desventajas:
• MVC es potencialmente más complejo de entender que los modelos Web Pages o Web
Forms
• MVC obliga a separar responsabilidades en Modelos, Vistas y Controladores. Algunos
programadores pueden encontrar esto como todo un desafío
• No es posible crear una interfaz de usuario de manera visual arrastrando los controles desde
una barra de herramientas hacia una página tal y como lo hacemos en Web Forms
• En MVC no existen controles con eventos del lado del servidor, en lugar de eso, se responde
a la interacción del usuario mediante métodos de acción
• Se debe tener un entendimiento completo de HTML, CSS y JavaScript para desarrollar las
Vistas
Características compartidas
ASP.NET también incluye una serie de características que están disponibles independientemente del
modelo de programación que se utilice. Esto significa que si estamos familiarizados con estas
características trabajando con Web Pages o Web Forms, nuestros conocimientos también pueden
ser utilizados en Aplicaciones MVC.
Configuración
Al configurar un sitio ASP.NET, podemos controlar cómo se manejan los errores, cómo el sitio se
conecta a bases de datos, cómo se valida la entrada del usuario y muchas otras opciones. Podemos
configurar sitios ASP.NET mediante la creación y edición de archivos web.config. El archivo
web.config en la carpeta raíz del sitio configura todo el sitio, pero se puede sobrescribir esta
configuración en los niveles inferiores mediante la creación de archivos web.config en subcarpetas.
Los archivos web.config son archivos XML con un conjunto de elementos y atributos que el motor en
tiempo de ejecución de ASP.NET acepta.
Si en tiempo de ejecución desde el código .NET del lado del servidor se necesita tener acceso a los
valores de configuración, se puede utilizar el espacio de nombres System.Web.Configuration.
Autenticación
Muchos sitios Web identifican a los usuarios mediante la autenticación. Esto se realiza por lo general
mediante la solicitud y la comprobación de credenciales, tales como un nombre de usuario y una
contraseña, aunque la autenticación se puede hacer mediante el uso de métodos más sofisticados
como el uso de tarjetas inteligentes. Algunos sitios requieren que todos los usuarios se autentiquen
antes de que puedan acceder a cualquier página, pero es común permitir el acceso anónimo a
algunas páginas y requerir autenticación sólo para contenido confidencial o de suscripción.
ASP.NET soporta varios mecanismos para autenticación. Por ejemplo, si se está utilizando Internet
Explorer en un equipo Windows, ASP.NET puede ser capaz de utilizar la autenticación integrada de
Windows. En este mecanismo, la cuenta de usuario de Windows se utiliza para identificar al usuario.
Al crear sitios de Internet, no puede asegurarse de que los usuarios tengan Windows, un navegador
compatible, o una cuenta de acceso, por lo que se utilizan a menudo formularios de autenticación.
Los formularios de autenticación son soportados por la mayoría de los navegadores y pueden ser
configurados para comprobar las credenciales del usuario almacenadas en una base de datos,
servicio de directorio o en otros almacenamientos de cuentas de usuario.
Roles y Membresía
En muchos sitios de Internet, por ejemplo, Facebook y Twitter, los usuarios pueden crear sus propias
cuentas y establecer las credenciales. De esta manera, un sitio puede soportar un gran número de
miembros sin que se requiera una gran cantidad de esfuerzo administrativo porque los
administradores no tienen que crear cuentas de usuarios.
En ASP.NET, un proveedor de membresía es un componente que implementa las funciones de

administración de cuentas de usuario. Varios proveedores de membresía son soportados por
ASP.NET, tal como el Proveedor de Membresía de SQL (SQL Membership Provider), que utiliza una
base de datos SQL para almacenar cuentas de usuario. También, en caso de que se tengan requisitos
únicos, se puede crear un proveedor de membresía personalizado heredando de uno de los
proveedores predeterminados.
Cuando se tiene más que unos pocos usuarios, es posible que se desee agruparlos en Roles con
diferentes niveles de acceso. Por ejemplo, podemos crear un Rol de "Miembros Platino", que
contenga las cuentas de usuario con acceso a las mejores ofertas. Los proveedores de Roles ASP.NET
permiten crear y llenar los roles con el mínimo de código personalizado.
Se puede permitir el acceso a las páginas de un sitio Web para cuentas de usuario individuales o para
todos los miembros de un Rol. Este proceso se conoce como autorización.
Administración del estado

Los servidores Web y los navegadores Web se comunican a través de HTTP. Este es un protocolo sin
estado, donde cada petición es independiente de las peticiones anteriores y posteriores a ella. Los
valores de las solicitudes anteriores no son recordados automáticamente. Sin embargo, cuando se
crea una aplicación Web, frecuentemente se deben preservar valores a través de varias peticiones de
páginas. Por ejemplo, si un usuario introduce un producto en un carro de compras y posteriormente
hace clic en "Ver carrito de compras", se trata de una solicitud Web independiente, pero el servidor
debe preservar el contenido de ese carro de compras, de lo contrario, sería vaciado y el cliente no
podría realizar compras. ASP.NET ofrece diversos lugares donde se puede almacenar tales valores o
información de estado a través múltiples solicitudes.
Almacenamiento en caché
Una página ASP.NET se construye dinámicamente por el motor en tiempo de ejecución de ASP.NET
en el servidor Web. Por ejemplo, en una aplicación Web Pages, el motor en tiempo de ejecución
debe ejecutar el código C# de la página para generar HTML para enviarlo al navegador. Ese código C#
puede realizar operaciones complejas y que requieren mucho tiempo. Puede ejecutar varias
consultas contra una base de datos o llamar servicios en servidores remotos. Es posible mitigar estos
retardos mediante almacenamiento en el caché de páginas ASP.NET.
Por ejemplo, se puede utilizar el caché de páginas ASP.NET para almacenar en la memoria del
servidor Web la versión generada de una página solicitada con frecuencia. La primera página de un
catálogo de productos puede ser solicitada cientos o miles de veces al día por varios usuarios. Si se
almacena la página en memoria caché la primera vez que se genera, el servidor Web puede servir a la
mayoría de los usuarios con gran rapidez, sin consultar al servidor de base de datos y sin construir la
página desde cero.
Lección 3
Introducción a ASP.NET MVC
En esta lección, conoceremos la forma en que los Modelos, las Vistas y los Controladores trabajan en
conjunto para generar el contenido HTML que es enviado al Cliente. Al conocer esta relación,
podremos construir aplicaciones Web eficientes.
• Describir los Modelos, Vistas y Controladores.

• Explorar las principales características de una aplicación Web ASP.NET MVC en Visual Studio.
Modelos, Vistas y Controladores

Los Modelos representan los datos y la lógica de negocio asociada, las Vistas construyen la interfaz
de usuario y los Controladores interactúan con las solicitudes del usuario e implementan la lógica de
entrada.
Al examinar cómo una solicitud de un usuario es procesada por ASP.NET MVC, podremos entender
cómo fluyen los datos a través de los Modelos, las Vistas y los Controladores antes de ser enviados al
navegador Web del usuario.
Modelos y datos
Un Modelo es un conjunto de clases .NET que representan objetos utilizados en el sitio Web.
Por ejemplo, el modelo para una aplicación de comercio electrónico puede incluir una clase modelo
Producto con propiedades como la Descripción, el Identificador del Producto, el Nombre, el Número
de Catálogo, el Número de Parte y el Precio. Al igual que cualquier clase .NET, las clases del modelo
pueden incluir un constructor que es un procedimiento que se ejecuta cuando se crea una nueva
instancia de esa clase. También podemos incluir otros procedimientos de ser necesario. Estos
procedimientos encapsulan la lógica de negocio. Por ejemplo, podemos escribir un procedimiento
Publicar que marque un producto como listo para vender.
La mayoría de los sitios Web almacenan información en una base de datos. En una aplicación MVC, el
modelo incluye código que lee y escribe registros de la base de datos.
ASP.NET MVC trabaja con diferentes Frameworks de acceso a datos, sin embargo, el Framework
comúnmente más utilizado es Entity Framework.
Controladores y Acciones
Un Controlador es una clase .NET que responde a las peticiones del navegador Web en una
aplicación MVC. Por lo general hay una clase Controlador para cada clase modelo. Los controladores
incluyen acciones, que son métodos que se ejecutan en respuesta a una solicitud del usuario. Por
ejemplo, el controlador Producto puede incluir una acción Comprar que se ejecuta cuando el usuario
hace clic en el botón Agregar al carro en la aplicación Web.
Los controladores heredan de la clase base System.Web.Mvc.Controller. Las acciones normalmente

devuelven un objeto System.Web.Mvc.ActionResult.
Vistas y Razor
Una Vista es de manera predeterminada un archivo .cshtml o .vbhtml que incluye etiquetas HTML y
código de programación. A menudo, la vista expone al usuario las propiedades de una clase Modelo.
Un motor de Vistas interpreta los archivos de Vistas, ejecuta el código del lado del servidor y genera
código HTML para el navegador Web.
Razor es el motor de Vistas predeterminado en ASP.NET MVC, pero ASP.NET MVC también soporta el
motor de vistas ASPX. El motor de Vistas Razor identifica el código del lado del servidor buscando el
símbolo @. Adicionalmente, es posible instalar motores de Vistas alternativos como Spark y Nhaml
(se pronuncia enamel).
Ciclo de Vida de una Petición

El ciclo de vida de una petición comprende una serie de eventos que ocurren cuando una petición
Web es procesada.
Supongamos que un usuario realiza una petición para ver el detalle de un Producto cuyo ID es “1”.
Los siguientes pasos ilustran el proceso que la aplicación MVC sigue para responder a la petición:
1. El ciclo de vida de la petición inicia cuando el usuario solicita la dirección web:

http://www.northwind.com/producto/mostrar/1
2. El motor de enrutamiento MVC examina la petición y determina que la petición debe ser
dirigida al Controlador Producto y la acción Mostrar.
3. La acción Mostrar en el Controlador Producto crea una nueva instancia de la clase modelo
Producto.
4. La clase modelo Producto consulta a la base de datos para obtener información sobre el
producto con ID "1".
5. La acción Mostrar también crea una nueva instancia de la Vista que muestra un Producto y le
pasa el Modelo Producto.
6. El motor de vistas Razor ejecuta el código del lado del servidor de la vista que muestra el
Producto para generar el contenido HTML. En este caso, el código del lado del servidor
inserta propiedades, tales como Título, Descripción, Número de Catálogo y el Precio en el
código HTML.
7. La página HTML generada se devuelve al navegador Web para su visualización.
Explorando una aplicación MVC

Demostración
En esta demostración se explora la estructura de una aplicación MVC de ejemplo. Durante la
demostración toma en cuenta los siguientes puntos:
 Una aplicación MVC no requiere de una página de inicio default.html, default.aspx o

default.cshtml.
 En la carpeta Controllers se encuentran los Controladores de la aplicación.
 Las clases que definen a los Controladores deben llevar de manera predeterminada el sufijo
Controller y derivar de la clase System.Web.Mvc.Controller.
 Los Controladores contienen métodos de acción que representan acciones que devuelven
tradicionalmente una Vista.
En MVC se utiliza la convención por nombres para determinar la Vista

predeterminada de un método de acción de un Controlador.
 Las Vistas asociadas a un controlador se encuentran en la carpeta Views/<nombre del

Controlador>. Dentro de ese directorio se pueden encontrar las Vistas cuyo nombre es
similar al de los métodos de acción del controlador. Por ejemplo, en la carpeta Views/Home
se puede encontrar la vista llamada index que es la vista predeterminada del método de
acción Index del controlador Home.
 Las Vistas contienen código HTML e instrucciones Razor que permitirán generar el contenido
HTML final que será devuelto al navegador Web como respuesta a las peticiones.
 En el método RegisterRoutes del archivo App_Start/RouteConfig.cs se definen las rutas que
direccionan las peticiones de los usuarios a los controladores.
 Las clases Modelo utilizadas en la aplicación se encuentran en la carpeta Models. También es
posible ubicar las clases Modelo en su propio Assembly en lugar de ubicarlas en la carpeta
Models.
Características importantes de ASP.NET MVC

ASP.NET MVC incluye diversas características importantes entre las que podemos mencionar las
siguientes:
• ASP.NET Web API. Esta es una de las características que facilitan la creación de un conjunto
de servicios Web que pueden responder a las peticiones del navegador utilizando verbos
simples HTTP, tales como GET, POST y DELETE. Utilizando Web API, podemos construir los
servicios Web de servidor que una aplicación Web cliente pueda invocar. El desarrollo de
aplicaciones Web utilizando Web API es una alternativa al uso de ASP.NET MVC.
• Características móviles. A medida que los teléfonos inteligentes y las tabletas se hacen
presentes por todas partes, debemos asegurarnos de que nuestros sitios Web se muestren
adecuadamente en todos los tamaños de pantalla, resoluciones, profundidades de color, etc.
ASP.NET MVC incluye varias características que facilitan estas tareas. Por ejemplo, las
plantillas de proyectos MVC han sido actualizadas para utilizar Bootstrap para proporcionar
un aspecto elegante y Responsivo que podemos personalizar fácilmente.
• Controladores asíncronos. Por lo general, una acción de controlador funciona

sincrónicamente. Si la acción toma mucho tiempo en ejecutarse, el usuario tiene que esperar
porque la acción utiliza un solo hilo. Con acciones asíncronas, podemos invocar a un método
de larga duración en un hilo independiente y esperar que los resultados sean devueltos. Esto
permite a una acción completar y responder al usuario antes de que los resultados sean
devueltos.
• ASP.NET Identity. Las platillas de los proyectos MVC han sido actualizados para utilizar
ASP.NET Identity para autenticación y administración de identidad. ASP.NET MVC
proporciona el soporte de los estándares OAuth y OpenID. Mediante el uso de los
estándares OAuth y OpenID para identificar usuarios conectados a la aplicación Web a través
de Internet, podemos invocar a los servicios de un sitio de un tercero para comprobar las
credenciales de un usuario. Podemos confiar en la identidad verificada por el sitio externo y
utilizarla para autorizar el acceso a los recursos internos. Con el uso de estas tecnologías, se
podría, por ejemplo, permitir a los usuarios acceder a los recursos internos, iniciando sesión
con su cuenta Microsoft, Google o Facebook.
• Agrupación y Reducción (Bundling and Minification). Cuando un navegador solicita una

página Web, el servidor devuelve frecuentemente la página con una hoja de estilo CSS y uno
o más archivos de JavaScript. ASP.NET MVC puede agrupar estos archivos en un único
archivo para aumentar la eficiencia de la respuesta. También puede reducir estos archivos,
mediante la eliminación de espacios en blanco, acortando los nombres de variables y
realizando otras acciones que ahorran espacio. Esto ahorra tiempo de descarga y recursos
del servidor y del cliente además de hacer que la aplicación Web sea más rápida.
Programador Jr. de
MVC
Modulo 2: Disenando aplicaciones Web
ASP.NET MVC
Acerca del módulo

Microsoft ASP.NET MVC es un modelo de programación que se puede utilizar para crear aplicaciones
web complejas y poderosas. Sin embargo, todos los proyectos de desarrollo complejos y proyectos
grandes en general, pueden ser desafiantes y complicados de entender completamente.
Sin una comprensión completa de los propósitos de un proyecto, no se puede desarrollar una
solución efectiva al problema del cliente. Es necesario saber cómo identificar un conjunto de
necesidades de negocio y planificar una aplicación Web MVC para cumplir esas necesidades.
El plan del proyecto que se crea, asegura a los interesados de la aplicación que hemos entendido sus
requerimientos y comunica a los desarrolladores que la crearán, la funcionalidad de la aplicación
web, la estructura de su interfaz de usuario y el almacenamiento de datos. Al escribir un plan
detallado y exacto del proyecto, podemos asegurar que las características poderosas de MVC sean
utilizadas apropiadamente para resolver los problemas de negocio de un cliente.
Objetivos
• Planear la estructura general de una aplicación Web MVC y considerar aspectos tales como la
administración de estado.
• Planear los Modelos, Controladores y Vistas que son requeridos para implementar un
conjunto dado de requerimientos funcionales.

• Lección 1: Planeación en la fase de diseño del proyecto
• Lección 2: Diseñando Modelos, Controladores y Vistas
Lección 1
Planeación en la fase de diseño del proyecto
Antes de planificar una aplicación Web Model-View-Controller (MVC) o empezar a escribir código,
debemos tener bien claras dos cosas: el problema de negocio que estemos tratando de resolver y los
componentes ASP.NET que podemos utilizar para construir la solución. Antes de diseñar la
arquitectura de una aplicación Web y su base de datos, debemos saber cómo identificar los
requerimientos que tienen los usuarios potenciales de una aplicación Web.
• Describir los distintos modelos de proyectos de desarrollo.

• Describir cómo recopilar información acerca de los requerimientos del proyecto cuando
construimos aplicaciones ASP.NET MVC.
• Determinar los requerimientos funcionales y problemas de negocio cuando construimos
aplicaciones ASP.NET MVC.
• Explicar cómo planificar el diseño de la base de datos cuando construimos una aplicación
Web.
• Describir posibles arquitecturas de aplicaciones distribuidas.
• Describir las opciones para planificar el manejo de estado en una aplicación Web.
• Describir las opciones para planificar la Globalización y Localización de una aplicación Web.
• Determinar los aspectos críticos del diseño de aplicaciones Web.
Metodologías de desarrollo de Proyectos

El desarrollo de una aplicación Web para Internet o Intranet es a menudo un proceso complejo que
implica muchos desarrolladores de diferentes equipos desempeñando varios roles. Para organizar el
proceso de desarrollo y garantizar que todas las personas en el proyecto trabajen en equipo,
podemos utilizar alguna Metodología de Desarrollo de la amplia gama de metodologías existentes.
Esas metodologías de desarrollo describen las fases del proyecto de desarrollo, los roles que las
personas toman, los entregables que concluyen cada fase y otros aspectos del proyecto. Debemos
elegir una metodología de desarrollo en una etapa temprana en el proyecto. Muchas organizaciones
tienen una metodología estándar que utilizan siempre para el desarrollo del proyecto.
Algunas metodologías de desarrollo de proyectos incluyen el Modelo de Cascada, el Modelo de

Desarrollo Iterativo, el Modelo de Prototipo, el Modelo de Desarrollo Ágil de Software, Programación
Extrema y el Desarrollo Orientado a Pruebas.
Las metodologías de desarrollo en Cascada, Iterativa y de Prototipos son modelos viejos y en la

actualidad menos populares. En la actualidad deberíamos inclinarnos por las metodologías Ágil,
Programación Extrema y Orientada a Pruebas que son los modelos más actualizados.
Modelo en Cascada (Waterfall Model)

El modelo de cascada es una metodología que define las siguientes fases del proyecto:
• Análisis de Viabilidad. En esta fase, los planificadores y desarrolladores estudian y
determinan los enfoques y las tecnologías que pueden ser utilizadas para construir la
aplicación.
• Análisis de requerimientos. En esta fase, los planificadores y analistas entrevistan a los
usuarios, directores, administradores y a otros involucrados en el desarrollo del software
para determinar sus necesidades.
• Diseño de la aplicación. En esta fase, los planificadores, analistas y desarrolladores registran
una solución propuesta.
• Codificación y pruebas unitarias. En esta fase, los desarrolladores crean el código y prueban
de forma individual los componentes que conforman el sistema.
• Integración y pruebas del sistema. En esta fase, los desarrolladores integran los
componentes que han desarrollado y prueban el sistema completo.
• Publicación y mantenimiento. En esta fase, los desarrolladores y los administradores
entregan la solución de tal forma que los usuarios pueden empezar a utilizar la aplicación.
El modelo de Cascada clasifica el proyecto de desarrollo en distintas fases, con una definición clara de
los entregables en cada fase. El modelo también hace hincapié en la importancia de las pruebas. Sin
embargo, el cliente no recibe ningún software funcional para su revisión hasta el final del proyecto.
Esto dificulta trabajar con cambios al diseño como respuesta a una retroalimentación o al manejo de
circunstancias alteradas.
Modelo de Desarrollo Iterativo (Iterative Development Model)

Cuando se utiliza un modelo de desarrollo iterativo, el proyecto se divide en partes pequeñas. Para
cada parte, realizamos las actividades relacionadas con todas las etapas del modelo en cascada. El
proyecto se construye etapa por etapa, con pruebas exhaustivas en cada etapa para asegurar la
calidad.
En un proyecto iterativo, podemos realizar las acciones correctivas al final de cada iteración. Esas
correcciones podrían reflejar un mejor entendimiento de los problemas de negocios,
retroalimentación importante de los usuarios o un mejor entendimiento de las tecnologías utilizadas
para construir la solución. Dado que los requerimientos son agregados al final de cada iteración, los
proyectos iterativos requieren una gran cantidad de esfuerzo de administración del proyecto y con
frecuencia presentan una saturación de esfuerzos planificados.
Modelo de Prototipos (Prototyping Model)

El modelo de Prototipos es adecuado para un proyecto en el que se empieza con pocos o escasos
requerimientos de negocio definidos. Esta situación ocurre cuando los clientes o los interesados en el
desarrollo de la solución tienen una idea vaga de sus necesidades y la forma de resolverlas.
En este enfoque, los desarrolladores crean una versión simplificada de la aplicación (Prototipo) y
luego buscan la retroalimentación de los usuarios del sistema. Esta retroalimentación sobre el
prototipo es utilizada para definir los requerimientos detallados que los desarrolladores utilizan en la
siguiente iteración para construir una solución que cumpla con las necesidades de las partes
interesadas para ayudarlos a realizar su trabajo.
Después de dos o más iteraciones, cuando tanto los interesados en el desarrollo como los
desarrolladores llegan a un consenso sobre los requerimientos, una solución completa es construida
y probada. El modelo de prototipos, sin embargo, puede llevar a una aplicación mal diseñada ya que
en ninguna etapa de proyecto hay un claro enfoque sobre la arquitectura general.
Modelo de Desarrollo Ágil de Software (Agile Software Development

Model)
El modelo de Cascada, el modelo de Desarrollo Iterativo y el modelo de Prototipos están basados
sobre la premisa de que los requerimientos de negocio y otros factores no cambian desde el principio
hasta el final del proyecto. En realidad, esta suposición es a menudo no válida. El Desarrollo Ágil de
Software es una metodología diseñada para integrar las circunstancias y requerimientos cambiantes
a lo largo de todo el proceso de desarrollo. Los proyectos ágiles se caracterizan por:
• Un desarrollo incremental. El software es desarrollado en ciclos rápidos que se construyen
sobre ciclos anteriores. Cada iteración se prueba exhaustivamente.
• Énfasis en las personas e interacciones. Los desarrolladores escriben código basados en lo
que la gente hace en sus roles en lugar de escribir código basados en lo que pueden hacer
con las herramientas de desarrollo.
• Énfasis en el software funcionando. En lugar de escribir documentos de diseño detallados
para las personas interesadas, los desarrolladores escriben soluciones que las personas
interesadas puedan evaluar en cada iteración para validar si se resuelve un requerimiento.
• Colaboración estrecha con los clientes. Los desarrolladores trabajan con los clientes y las
partes interesadas día con día para verificar los requerimientos.
Programación Extrema (Extreme Programming)

La Programación Extrema evolucionó del desarrollo Ágil de software. En la Programación Extrema, la
fase de diseño preliminar es reducida a un mínimo y los desarrolladores se enfocan en resolver unas
cuantas tareas críticas. Tan pronto como esas tareas críticas sean finalizadas, los desarrolladores
prueban la solución simplificada y obtienen una retroalimentación de las partes interesadas. Esta
retroalimentación ayuda a los desarrolladores a identificar los requerimientos detallados lo cual
evoluciona con el ciclo de vida del proyecto.
La Programación Extrema define una Historia de Usuario por cada rol de usuario. Una Historia de
Usuario describe todas las interacciones que un usuario con un rol específico podría llevar a cabo con
la aplicación terminada. La colección de todas las Historias de Usuario de todos los roles de usuario
describen la aplicación entera.
En la Programación Extrema, los desarrolladores frecuentemente trabajan en parejas. Un

desarrollador escribe el código y el otro desarrollador revisa el código para asegurar que utiliza
soluciones simples y se adhiere a las mejores prácticas. El desarrollo orientado a pruebas es una
práctica fundamental en la programación extrema.
Para obtener más información sobre el modelo de Programación Extrema, puedes

consultar el siguiente enlace:
Extreme Programming: A gentle introduction

http://www.extremeprogramming.org/
Desarrollo Orientado a Pruebas (Test Driven Development)

En el Desarrollo Orientado a Pruebas, los desarrolladores escriben código de prueba como su primera
tarea en una iteración dada. Por ejemplo, si deseamos escribir un componente que almacena
detalles de una tarjeta de crédito, comenzamos escribiendo las pruebas que el componente debe
pasar. Esto puede ser si cumple con un formato de número correctamente, si escribe cadenas en una
tabla de base de datos correctamente o si invoca a los servicios bancarios correctamente.
Después de definir las pruebas, escribimos el componente que debe pasar esas pruebas. En
iteraciones posteriores, las pruebas de la tarjeta de crédito permanecen en su lugar. Esto asegura
que, si se daña la funcionalidad de la tarjeta de crédito, tal vez por una refactorización de código o al
añadir un nuevo constructor, se detecta esto rápidamente porque las pruebas fallan.
En Microsoft Visual Studio, podemos definir un Proyecto de Pruebas dentro de la misma solución del
Proyecto principal para almacenar y ejecutar pruebas unitarias. Después de escribir las pruebas, se
pueden ejecutar por separado o en grupos después de cada cambio de código. Dado que los
proyectos MVC tienen el código del Modelo, la Vista y el Controlador en archivos separados, es fácil
crear pruebas unitarias para todos los aspectos del comportamiento de la aplicación. Esta es la
ventaja principal de MVC sobre las Web Pages y Web Forms.
Lenguaje Unificado de Modelado (Unified Modeling Language)

El Lenguaje Unificado de Modelado (UML) es una notación estándar de la industria para elaborar el
diseño de cualquier aplicación que utiliza la tecnología orientada a objetos.
UML no es un modelo de desarrollo. Más bien, los diagramas UML se utilizan a menudo para
planificar y documentar la arquitectura de la aplicación y sus componentes a través de todas las
metodologías de desarrollo de proyectos. Al utilizar UML para diseñar y documentar una aplicación,
creamos una serie de diagramas con formas y conectores estándar. Estos diagramas se pueden
clasificar en tres clases:
• Diagramas de Comportamiento. Estos diagramas representan el comportamiento de los
usuarios, las aplicaciones y los componentes de la aplicación.
• Diagramas de interacción. Estos diagramas son un subconjunto de los diagramas de
comportamiento que se enfocan en las interacciones entre los objetos.
• Diagramas de estructura. Estos diagramas representan los elementos de una aplicación que
son independientes del tiempo. Esto quiere decir que no cambian a través del ciclo de vida
de la aplicación.
Recopilación de Requerimientos
Cuando un proyecto es comisionado, necesitamos una visión de la solución. La visión a menudo
puede ser vaga y puede requerirse de una investigación más profunda antes de que podamos
agregar detalles y asegurar que todos los requerimientos de los interesados en el desarrollo del
proyecto estén cubiertos por la aplicación que construiremos. Los requerimientos pueden ser de 2
tipos:
• Requerimientos funcionales. Estos requerimientos describen cómo la aplicación se
comporta y responde a los usuarios. Los requerimientos funcionales son frecuentemente
llamados requerimientos de comportamiento. Ellos incluyen:
o Requerimientos de la interfaz de usuario. Estos requerimientos describen la forma
en que el usuario interactúa con una aplicación.
o Requerimientos de uso. Estos requerimientos describen lo que el usuario puede
hacer con la aplicación.
o Requerimientos de Negocio. Estos requerimientos describen la forma en que la
aplicación cumplirá las funciones de negocio.
• Requerimientos técnicos. Estos requerimientos describen las características técnicas de la
aplicación y se refieren a la disponibilidad, seguridad o el rendimiento. Estos requerimientos
algunas veces son llamados requerimientos no funcionales o requerimientos de no
comportamiento.
Generalmente se recopilan los requerimientos entrevistando a los interesados en el desarrollo de la

aplicación (stakeholders), tales como usuarios, administradores, otros desarrolladores, directores,
responsables de finanzas y directivos del equipo. Cada uno de estos grupos tendrá un conjunto
diferente de prioridades que la aplicación deberá cumplir.
Escenarios de uso y Casos de Uso

Un método común con el cual podemos construir un conjunto de requerimientos de la interfaz de
usuario, requerimientos de negocio y requerimientos de uso es preguntar a los usuarios lo que harán
con la aplicación que construiremos. Podemos registrar esas acciones como Escenarios de Uso y
Casos de Uso.
Un Escenario de Uso es un ejemplo concreto del mundo real, con nombres y valores de entrada
sugeridos de una interacción entre la aplicación y un usuario. El siguiente es un ejemplo simple:
1. Maria Sanders da clic en el enlace “Agregar foto” del menú principal del sitio.
2. Maria proporciona el texto “MariaS” en la caja de texto “Nombre de usuario” y la
contraseña en la caja de texto “Clave de acceso” para autenticarse en el sitio.
3. Maria escribe el título “Puesta de Sol” para la foto.
4. Maria busca el archivo JPEG para su nueva foto
5. Maria da clic en el botón Enviar.

6. La aplicación Web almacena la nueva foto y muestra la galería de fotos a Maria.
Un Caso de Uso es similar a un Escenario de Uso, pero es más generalizado. Los Casos de Uso no
incluyen nombres de usuario o valores de entrada. Ellos describen varias rutas de una interacción
que depende de lo que el usuario proporciona como entrada o de otros valores. El siguiente es un
ejemplo simple:
1. El usuario da clic en el enlace “Agregar foto” del menú principal del sitio.
2. Si el usuario es anónimo, se muestra la página de inicio de sesión y el usuario proporciona
sus credenciales.
3. Si las credenciales son correctas se muestra la vista “Agregar foto”.
4. El usuario escribe un título.
5. El usuario especifica el archivo de la foto a subir.
6. El usuario escribe opcionalmente una descripción de la foto.
7. El usuario da clic en el botón Enviar.
8. La aplicación Web almacena la nueva foto y muestra la galería de fotos al usuario.
Al igual que las descripciones verbales, se pueden utilizar Diagramas de Casos de Uso UML para
registrar los Casos de Uso de la aplicación Web.
Mediante el análisis de los Escenarios de Uso y Casos de Uso, se pueden identificar los
requerimientos funcionales de todos los tipos. Por ejemplo, del anterior Caso de Uso se puede
identificar el siguiente requerimiento de interfaz de usuario:
La página Web que permite a los usuarios agregar una nueva foto debe incluir cuadros de texto
para el título y descripción, un control de entrada de archivo para seleccionar el archivo de la
foto y un botón Enviar para guardar la foto.
Modelado de requerimientos Ágil

En un modelo de cascada tradicional o modelo de desarrollo iterativo, los desarrolladores y analistas
investigan y registran los requerimientos técnicos y funcionales en una etapa temprana del proyecto
de una forma precisa y detallada y que no cambian posteriormente.
Por el contrario, en un proyecto basado en el modelo de desarrollo ágil, los desarrolladores

reconocen que los requerimientos pueden cambiar en cualquier momento durante el desarrollo. El
análisis de requerimientos es por lo tanto caracterizado de la siguiente manera:
• Modelado de requerimientos inicial. En la fase inicial de diseño, los desarrolladores

identifican y registran casos de uso pequeños en una manera informal sin detalles
completos.
• Modelado justo a tiempo (Just-in-time). Antes de escribir código que implemente un caso
de uso, un desarrollador lo discute con los usuarios relevantes. En este punto, el
desarrollador agrega detalles completos al caso de uso. En un proyecto de desarrollo ágil, los
desarrolladores hablan en todo momento con los usuarios y otras personas interesadas y no
sólo en el comienzo y el final del proyecto.
• Pruebas de aceptación. Una prueba de aceptación es una prueba que la aplicación debe
pasar para cada uno de los interesados de la aplicación y ser aceptada y firmada. Cuando se
identifica un requerimiento funcional, también puede especificarse una prueba de
aceptación correspondiente que debe ejecutarse para asegurar que los requisitos sean
cumplidos.
Historias de usuario en Programación Extrema

En proyectos de programación extrema, los desarrolladores realizan un análisis menor de
requerimientos funcionales al inicio del proyecto en comparación con otros modelos de desarrollo.
Ellos crean historias de usuario en lugar de casos de uso o escenarios de uso.
Una historia de usuario es un ejemplo muy amplio de una interacción entre la aplicación y un
usuario, y es a menudo expresado en una sola oración, como en el siguiente ejemplo:
Los usuarios pueden subir fotos y proporcionar a las nuevas fotos un título y una descripción
Las Historias de usuario contienen simplemente los detalles mínimos que permiten a los
desarrolladores estimar el esfuerzo involucrado para desarrollarlas. Los Programadores extremos
discuten cada historia de usuario con las partes interesadas antes de escribir el código para
implementar cada historia de usuario.
Planificando el Diseño de la Base de Datos

Cuando se tiene una buena comprensión de los requerimientos funcionales y técnicos de la
aplicación propuesta, se puede empezar a diseñar la implementación física de la aplicación.
Uno de los objetos físicos más importantes que debemos planificar, es el de una o más bases de
datos. Aunque no todas las aplicaciones utilizan bases de datos para almacenar información, ellas
son un objeto fundamental para la mayoría de los sitios y son utilizadas en la mayoría de los
proyectos.
Se puede comenzar el diseño de datos a un alto nivel creando diagramas UML de Modelo de Dominio
y diagramas de Modelo de Datos Lógico (LDM).
Diagrama de modelo de dominio (Domain Model)

Un diagrama de modelo de dominio, también conocido como un modelo conceptual de datos,
muestra los objetos conceptuales de alto nivel que gestiona la aplicación Web. Por ejemplo, en una
aplicación Web de comercio electrónico, el modelo de dominio podría incluir los conceptos de
Categorías, Productos y Proveedores entre otros más conceptos. El modelo de dominio no incluye
detalles de las propiedades tales como los tipos de datos que tiene cada concepto, pero muestra las
relaciones entre esos conceptos. El modelo de dominio es utilizado para registrar las conversaciones
iniciales con las partes interesadas (Stakeholders).
Diagrama de Modelo de Datos Lógico (Logical Data Model)

En esencia, un Modelo de datos Lógico es un diagrama de modelo de dominio con detalles extras
adicionales. Podemos utilizar diagramas de modelo lógico de datos para registrar más detalle, tales
como las propiedades y tipos de datos para los conceptos que hayamos definido en el modelo de
dominio.
Debemos tener en cuenta que los objetos en el modelo lógico de datos no corresponden a tablas en
la base de datos. Por ejemplo, un objeto Carrito de compras, puede mostrar datos de la tabla
Clientes y de la tabla Productos.
Estructura física de la Base de Datos

En UML, un modelo físico de datos es un diagrama que representa las tablas, columnas, tipos de
datos y las relaciones entre las tablas.
Debemos considerar los siguientes objetos de base de datos en nuestra planificación del proyecto:
• Tablas. Estos son los objetos fundamentales de almacenamiento de información en una base
de datos. Cuando se define una tabla, es necesario especificar las columnas que cada tabla
tiene. Para cada columna, se debe definir un tipo de datos tal como Entero, Cadena,
FechaHora, etc. También se debe definir la llave primaria de la tabla – el valor de esta
columna identifica cada registro (fila) de forma única y es esencial para definir las relaciones
con los registros de otras tablas.
• Vistas. Estos objetos son presentaciones comunes de los datos de las tablas y están basadas
en consultas. Por ejemplo, una vista puede unir a dos tablas tal como una tabla de productos
y una tabla de existencias en inventario.
• Procedimientos almacenados. Estos objetos son secuencias comunes de operaciones de
base de datos que se definen en la base de datos. Algunas operaciones son complejas y
pueden implicar una transformación compleja de los datos. Podemos implementar un
procedimiento almacenado para implementar esa rutina compleja.
• Seguridad. Se debe considerar la forma de como la aplicación Web se autenticará con el
servidor de base de datos y cómo se autorizará el acceso a cada tabla de la base de datos.
Trabajando con los administradores de bases de datos

Los administradores de bases de datos son contribuyentes críticos en la entrega de la aplicación.
En algunas ocasiones, el equipo de desarrolladores tiene control completo sobre la base de datos
que utiliza la aplicación. Esto sucede, por ejemplo, cuando la organización es pequeña o cuando la
aplicación web tiene un servidor de base de datos aparte sin datos críticos de negocio. Sin embargo,
en organizaciones más grandes o en proyectos donde la base de datos almacena información crítica
de negocio, puede haber un equipo de administradores de bases de datos (DBAs). Estos
administradores de base de datos generalmente cuentan con habilidades avanzadas en la
administración y diseño de base de datos y su trabajo es garantizar la integridad de los datos basados
en una política de almacenamiento de datos de la organización.
Si la base de datos del proyecto es administrada por el equipo de administradores de bases de datos,
es esencial tener una buena comunicación con ellos. Se debe consultar con los administradores de la
base de datos (DBAs) acerca de los requerimientos. Con frecuencia ellos imponen una lista técnica de
requerimientos que otros usuarios podrían no entender. A medida que se construye y despliega la
aplicación, los administradores de bases de datos son responsables de la creación de las bases de
datos en los servidores o clusters correctos y de la asignación de permisos.
Diseño de base de datos en el desarrollo ágil y Programación

Extrema
El desarrollo ágil y la programación extrema se caracterizan por una cantidad relativamente pequeña
de documentación y planificación inicial y, el conocimiento de que los requerimientos son propensos
a cambiar a lo largo del desarrollo de proyecto.
Si se está trabajando con estas metodologías de desarrollo, sólo se crearán modelos de dominio
durante la fase inicial de planificación del proyecto. No se desarrollan modelos lógicos o físicos de
datos hasta que se escriba código que implemente los requerimientos funcionales. Durante la fase de
desarrollo, se discuten los requerimientos con los usuarios y administradores de bases de datos y se
crean los modelos lógicos y físicos de datos justo antes de escribir el código.
En el desarrollo ágil y la programación extrema, el diseño de la base de datos cambia a lo largo del
proyecto hasta su despliegue. Por lo tanto, los desarrolladores deberían ser capaces de modificar la
base de datos siempre que sea necesario y sin consultar a los administradores de bases de datos o
cumpliendo con las políticas complejas de datos. Por esta razón, se debe utilizar una base de datos
separada y hospedada en un servidor dedicado de desarrollo.
En algunos casos, el proyecto de desarrollo trabaja con una base de datos que ya existe. Por ejemplo,
podemos estar desarrollando una aplicación Web que presenta y edita la información de la base de
datos de empleados de la empresa en la Intranet. En tales casos, la base de datos no cambia a
medida que se desarrolla el código, pero los requerimientos funcionales y técnicos si pueden
cambiar. Se debe copiar la base de datos a un servidor de base de datos de desarrollo aislado para
asegurarse de que el código no modifique erróneamente datos críticos de negocio.
Planificación de Aplicaciones Distribuidas

Para una pequeña aplicación Web con pocos niveles de tráfico de usuarios, se puede elegir hospedar
todos los componentes de la aplicación Web en un único servidor. Sin embargo, a medida que la
aplicación Web crece, es común utilizar un despliegue distribuido, en el cual diferentes servidores
hospedan componentes separados de la aplicación. Las aplicaciones Web distribuidas utilizan
frecuentemente una arquitectura en capas:
• Capa de presentación. Los componentes en esta capa implementan la interfaz de usuario y la

lógica de presentación. Si se está construyendo una Aplicación Web MVC, las Vistas y los
Controladores conforman la capa de presentación.
• Capa de lógica de negocio. Los componentes de esta capa implementan objetos de negocio
de alto nivel tales como Productos o Clientes. Si se está construyendo una aplicación Web
MVC, los Modelos conforman la capa de lógica de negocio.
• Capa de acceso a datos. Los componentes en esta capa implementan operaciones de acceso
a base de datos y, a partir de los objetos de negocio, abstraen los objetos de la base de datos
tales como las tablas. Por ejemplo, un objeto de negocio Producto puede incluir datos de las
tablas Productos e Inventarios de la base de datos. Si se está construyendo una Aplicación
Web MVC, los modelos frecuentemente representan ambas capas: Lógica de negocio y
Acceso a datos. Sin embargo, con un diseño y prácticas de codificación cuidadosas, es posible
refactorizar el código para separar estas capas.
• Capa de base de datos: Esta capa tiene la base de datos misma.
Si implementamos una arquitectura en capas en una aplicación Web, podremos hospedar cada capa
en servidores separados. A menudo, por ejemplo, la capa de Presentación está alojada en uno o más
servidores IIS, la capa de Lógica de negocio y la capa de Acceso a datos son alojadas en servidores
dedicados de nivel medio y la base de datos está alojada en servidores dedicados SQL Server.
Ventajas de la arquitectura N-Capas

El desarrollo de una aplicación utilizando la arquitectura n-capas tiene las siguientes ventajas:
• Es posible especificar el hardware del servidor que se adecue a cada Rol. Por ejemplo, un
servidor que aloja componentes de Lógica de negocio requiere buena memoria y recursos de
procesamiento.
• Es posible dedicar varios servidores para cada Rol para asegurar que la falla de un simple
servidor no cause una interrupción en el servicio.
• Únicamente los servidores Web deben estar en la red perimetral. Tanto los servidores de
base de datos y servidores de nivel medio pueden ser protegidos por dos firewalls sin acceso
directo desde Internet.
• Alternativamente, se pueden hospedar capas de nivel medio y bases de datos en una nube
de servicios, tales como Microsoft Azure.
Comunicación entre Capas

Cuando un solo servidor aloja todos los componentes de una aplicación Web, la Presentación, la
Lógica de negocio y los componentes de Acceso a datos, se ejecutan en un solo proceso en la
memoria del servidor Web. La comunicación entre los componentes no es un problema. Sin
embargo, al ejecutar diferentes capas sobre diferentes servidores, se deben considerar dos factores:
• ¿Cómo intercambia información y mensajes cada capa?
• ¿Cómo se autentica cada servidor y como se logra la comunicación segura con otros
servidores?
La comunicación de información y seguridad se lleva a cabo de diferentes formas entre las distintas
capas:
• Entre el navegador Web y el servidor Web de la Capa de Presentación. En cualquier
aplicación Web, la comunicación entre el navegador Web donde se ejecuta la capa de
presentación y el servidor Web se realiza a través de HTTP. Si se requiere de una
autenticación, normalmente se ejecuta mediante el intercambio de las credenciales como
texto plano. También se puede utilizar Secure Sockets Layer (SSL) para encriptar esta
comunicación sensible.
• Entre el servidor Web y el servidor de nivel medio. Los mecanismos de comunicación y
seguridad utilizados para la comunicación entre el servidor Web y el servidor de nivel medio,
dependen de la tecnología que se utilice para construir los componentes de la Lógica de
negocio:
o Servicios Web. Si se implementan los objetos de negocio y las clases de acceso a
datos como servicios Web, los componentes de la capa de presentación se
comunican con los servicios Web mediante HTTP. Se puede realizar la autenticación
mediante el protocolo Kerberos que es parte de la autenticación integrada con
Windows o mediante el uso de texto encriptado con SSL.
o Servicios Windows Communication Foundation (WCF). Si se implementan los
objetos de negocio y clases de acceso a datos como servicios WCF, se puede elegir
entre dos mecanismos de hospedaje
▪ Es posible hospedar los servicios WCF en IIS, en cuyo caso el mecanismo de
transporte es HTTP y SSL es el mecanismo de seguridad
▪ Es posible hospedar los servicios WCF dentro del Windows Process
Activation Service (WAS), en cuyo caso se puede utilizar TCP, Microsoft
Message Queuing (MSMQ) o canalizaciones con nombres (named pipes)
como mecanismo de transporte.
• Entre el servidor de nivel medio y la base de datos. El servidor de nivel medio envía
consultas T-SQL al servidor de base de datos, el cual autentica contra la base de datos
mediante el uso de las credenciales requeridas que a menudo se incluyen en la cadena de

conexión.
Planificando la Administración de Estado

En el desarrollo de aplicaciones Web, el estado de la aplicación se refiere a los valores e información
que se mantienen a través de múltiples operaciones.
El protocolo HTTP es fundamentalmente un protocolo sin estado, lo que indica que no tiene un
mecanismo para conservar información de estado a través de múltiples solicitudes de página.
Existen diversos escenarios en los cuales se requiere preservar el estado:
• Preferencias del usuario. Algunos sitios web permiten a los usuarios especificar sus
preferencias. Por ejemplo, una aplicación web para compartir fotos podría permitir a los
usuarios elegir un tamaño preferido para las fotos. Si esta información se pierde entre
solicitudes de página, los usuarios tendrían que especificar continuamente la preferencia.
• Identidad del usuario. Algunos sitios autentican a los usuarios para proveerles acceso a
contenido exclusivo solo para miembros. Si la identidad del usuario se pierde entre cada
solicitud de página, el usuario debe volver a introducir sus credenciales para cada página.
• Los carritos de compra. Si el contenido de un carrito de compras es perdido entre cada
petición de página, el cliente no podría realizar alguna compra desde la aplicación Web.
En casi todas las aplicaciones Web, el almacenamiento de estado es un requisito fundamental.

ASP.NET proporciona varios lugares donde podemos almacenar y tener acceso de forma simple a la
información del estado. Sin embargo, debemos planear el uso de estos mecanismos
cuidadosamente. Si utilizamos una dirección incorrecta, podríamos no ser capaces de recuperar el
valor cuando lo necesitemos. Además, la mala planificación de la administración de estado con
frecuencia se refleja en un bajo rendimiento.
En general, se debe tener cuidado con mantener grandes cantidades de datos de estado debido a
que, o consume la memoria del servidor si se está almacenado el estado en el servidor, o vuelve
lenta la transferencia de la página Web al navegador si el estado está incluido en la página Web. Si se
requiere almacenar valores de estado, se puede elegir entre el almacenamiento del estado en el lado
del cliente o el almacenamiento de estado del lado del servidor.
Almacenamiento de Estado del lado del Cliente

Cuando se almacena la información de estado en el lado del cliente, se asegura que no se utilizan los
recursos del servidor. Sin embargo, se debe considerar que toda la información de estado del lado
del cliente debe ser enviada entre el servidor Web y el navegador Web y este proceso puede retrasar
el tiempo de carga de la página. Se debe utilizar el almacenamiento de estado del lado del cliente
sólo para pequeñas cantidades de datos:
• Cookies. Las Cookies son pequeños archivos de texto que podemos pasar al explorador Web
para almacenar información. Una Cookie puede ser almacenada en:
o La memoria de la computadora cliente, en cuyo caso, se conserva la información sólo
para una sola sesión de usuario.
o El disco duro del cliente, en este caso se conserva información de múltiples sesiones.
La mayoría de los navegadores pueden almacenar cookies de hasta 4096 bytes y permiten
solamente 20 cookies por sitio web. Por lo tanto, las cookies, se pueden utilizar sólo para
pequeñas cantidades de datos. También algunos usuarios pueden desactivar las cookies con
propósitos privacidad, por lo que no se debe depender de las cookies para funciones críticas.
• Cadenas de consulta (Query Strings). Una cadena de consulta es la parte de la URL después
del signo de interrogación y se utiliza a menudo para comunicar valores de formulario y otros
datos al servidor. Se puede utilizar la cadena de consulta para preservar una pequeña
cantidad de datos de una petición de una página a otra. Todos los navegadores admiten
cadenas de consulta, pero algunos navegadores imponen un límite de 2,083 caracteres de la
longitud de la URL. No se debe colocar ninguna información sensible en la cadena de
consulta ya que es visible para el usuario, para cualquier persona que esté observando la
sesión o para cualquier persona que este monitoreando el tráfico Web.
En las aplicaciones ASP.NET Web Forms, el View State, Control State y los campos ocultos pueden ser
utilizados para almacenar la información de estado en el HTML generado que el servidor envía al
cliente. Estos mecanismos no están disponibles en las aplicaciones Web MVC ya que estas no utilizan
controles Web Forms.
Almacenamiento de estado del lado del Servidor

La información de estado que se almacena en el servidor consume recursos del servidor, por lo que
se debe tener cuidado del uso excesivo del almacenamiento de estado del lado del servidor ya que se
corre el riesgo de un bajo rendimiento.
Las siguientes ubicaciones almacenan la información de estado en la memoria del servidor:

• TempData. Esta es una ubicación para almacenamiento de estado que se puede utilizar en
aplicaciones MVC para almacenar valores entre una petición y otra. Los valores pueden ser
almacenados agregándolos a la colección TempData. Esta información se conserva
únicamente para una sola solicitud y está diseñada para ayudar a mantener los datos a través
de una redirección de una página Web. Por ejemplo, se puede utilizar para transmitir un
mensaje de error a una página de error.
• Estado de la aplicación. Esta es una ubicación para almacenamiento de estado que se puede
utilizar para almacenar valores que pueden ser mantenidos durante todo el ciclo de vida de
la aplicación. Los valores almacenados en el estado de aplicación son compartidos por todos
los usuarios. Se puede almacenar valores agregándolos a la colección Application. Si el
servidor Web o la aplicación es reiniciada, los valores son destruidos. El procedimiento
Application_Start() ubicado en el archivo Global.asax es un lugar apropiado para inicializar
los valores del estado de la aplicación. El estado de aplicación no es un lugar adecuado para
almacenar valores específicos del usuario, tal como las preferencias, ya que, si se almacena
una preferencia en el estado de la aplicación, todos los usuarios comparten la misma
preferencia en vez de tener su propio valor único.
• Estado de la sesión. La Colección Session almacena información durante todo el ciclo de vida
de una sesión del navegador y los valores almacenados ahí son específicos a una sesión única
de usuario y no pueden ser accedidos por otros usuarios. De manera predeterminada, si se
reinicia el servidor Web o la aplicación Web los valores son destruidos. Sin embargo, se
puede configurar ASP.NET para almacenar el estado de sesión en una base de datos o un
servidor de estados. Si se hace esto, es posible preservar el estado de sesión a través de
reinicios del servidor. El estado de sesión está disponible tanto para los usuarios
autenticados como para los usuarios anónimos. De forma predeterminada, el estado de
sesión utiliza cookies para identificar usuarios, pero se puede configurar ASP.NET para
almacenar el estado de sesión sin utilizar cookies.
Si decidimos utilizar estas ubicaciones de memoria del servidor, debemos asegurarnos de

estimar el volumen total de datos de estado que puede ser requerido para todos los usuarios
concurrentes que esperamos tener. Los valores de estado de la aplicación se almacenan sólo
una vez, pero los valores de estado de sesión se almacenan una vez por cada usuario
concurrente.
Cuando almacenamos los datos de estado en la memoria del servidor, debemos especificar el
hardware de servidor que pueda manejar fácilmente esta carga, o bien, mover los datos de
estado en las siguientes ubicaciones basadas en el disco duro del servidor:
o Propiedades del Perfil. Si el sitio utiliza un proveedor de perfiles ASP.NET, se pueden
almacenar las preferencias del usuario en Perfiles. Las Propiedades del Perfil se
almacenan en la base de datos de membresía de tal forma que serán mantenidos,
aunque se reinicie la aplicación Web o el servidor Web.
o Tablas de base de datos. Si el sitio utiliza una base de datos subyacente, tal y como
lo hacen la mayoría de los sitios, entonces puede almacenarse la información de
estado en sus Tablas. Este es un buen lugar para almacenar grandes volúmenes de
datos de estado que no pueden ser colocados en la memoria del servidor o en el
equipo del cliente. Por ejemplo, si deseamos almacenar un gran volumen de
información de estado específica de la sesión, podemos almacenar simplemente el
valor del ID en la colección Session y utilizarlo para consultar y actualizar un registro
en la base de datos.
Recordemos que los datos del estado son sólo una pieza de información que una aplicación ASP.NET
coloca en la memoria del servidor. Por ejemplo, la memoria caché debe compartir memoria con los
datos de estado.
Planificando la Globalización y Localización

Internet es una red internacional y a menos que estemos seguros de que los usuarios de la aplicación
Web hablan un solo idioma, debemos asegurarnos de que todo el mundo pueda leer el contenido de
la aplicación Web. Se limita la audiencia potencial del sitio si se generan únicamente páginas en un
solo idioma. El proceso por el cual se hace que una aplicación Web esté disponible en múltiples
idiomas se llama Globalización o Internacionalización. El proceso por el cual se hace una página Web
disponible en un lenguaje y cultura específica se llama localización.
Manejo de Navegadores Web para Idiomas y Regiones

Hay un conjunto de códigos de lenguajes reconocidos internacionalmente que especifican una
cultura en Internet. Esos códigos se componen de dos partes:
1. El lenguaje. Por ejemplo, el inglés es "en", el ruso es "ru", el español es “es”.
2. La región. Especifica las variaciones regionales dentro de un lenguaje y afecta a la ortografía
y los formatos. Por ejemplo, en el inglés de Estados Unidos, "Globalize" con “Z” es correcto y
las fechas se escriben en formato mm/dd/aa, mientras que en inglés británico, "Globalise"
con “S” es correcto y las fechas se escriben en formato dd/mm/aa.
El código completo de idioma y región para el Inglés de Estados Unidos es "en-US", el código
completo de idioma y región para el inglés británico es "en-UK" y el código completo de idioma y
región para el español de México es “es-MX”.
El idioma preferido que los usuarios elijen está disponible como el código del idioma en la cabecera
HTTP del navegador del usuario. Este es el valor al que se responde para globalizar el sitio.
Alternativamente, se puede proporcionar un control, tal como una lista desplegable en el que los
usuarios pueden elegir su idioma preferido. Este es un buen ejemplo de una preferencia de usuario
que se puede almacenar en el estado de sesión.
Uso de archivos de recursos

Cuando el usuario especifica un idioma y región preferidos, debemos responder generando páginas
para esa cultura. Un método para proporcionar una respuesta localizada es utilizar archivos de
recursos para insertar texto en el lenguaje apropiado dentro de la página en tiempo de ejecución.
Un archivo de recursos es un simple diccionario de términos en un idioma determinado. Para cada

término en el archivo, debemos especificar un nombre, un valor y opcionalmente un comentario. El
archivo tiene una extensión resx. El nombre del archivo también incluye el código de idioma al cual el
recurso aplica. Por ejemplo, si creamos un archivo de recursos para una Vista llamada Index el cual
almacena los valores en el español de Mexico, el nombre del archivo debe ser Index.es-MX.resx.
Los archivos de recursos también pueden tener una cultura neutra. Esto significa que el archivo
aplica a cualquier región en un determinado idioma. Por ejemplo, el archivo Index.es.resx aplica a los
términos en español, independientemente del código regional que haya sido elegido.
También se deben crear los archivos de recursos predeterminados correspondientes, sin ningún
código de lenguaje en el nombre del archivo, tal como Index.resx. Estos archivos son utilizados
cuando no se especifica el idioma preferido.
Cuando utilicemos archivos de recursos para localizar un sitio, cada Vista aplica sin importar el
idioma preferido. Debemos insertar código Razor extra en la vista para tomar los valores de texto
desde un archivo de recursos. Esto puede reducir la legibilidad de los archivos de vista porque todo el
texto generado proviene de archivos de recursos. Sin embargo, es más fácil soportar a nuevos
lenguajes ya que sólo se tiene que añadir un nuevo archivo de recurso para cada idioma que puede
ser creado por un traductor profesional.
Utilizando Vistas separadas

Algunos desarrolladores prefieren utilizar conjuntos de vistas separadas y paralelas para cada código
de idioma soportado. Si se utiliza este enfoque, se debe insertar código en los controladores para
detectar el idioma preferido que el usuario ha especificado. Después de esto, se puede utilizar este
valor para generar la vista correcta.
Al utilizar vistas separadas para globalizar y localizar un sitio, las Vistas son más legibles porque la
mayoría del texto y las etiquetas permanecen en el archivo de la Vista. Sin embargo, se deben crear
archivos de Vista, los cuales requieren que los miembros del equipo sean competentes en el idioma
destino.
Lección 2
Diseñando Modelos, Controladores y Vistas
Los Modelos, Controladores y Vistas son los bloques fundamentales para construir aplicaciones Web
MVC. En un sitio complejo, pueden existir cientos de Modelos, Vistas y Controladores. Nosotros
necesitamos administrar esos objetos y hacer una buena planificación de nuestra aplicación para
poder administrar fácilmente la organización y la estructura interna durante el desarrollo. Un plan
minucioso asegurará que podamos detectar cualquier código incorrecto y podamos depurar
problemas rápidamente.
• Describir como diseñar Modelos.
• Describir como diseñar Controladores.
• Describir como diseñar Vistas.
Diseñando Modelos
Una actividad fundamental en el proceso de diseño MVC es el diseño de un Modelo. Cada clase
Modelo dentro del Modelo representa un tipo de Objeto que la aplicación utiliza.
No se pueden planificar los Controladores y las Vistas hasta que se entienda la estructura y el diseño
del Modelo.
Los casos de uso, escenarios de uso o historias de usuario que se realizaron durante la fase de
análisis del proyecto, deben permitir determinar las clases Modelo que se necesitan crear. Cada clase
Modelo tiene una serie de propiedades, por ejemplo, consideremos el ejemplo de caso de uso visto
anteriormente:
1. El usuario da clic en el enlace “Agregar foto” del menú principal del sitio.
2. Si el usuario es anónimo, se muestra la página de inicio de sesión y el usuario proporciona
sus credenciales.
3. Si las credenciales son correctas, se muestra la vista “Agregar foto”
4. El usuario escribe un Título.
5. El usuario especifica el archivo de la foto a subir.
6. El usuario escribe opcionalmente una descripción de la foto.
7. El usuario da clic en el botón “Enviar”
8. La aplicación Web almacena la nueva foto y muestra la galería de fotos al usuario.
El ejemplo que acabamos de ver incluye los siguientes objetos, cada uno de los cuales requiere una
clase Modelo:
• Usuario: La clase Modelo Usuario debe incluir propiedades para almacenar las credenciales,
tal como el nombre de usuario y la contraseña.
• Foto: La clase modelo Foto debe incluir las propiedades Descripción y Título.
Otros casos de uso similares ayudan a agregar nuevas clases Modelo o nuevas propiedades a las
clases Modelo Usuario y Foto.
Diagramas Modelo de dominio y Modelo de datos lógico

Podemos utilizar diagramas de Modelo de dominio y diagramas de Modelo de datos lógico (LDM)
para analizar la información que un sitio Web maneja y sugerir un modelo de datos físico o un diseño
de base de datos.
Podemos regresar a esos diagramas para planificar las clases Modelo. Cada objeto en el Modelo de
dominio o Modelo de datos lógico puede ser implementado como una clase del modelo MVC. El
diagrama de Modelo de dominio incluye los nombres de estas clases y el diagrama de datos lógico
incluye los nombres de las propiedades y los tipos de datos.
Al identificar las clases del Modelo que implementaremos en el sitio Web, también debemos
considerar las relaciones entre ellas. Por ejemplo, en el caso de uso de la aplicación “Compartir
Fotos”, si cada Foto estuviera asociada con un Usuario y un Usuario solo pudiera subir una foto,
tendríamos una relación Uno a Uno.
Si cada usuario, sin embargo, pudiera crear múltiples fotos. Tendríamos entonces una relación uno-a-
muchos.
Los Diagramas de Modelo de dominio y los diagramas de Modelo de datos lógico, incluyen tales
relaciones como enlaces entre los objetos.
Los números al final de cada enlace muestran cuando la relación es uno a uno, uno-a-muchos o
muchos-a-muchos.
Los agregados añaden más límites en el comportamiento de las clases Modelo y clarifican las
relaciones. Por ejemplo, en una aplicación para compartir fotos, una foto es creada por un usuario
único, pero un usuario puede haber creado varias fotos.
Otros usuarios pueden hacer múltiples comentarios en cada foto. Si un usuario elimina una foto,
todos los comentarios sobre esa foto también deben ser eliminadas de la base de datos. Sin
embargo, el usuario que creó la foto no debe ser eliminado junto con la foto porque podría crear
otras fotos o comentarios en el sitio. En este caso, los Comentarios y Fotos deben ser colocados en
un agregado, pero los usuarios deben estar fuera de los agregados. La foto es la "entidad raíz" del
agregado lo que significa que, al borrar una foto, se eliminan todos los comentarios asociados, pero
al borrar un comentario no se borra la foto asociada.
Entity Framework
Entity Framework es un Framework de Mapeo Relacional de Objetos (ORM) para aplicaciones
basadas en el .NET Framework. Un Framework ORM, mapea las tablas y las vistas de la base de datos
en clases que un desarrollador puede programar a través de la creación de instancias o llamadas de
métodos.
Entity Framework ha sido parte de ADO.NET desde el .NET Framework 3.5. Cuando se utiliza el Entity
Framework en una aplicación Web MVC, este mapea las tablas y vistas a las clases Modelo que se
han planeado.
No es necesario escribir código SQL para consultar o actualizar las tablas de bases de datos porque el
Entity Framework lo hace por el desarrollador.
Entity Framework se integra muy bien con el lenguaje de consulta LINQ -Language Integrated Query.
Si se planea utilizar Entity Framework para el acceso de datos, durante la fase de planificación se
debe decidir cómo va a ser la creación de la base de datos.
• Database-First. Podemos usar Entity Framework con el enfoque “Primero la base de datos”
cuando se tiene una base de datos ya existente para trabajar con ella. Esto puede ocurrir
cuando ya se tengan los datos de un sistema anterior o porque un DBA ha diseñado la base
de datos por nosotros. Se puede elegir también este modo si se está familiarizado con la
creación de bases de datos en una herramienta de administración de base de datos como
Microsoft SQL Server Management Studio. Al utilizar este modo, se debe especificar la
cadena de conexión de la base de datos. Entity Framework se conecta a la base de datos y
examina el esquema (schema) y crea un conjunto de clases que se pueden utilizar para el
acceso a datos.
• Model-First. Podemos utilizar Entity Framework en el modo “Primero el Modelo” cuando no
se tiene una base de datos preexistente y se prefiere diseñar el Modelo en Visual Studio.
Podemos utilizar la herramienta Entity Designer para nombrar, configurar y vincular las
clases del Modelo. Esto crea archivos XML que el Entity Framework utiliza tanto para crear
las clases del Modelo como para la creación de las bases de datos con sus tablas y sus
relaciones.
• Code-First. Podemos utilizar Entity Framework en el modo “Primero el código” cuando no se
tiene una base de datos preexistente y se prefiere diseñar los modelos totalmente en código
C#. El código debe incluir objetos DbContext y DbSet que corresponden a la base de datos y
sus tablas. Cuando se ejecuta la aplicación por primera vez, Entity Framework crea la base de
datos por nosotros.
Diseño en Proyectos Ágiles y Programación extrema

Los proyectos Ágiles y de Programación Extrema se caracterizan por fases cortas de diseño en las
cuales los Modelos de datos no son completados. En su lugar, un diseño simple, con pocos detalles,
es creado y los desarrolladores van llenando los detalles a medida que construyen el código
mediante discusiones continuas de los requerimientos con los usuarios y otras partes interesadas
(stakeholders).
En un proyecto MVC, esto significa que se identifican los nombres y relaciones de los Modelos
durante la fase de diseño. Se puede registrar esto en un diagrama UML de Modelo de Dominio. Sin
embargo, se pueden dejar detalles tales como nombres de propiedades y tipos de datos para ser
finalizados en la fase de desarrollo, junto con los diagramas completos de Modelo de Datos Lógico.
Entity Framework permite trabajar con los estilos Ágiles o de Programación Extrema. Por ejemplo, el
Framework puede actualizar la base de datos cuando el Modelo cambie. Alternativamente, el
Framework puede actualizar el Modelo cuando la base de datos cambie. El Entity Framework puede
realizar estas actualizaciones en cualquier modo o enfoque en que se esté utilizando ya sea
Database-First, Model-First o Code-First.
Diseñando Controladores
En una aplicación Web ASP.NET MVC, los Controladores son clases que heredan de la clase base
System.Web.Mvc.Controller.
Ellos implementan la lógica de entrada. Esto significa que ellos reciben la entrada del usuario en la
forma de peticiones HTTP y seleccionan tanto el Modelo correcto como la Vista a utilizar para
generar una respuesta.
Identificar los Controladores y las Acciones

En una aplicación Web ASP.NET MVC, usualmente hay un Controlador para cada clase Modelo.
Convencionalmente, si la clase Modelo es llamada "Photo", el controlador es llamado
"PhotoController".
Si seguimos esta convención en nuestro diseño, podemos utilizar el comportamiento de

enrutamiento predeterminado en MVC para seleccionar el Controlador adecuado para una solicitud.
Sin embargo, para cada Controlador pueden existir varias acciones, cada acción es implementada
como un método en el Controlador y generalmente devuelve una Vista. A menudo requerimos
acciones separadas para los verbos GET y POST de las solicitudes HTTP. De manera similar al diseño
de un Modelo, podemos identificar las acciones a escribir en cada Controlador examinando los casos
de uso registrados durante el análisis.
Consideremos el caso de uso que vimos anteriormente. Ya hemos identificado las clases Modelo Foto
y Usuario de este caso de uso. Adhiriéndose a la Convención MVC, debemos crear los controladores
PhotoController y UserController.
El caso de uso muestra que se necesitan las siguientes acciones para cada controlador:
• Controlador Foto (PhotoController)

o AgregarFoto (GET). La acción AgregarFoto para la solicitud GET, crea una nueva
instancia de la clase Modelo Foto, establece los valores predeterminados tal como la
fecha de creación y los pasa a la Vista correcta.
o AgregarFoto (POST). La acción AgregarFoto para la solicitud POST, invoca a los
métodos de la clase Modelo Foto para guardar los valores de la foto en la base de
datos y redirige el navegador a la acción MostrarGaleria.
o MostrarGaleria (GET). La acción MostrarGaleria para la solicitud GET, muestra todas
las fotos almacenadas en la base de datos.
• Controlador Usuario (UserController)
o IniciarSesion (GET). La acción IniciarSesion para las solicitudes GET muestra una
Vista en la que un usuario anónimo puede proporcionar sus credenciales.
o IniciarSesión (POST). La acción IniciarSesion para las solicitudes POST, verifica las
credenciales de usuario contra la base de datos de membresía. Si las credenciales
son correctas, la acción IniciarSesion autentica al usuario y lo redirige hacia la página
solicitada originalmente.

Al igual que en el diseño de Modelos, sólo se hacen planes generalizados de los Controladores
durante la fase de diseño de un proyecto de desarrollo ágil o de programación extrema.
Debido a que se han identificado las clases Modelo necesarias, se pueden planificar los
Controladores necesarios. Sin embargo, se deben especificar solamente unas pocas acciones en esta
etapa.
Diseñando Vistas
La interfaz de usuario es un componente vital de cualquier sistema ya que es la parte que los
usuarios, los responsables del presupuesto y otras partes interesadas ven e interactúan con ella. Los
usuarios se interesan más en que esta parte de la aplicación funcione de forma correcta y con
frecuencia tienen mucho que opinar acerca de su diseño. Como desarrollador, se tiene la
oportunidad de impresionar a los usuarios a través del diseño e implementación de una interfaz de
usuario sofisticada, lo que puede resultar en más usuarios interesados en adquirir la aplicación.
En una aplicación Web ASP.NET MVC, la interfaz de usuario es creada mediante la construcción de
Vistas.
Vistas, Plantilla de Vistas y Vistas Parciales

Existe una relación uno-a-muchos entre los controladores MVC y las Vistas. Por ejemplo, un
Controlador puede utilizar una Vista para mostrar una sola foto, otra Vista para mostrar varias fotos y
una tercera Vista para permitir a los usuarios subir nuevas fotos.
Cada vista corresponde con una página Web que la aplicación puede mostrar al usuario, aunque
puede mostrar datos diferentes. Por ejemplo, la vista PhotoDetails puede mostrar diferentes fotos
dependiendo del parámetro ID que se le pase a la misma.
Al planear las Vistas, también se deben considerar partes de la interfaz de usuario que aparecen en
todas las páginas. Por ejemplo, el logotipo de la empresa, el menú principal del sitio, los enlaces a
información legal y los controles de inicio de sesión son elementos que podría necesitarse tener en
todas las páginas. Se pueden colocar estos componentes de la interfaz de usuario en una plantilla de
Vista para crear una apariencia consistente en todas las páginas. La plantilla de Vistas en las
aplicaciones Web ASP.NET MVC tiene el mismo papel que la Página Maestra en Aplicaciones Web
Forms ASP.NET.
Algunos componentes de la interfaz de usuario no aparecen en todas las páginas, pero son
reutilizados en diversas páginas. Por ejemplo, los comentarios pueden ser mostrados en una página
que muestra el detalle de una foto, en una página que muestre la galería de fotos o en otras páginas.
Al crear una Vista Parcial, se puede crear un elemento de interfaz de usuario reutilizable que puede
aparecer en varios lugares sin duplicar código.
Creando Diagramas Wireframe

Una técnica común para discutir y planificar la interfaz de usuario de la aplicación es la creación de
diagramas Wireframe. Estos diagramas son diseños simplificados que muestran el lugar en las
páginas finales donde aparecerán los elementos.
Los diagramas Wireframe tienen la finalidad de comunicar a los usuarios las partes funcionales
esenciales de la interfaz de usuario, pero no incluyen gráficos, logotipos o colores. No es necesario
crear un modelo Wireframe para cada Vista en una aplicación, sino sólo para las más importantes.
Se puede comenzar un diagrama Wireframe dibujándolo en un pizarrón durante una conversación

con un usuario.
Existen muchas herramientas disponibles para crear versiones más formales, por ejemplo, Microsoft
Visio tiene excelentes capacidades para la creación de Diagramas Wireframe.

No se diseñan muchas partes de la interfaz de usuario durante las fases iniciales de proyectos de
desarrollo ágil o de Programación Extrema. En lugar de eso, se diseñan Vistas y Vistas parciales en
consulta estrecha con los usuarios durante la fase de desarrollo. Esto se aplica incluso a la plantilla de
Vista que muestra componentes comunes de la interfaz de usuario, aunque es probable que la
plantilla de Vista sea uno de los primeros componentes de la interfaz de usuario que se diseña y se
crea.
La Plantilla de Vista se crea durante las primeras iteraciones de la fase de desarrollo del proyecto.
Programador Jr. de
MVC
Modulo 3: Desarrollando Modelos
ASP.NET MVC
Acerca del módulo

La mayoría de las aplicaciones Web necesitan interactuar con diferentes tipos de datos u objetos.
Una aplicación de comercio electrónico, por ejemplo, maneja productos, carritos de compra, clientes
y pedidos. Una aplicación de red social puede administrar usuarios, actualizaciones de estado,
comentarios, fotos y vídeos. Un blog gestiona las entradas del blog, comentarios, categorías y
etiquetas. Cuando se escribe una aplicación Web MVC, se crea un Modelo MVC para modelar los
datos de la aplicación Web. Dentro de ese Modelo, se crea una clase Modelo para cada tipo de
objeto. La clase Modelo describe las propiedades de cada tipo de objeto y puede incluir lógica de
negocio que coincide con los procesos del negocio. Por lo tanto, el Modelo es un bloque de
construcción fundamental en una aplicación MVC y un buen lugar para empezar cuando escribimos
código. Los Modelos interactúan con el almacén de información que proporciona soporte al sitio y
que por lo general es una base de datos. Por lo tanto, es necesario comprender las técnicas y las
tecnologías de acceso a datos para escribir Modelos.
En este módulo, veremos cómo crear el código para los Modelos y el acceso a datos mediante el uso
de Entity Framework y LINQ.
Objetivos
• Agregar un Modelo a una aplicación MVC y escribir código en el Modelo para implementar la
lógica de negocio.
• Crear una nueva base de datos en Microsoft Azure SQL Database para almacenar datos para
una aplicación Web.
• Lección 1: Creando Modelos MVC.
• Lección 2: Trabajando con datos.
Lección 1
Creando Modelos MVC
Un Modelo MVC es una colección de clases del .NET Framework. Cuando creamos una clase Modelo,
definimos las propiedades y métodos de acuerdo con el tipo de objeto que la clase Modelo describe.
Podemos describir estas propiedades en el código para que MVC pueda determinar cómo
visualizarlas en una página Web y cómo validar la entrada de usuario. Es necesario conocer cómo
crear y describir Modelos y cómo modificar la manera en que MVC crea instancias de la clase Modelo
cuando ejecuta la aplicación Web.
Al finalizar esta lección, los participantes serán capaces de:
• Describir la forma de crear Modelos MVC y desarrollar la lógica de negocios.

• Utilizar anotaciones de datos de muestra y edición asignando atributos a Vistas y
Controladores.
• Validar la entrada de usuario con anotaciones de datos.
• Describir los Enlazadores de Modelo.
• Describir la extensibilidad del Modelo.
• Agregar un Modelo a una aplicación Web MVC.
Desarrollo de Modelos
Cada sitio Web presenta información sobre diversos tipos de objetos. En nuestras aplicaciones Web,
necesitamos definir clases Modelo para esos objetos.
Cuando se implementa un requisito funcional en la aplicación Web, por lo general empezamos con la
creación de una clase Modelo. La clase Modelo probablemente será revisada cuando se cree el
Controlador y las Vistas para el Modelo, y luego, más tarde, durante las iteraciones que ocurran en el
proyecto.
Si se sigue el modelo de desarrollo Ágil o Programación Extrema, se empieza con un entendimiento

simple de la clase, tal vez su nombre y algunas propiedades, esto es, se empieza por crear el Modelo
de dominio también conocido como Modelo Conceptual de Datos.
La siguiente imagen muestra un Modelo Conceptual de Datos de una aplicación Almacén que
manejará Productos y donde cada producto estará clasificado por Categorías.
Después de crear el diagrama del Modelo Conceptual de Datos, lo conversamos con los usuarios y
agregamos detalles a la clase Modelo planeado con el conjunto completo de propiedades, sus tipos y
sus relaciones con otras clases.
Cuando se desarrolla el Modelo, se puede hacer referencia a los Casos de Uso o Historias de Usuario
para asegurarse de que esos detalles del Modelo sean correctos.
La siguiente imagen muestra el Modelo Conceptual de Datos anterior con más detalle.
Cuando sentimos que hemos entendido completamente los requerimientos para un Modelo,
podemos escribir el código de las clases Modelo para implementar los requerimientos.
El siguiente ejemplo, muestra el código de la clase Modelo Categoria.
public class Categoria

{
public int ID { get; set; }
public string Nombre { get; set; }
public virtual string Descripcion { get; set; }
public virtual IEnumerable<Producto> Productos { get; set; }
}
Notemos que la clase Categoria no hereda de ninguna otra clase. Además, se han creado
propiedades públicas en el Modelo. Las propiedades son de lectura y escritura pero igualmente
podríamos incluir únicamente propiedades de sólo lectura.
La clase Categoria incluye una propiedad llamada Productos. Esta es declarada como una colección
de objetos Producto e implementa uno de los lados de la relación entre las Categorías y los
Productos.
El siguiente ejemplo muestra la implementación de la clase Producto.
public class Producto

{
public int IDCategoria { get; set; }
public decimal Precio { get; set; }
public decimal Existencia { get; set; }
public DateTime UltimoMovimiento { get; set; }
public virtual Categoria Categoria { get; set; }
}
Notemos que la clase Producto incluye una propiedad IDCategoria. Esta propiedad almacena el
identificador (ID) de la categoría a la que pertenece el producto y vincula el producto a una sola
categoría. Notemos también que la clase Producto incluye una propiedad Categoria, que devuelve el
objeto Categoria a la que el Producto está clasificado. Estas propiedades implementan el otro lado
de la relación entre Categorías y Productos.
Las instancias de las clases Modelo se crean generalmente en una acción del Controlador y se pasan
a una Vista para ser mostradas.
El siguiente ejemplo muestra como un método de acción de un Controlador puede crear un nuevo
objeto Categoria a partir de la clase Modelo Categoria y pasárselo a la Vista para que lo muestre.

{
Models.Categoria c = new Models.Categoria
{
ID = 1,
Nombre = "Bebidas",
Descripcion = "Categoría de productos líquidos"
};
return View(c);
}
En la Vista Index, se puede mostrar la propiedad Nombre de una Categoria utilizando el objeto
Model en el código Razor que escribimos de la siguiente manera.
<div>
@Model.Nombre
</div>
Uso de Anotaciones de Datos de Visualización y Edición sobre las

propiedades
Usualmente, las clases Modelo especifican tres atributos para cada propiedad:
• El nombre de la propiedad, por ejemplo, UltimoMovimiento.

• El tipo de dato de la propiedad, por ejemplo, DateTime.
• Los niveles de acceso de la propiedad, por ejemplo, las palabras claves set y get para
indicar acceso de lectura y escritura.
Adicionalmente mediante el uso de atributos, podemos proporcionar metadatos adicionales para

describir las propiedades para ASP.NET MVC. El runtime de MVC utiliza esta metadata para
determinar cómo representar cada propiedad en las Vistas para su visualización y edición. Estos
atributos son llamados Anotaciones de Visualización y Edición.
Por ejemplo, los nombres de propiedades en C# no pueden contener espacios, esto es, no podemos
tener una propiedad llamada “Fecha de último movimiento”. En la visualización de una página Web,
podríamos querer incluir espacios en la etiqueta de una propiedad. Por ejemplo, podríamos querer
mostrar una propiedad llamada UltimoMovimiento con la etiqueta “Fecha de último movimiento”.
Para proporcionarle a MVC esta información, podemos utilizar la anotación DisplayName como se
muestra en el siguiente ejemplo.
[DisplayName("Fecha de último movimiento")]
Si tenemos una propiedad DateTime, podemos utilizar las anotaciones de datos de visualización y
edición para informar a MVC el formato que deseamos utilizar para visualizar la propiedad.
El siguiente ejemplo muestra el uso del atributo DisplayFormat para indicar a MVC que sólo los
valores día, mes y año deben ser mostrados.

[DisplayFormat(DataFormatString = "{0:dd/MM/yy}",
ApplyFormatInEditMode = true)]
El parámetro DataFormatString indica el formato a aplicar y el parámetro ApplyFormatInEditMode

indica si el formato es aplicado al valor del campo cuando se encuentre en modo edición.
Podemos también indicar a MVC el tipo de datos que almacena la propiedad tal y como se muestra
en el siguiente ejemplo.

[DisplayFormat(DataFormatString = "{0:dd/MM/yy}",
ApplyFormatInEditMode = true)]
[DataType(
System.ComponentModel.DataAnnotations.DataType.DateTime)]
Validando la entrada de usuario con Anotaciones de Datos

Podemos utilizar anotaciones de datos en Modelos MVC para establecer criterios de validación para
la entrada de datos del usuario. La validación de entrada es el proceso por el cual MVC comprueba
los datos proporcionados por un usuario o una petición Web para asegurar que están en el formato
correcto.
Podemos tener por ejemplo una clase Modelo llamada Persona con las siguientes propiedades.
public class Persona

{
// Una propiedad que sea requerida
// Una propiedad que debe ser de 5 caracteres
public string CodigoPostal { get; set; }
// Una propiedad que indique el porcentaje de dominio del idioma ingles
// que debe ser del 0 al 100%
public byte DominioIngles { get; set; }
// Una dirección de correo que sea requerida y que además sea válida
public string Correo { get; set; }
}
Cuando un usuario proporcione los datos de una persona, queremos que MVC cree una nueva
instancia del Modelo Persona y la utilice para almacenar los datos hacia la base de datos. Sin
embargo, queremos asegurar que los datos sean válidos antes de que sean almacenados.
Para asegurarnos que los datos sean válidos, podemos definir la clase modelo Persona utilizando las
siguientes anotaciones de datos de validación:

{
[Required]
[StringLength(5, MinimumLength=5)]
[Range(0,100)]
[Required]
[RegularExpression(@".+\@.+\..+")]
}
Las anotaciones Required, Range, StringLength y RegularExpression implementan validación de

entrada en MVC. Si los usuarios no proporcionan datos que cumplan los criterios especificados para
cada propiedad, la Vista muestra un mensaje de error estándar que solicita al usuario introducir los
datos correctos.
Para especificar el mensaje de error que el usuario deba ver cuando los datos no sean válidos,
podemos utilizar la propiedad ErrorMessage en la anotación de datos de validación como se muestra
en el siguiente ejemplo.

{
[Required(ErrorMessage="Debe proporcionar un nombre")]
[StringLength(5, MinimumLength=5,
ErrorMessage="El código postal debe ser de 5 caracteres")]
[Range(0,100,
ErrorMessage="El porcentaje debe ser de 0 a 100%")]
[Required(ErrorMessage="El correo es requerido")]
[RegularExpression(@".+\@.+\..+",
ErrorMessage="La dirección de correo debe ser válida")]
}
¿Qué son los Enlazadores de Modelo (Model Binders)?

Un Enlazador de Modelo (Model Binder), es un componente de una aplicación ASP.NET MVC que
crea una instancia de una clase Modelo basado en los datos enviados en la petición desde el
navegador Web.
ASP.NET MVC incluye un Enlazador de Modelo predeterminado que cumple con las necesidades de la
mayoría de las aplicaciones Web. Sin embargo, debemos conocer cómo trabaja el Enlazador de
Modelo predeterminado con otros componentes para utilizarlo correctamente. Además, podríamos
elegir crear un Enlazador de Modelo personalizado para situaciones avanzadas.
¿Qué hace un Enlazador de modelo?

Un enlazador de modelo asegura que los datos correctos recibidos de una petición Web sean
enviados a los parámetros correctos de un método de acción de un Controlador. Esto permite a MVC
crear instancias de las clases Modelo que satisfagan la petición del usuario.
Supongamos que tenemos una página Web que solicita los datos de una Persona, el usuario
proporciona los datos y procede a enviar la información al servidor.
Una vez que el usuario selecciona el botón “Enviar”, los datos son enviados de regreso hacia el
servidor como una solicitud (Request) Web.
Del lado del servidor, en nuestro ejemplo, los datos se encuentran disponibles a través del objeto
Request.Form. En algunos otros casos, los datos pueden pasarse a través del URL y en el servidor los
obtenemos a través del objeto Request.QueryString.
El Enlazador de Modelo predeterminado, examina tanto la definición de los parámetros del método
de acción del Controlador como los parámetros de la petición Web para determinar que valores de la
petición Web deben pasarse a que parámetros del método de acción del Controlador.
En nuestro ejemplo, el Enlazador de Modelo, crea una instancia de la clase Persona y asigna los
valores de los parámetros de la petición Web hacia las propiedades correspondientes del objeto
Persona. El método de acción finalmente recibe un parámetro de tipo Persona con el valor de la
instancia creada por el Enlazador de Modelo.
Este proceso de enlace del Modelo puede ahorrar a los desarrolladores una gran cantidad de tiempo
y evitar muchos errores inesperados en tiempo de ejecución que surgen de parámetros incorrectos.
MVC incluye un Enlazador de Modelo predeterminado con lógica sofisticada que pasa parámetros
correctamente en casi todos los casos sin la necesidad de escribir código personalizado complejo.
Invocador de Acción del controlador

Para entender el proceso del Enlazador de Modelo predeterminado, consideremos la siguiente

petición de un navegador Web:
http://www.adventureworks.com/product/display/45
Esta solicitud identifica tres aspectos:
1. La clase Modelo que le interesa al usuario. En este caso, el usuario ha solicitado un producto
(product).
2. La operación que realizar sobre la clase Modelo. En este caso, el usuario ha solicitado que el
producto sea mostrado (display).
3. La instancia específica de la clase Modelo. En este caso, el usuario ha solicitado que el
producto con el ID 45 sea mostrado.
La solicitud es recibida por un objeto llamado Invocador de Acción del Controlador (Controller
Action Invoker). El Invocador de Acción del Controlador del runtime de MVC invoca a un método de
acción del controlador y le pasa los parámetros correctos. En el ejemplo, el invocador de acción
invoca a la acción Display del controlador Product y pasa el ID "45" como un parámetro al método de
acción para que el producto correcto sea mostrado.
La clase ControllerActionInvoker es el invocador de acción predeterminado. Este invocador de

acción utiliza los enlazadores de Modelo para determinar la forma en que serán pasados los
parámetros a las acciones.
¿Cómo pasa parámetros el Enlazador de Modelo predeterminado?

En una aplicación MVC predeterminada, existe un Enlazador de Modelo que puede ser utilizado por
el ControllerActionInvoker. Este Enlazador es una instancia de la clase DefaultModelBinder.
El Enlazador de Modelo predeterminado pasa los parámetros utilizando la siguiente lógica:
1. El enlazador examina la definición del método de acción al que debe proporcionar los
parámetros. En nuestro ejemplo, el enlazador determina que la acción requiere un
parámetro entero llamado ID.
2. El enlazador busca valores en la petición Web que se puedan pasar como parámetros. En
nuestro ejemplo, el enlazador busca números enteros porque el método de acción requiere
un número entero. El enlazador busca valores en las siguientes ubicaciones y orden:
1. Valores del formulario. Si el usuario llena un formulario y hace clic en un botón de

Enviar, podemos encontrar los parámetros en la colección Request.Form.
2. Valores de la ruta. Dependiendo de las rutas que hayamos definido en la aplicación

Web, el enlazador de modelo puede ser capaz de identificar los parámetros en la
URL. En el URL de ejemplo, "45" es identificado como parámetro de la ruta MVC

predeterminada.
3. Cadenas de consulta (Query Strings). Si la solicitud del usuario incluye parámetros

con nombre después de un signo de interrogación, podemos encontrar esos
parámetros en la colección Request.QueryString.
4. Archivos. Si la petición del usuario incluye archivos cargados, estos pueden ser
utilizados como parámetros.
Es importante tener en cuenta que, si hay valores de formulario y valores de ruta en la petición Web,
los valores de formulario tienen prioridad. Los valores de cadena de consulta sólo se utilizan si no hay
valores de formulario ni valores de ruta disponibles como parámetros.
Extensibilidad de Modelo
La arquitectura MVC ha sido diseñada para proporcionar extensibilidad para que los desarrolladores
puedan adaptar la arquitectura a requisitos inusuales o únicos. Por ejemplo, el invocador de acción
predeterminado, ControllerActionInvoker, puede ser remplazado por nuestro propio invocador de
acción si deseamos implementar nuestra propia lógica de invocación.
Dos formas en las que podemos extender el manejo de modelos MVC son crear anotaciones de datos
personalizadas y crear enlazadores de modelo personalizados.
Anotaciones de datos de validación personalizadas

Podemos utilizar anotaciones de datos de validación personalizadas para indicar a MVC cómo validar
los datos que introduce un usuario a través de un formulario o a través de cadenas de consulta. Los
cuatro atributos básicos de validación incorporados en MVC, Required, Range, StringLength y
RegularExpression, son muy flexibles. Sin embargo, en algunas situaciones, podríamos querer
ejecutar algún código de validación personalizado para:
• Ejecución de una verificación sobre la fuente de datos. Sucede cuando queremos verificar
los datos proporcionados con los datos almacenados en la base de datos o en otro almacén
de datos.
• Comparar valores. Sucede cuando queremos comparar entre si dos valores proporcionados.
• Verificaciones matemáticas. Sucede cuando deseamos calcular un valor a partir de los datos
proporcionados y verificar que el valor es válido.
En tales situaciones, podemos crear una anotación de datos de validación personalizada.
Enlazadores de Modelo personalizados

El Invocador de Acción de Controlador predeterminado recibe peticiones e invoca a la acción
correcta en el Controlador correcto para atender la solicitud. El invocador de acción predeterminado
utiliza enlazadores de modelo para identificar los parámetros en la solicitud y pasa todos ellos a los
parámetros correctos de la acción. Este mecanismo garantiza que las cadenas de consulta, los valores
de ruta, los valores de formulario y los archivos cargados estén disponibles para que la acción pueda
trabajar con ellos.
El enlazador de modelo predeterminado es sofisticado y flexible, pero a veces podríamos querer

personalizar su comportamiento para pasar parámetros de una manera inusual. Podemos hacer esto
creando un enlazador de modelo personalizado y registrándolo con el runtime de MVC.
Creando una Anotación de Datos de Validación personalizada

Podemos utilizar Anotaciones de datos para indicar a MVC la forma en que debe validar los datos que
un usuario introduce en un formulario o que pasa a través de cadenas de consulta.
MVC tiene incorporados 4 atributos básicos de validación, sin embargo, en algunas situaciones
podríamos tener la necesidad de ejecutar algún código de validación personalizado, por ejemplo
verificar los datos proporcionados con los datos almacenados en una fuente de datos. En tales
situaciones, podemos crear una anotación de datos de validación personalizada.
Supongamos que queremos validar que el nombre de una persona no exista actualmente en una
fuente de datos, en este caso podemos crear una anotación de datos de validación llamada
NombreValido. Para hacer eso, creamos una clase que herede de la clase
System.ComponentModel.DataAnnotations.ValidationAttribute como la siguiente.
public class NombreValido:ValidationAttribute

{
}
La clase ValidationAttribute es una clase abstracta que expone varios métodos. En nuestro caso
sobrescribiremos el método IsValid que recibe como parámetro un objeto y devuelve un valor
booleano.
public class NombreValido:ValidationAttribute

{
public override bool IsValid(object value)
{
return VerificaNombre(value.ToString());
}
private bool VerificaNombre(string nombre)

{
// Aquí va el código que busca el nombre en la Base de datos.
// Para este caso sólo comparamos que el nombre no sea “Demo”.
if(this.ErrorMessage.Contains("{0}"))
{
this.ErrorMessage =
this.ErrorMessage.Replace("{0}", "Demo");
}
return nombre != "Demo";

}
}
Es importante mencionar que con este código sólo estaremos validando del lado del servidor. En
situaciones especiales, también es posible hacer que la validación se realice tanto en el servidor
como en el cliente mediante la implementación de la interface IClientValidatable y codificando
también con jQuery para crear un Validador y Adaptador.
También es posible implementar validaciones personalizadas que apliquen a la clase Modelo

directamente en lugar de aplicar únicamente a una propiedad. Para hacer esto, debemos
implementar la interface IValidatableObject.
Una vez creada la Anotación de datos de Validación, podemos aplicarla a la propiedad apropiada
como en el siguiente ejemplo.
[Required(ErrorMessage="Debe proporcionar un nombre")]

[NombreValido(ErrorMessage="El nombre {0} ya existe")]
Creando Enlazadores de Modelo personalizados

Un Enlazador de Modelo asegura que los datos correctos sean enviados a los parámetros de un
método de acción de un Controlador. Esto permite a MVC crear instancias de las clases Modelo que
satisfagan la petición del usuario.
MVC incluye un Enlazador de Modelo predeterminado con lógica sofisticada que pasa parámetros
correctamente en casi todos los casos sin la necesidad de crear código personalizado complejo. El
Enlazador de Modelo predeterminado es sofisticado y flexible, pero a veces podríamos querer
personalizar su comportamiento para pasar parámetros de una manera inusual. Podemos hacer esto
creando un Enlazador de Modelo personalizado y registrándolo con el runtime de MVC.
Supongamos que desde una página Web queremos solicitar las habilidades técnicas de una persona y
almacenarlas en un arreglo. Podríamos empezar agregando la siguiente propiedad a una clase
Persona.
[Required]
public string[] Habilidades { get; set; }
La Vista podría contener un Texbox para permitir la entrada del usuario. Las habilidades podrían ser
proporcionadas como una lista separada por comas.
<input id="Habilidades" name="Habilidades" type="text" value=""/>
Al recibir la información del usuario, el Enlazador de Modelo predeterminado colocaría en el primer

elemento del arreglo la información de las habilidades proporcionadas por el usuario en el TextBox.
Sin embargo, nosotros necesitamos tener una habilidad en cada elemento del arreglo. Para este
caso, podemos crear un Enlazador de Modelo personalizado como se muestra en el siguiente
ejemplo.
public class PersonaMB:IModelBinder

{
public object BindModel(ControllerContext controllerContext,
ModelBindingContext bindingContext)
{
var Request = controllerContext.HttpContext.Request;
var persona = new Persona();
persona.Nombre = Request.Form["Nombre"];
persona.CodigoPostal = Request.Form["CodigoPostal"];
persona.DominioIngles = byte.Parse(Request.Form["DominioIngles"]);
persona.Correo = Request.Form["Correo"];
persona.Habilidades =
Request.Form["Habilidades"]
.Split(new char[] { ',' },
StringSplitOptions.RemoveEmptyEntries)
.Select(h => h.Trim()).ToArray();
if(persona.Habilidades.Count()<=1)
{
bindingContext.ModelState.AddModelError("Habilidades",
"Debe proporcionar más de una habilidad");
}
return persona;
}
}
Como podemos ver en el ejemplo anterior, un Enlazador de Modelo personalizado debe

implementar la interface IModelBinder. La interface IModelBinder define un único método llamado
BindModel donde se realiza el enlace con la clase Modelo.
El método BindModel recibe los parámetros:
• controllerContext. Proporciona información acerca del Controlador asociado y la petición

actual.
• bindingContext. Proporciona información acerca del Modelo y su Metadata.
En el método BindModel se crea una instancia del Modelo y se asignan los valores que se encuentran
en el objeto Request.Form.
En la lógica de negocio particular de este ejemplo, si el usuario sólo proporciona una habilidad o
ninguna, se genera un error.
Una vez que se ha creado el Enlazador personalizado, este debe ser asociado al tipo Persona para
que el Framework MVC conozca de su existencia. Para asociar un Enlazador a un tipo, debemos
registrarlo durante el inicio de la aplicación en el archivo Global.asax.
public class MvcApplication : System.Web.HttpApplication

{
protected void Application_Start()
{
AreaRegistration.RegisterAllAreas();
RouteConfig.RegisterRoutes(RouteTable.Routes);
ModelBinders.Binders.Add(typeof(Persona), new PersonaMB());
}
}
Lección 2
Trabajando con datos
Todas las aplicaciones Web presentan información y casi todas las aplicaciones Web requieren un
almacén de datos para esta información. Mediante la presentación de páginas Web utilizando datos
de un almacén de datos, podemos crear una aplicación Web que cambie continuamente en
respuesta a la entrada del usuario, acciones administrativas y publicación de eventos.
Generalmente el almacén de datos es una base de datos, pero también pueden ser utilizados otros
almacenes de datos.
En las aplicaciones MVC, podemos crear un Modelo que implemente tanto la lógica de acceso a
datos como la lógica de negocio. Alternativamente, podemos separar la lógica de negocios de la
lógica de acceso a datos implementando la lógica de acceso a datos en un Repositorio. Un
Repositorio es una clase que un Controlador puede invocar para leer y escribir datos desde y hacia
un almacén de datos.
El .NET Framework incluye las tecnologías Entity Framework y LINQ, que hacen que el código de
acceso a datos sea muy rápido de escribir y sencillo de entender. En esta lección, mostraremos la
forma de crear un sitio Web MVC con acceso a una base de datos.
Al finalizar esta lección, los participantes serán capaces de:
• Conectar una aplicación a una base de datos para acceder y almacenar datos.
• Describir las características de Entity Framework.
• Usar LINQ para escribir consultas que permitan seleccionar, filtrar y agrupar datos.
• Crear clases Modelo, separadas de las clases Repositorio mediante el uso de Código
Entity Framework.
• Explicar cómo acceder a los datos en Modelos y Repositorios.
Conectando a una base de datos

La mayoría de los sitios Web utilizan una base de datos para almacenar datos dinámicos. Con la
inclusión de estos datos en páginas HTML generadas, podemos crear una aplicación Web dinámica
con contenido que cambie frecuentemente. Por ejemplo, podemos proporcionar páginas Web
administrativas que permitan a los empleados de la empresa actualizar el catálogo de productos y
crear artículos publicitarios. Los productos y los artículos se almacenan en la base de datos. Tan
pronto como sean almacenados, los usuarios pueden verlos y leerlos. Los empleados no necesitan
editar código HTML o volver a publicar el sitio Web para que los cambios sean visibles.
Algunos sitios Web pueden almacenar datos en otras ubicaciones, tales como un servicio de
directorio, sin embargo, las bases de datos son el almacén de datos utilizado más ampliamente.
ADO.NET y Bases de Datos

Cuando creamos aplicaciones .NET, incluyendo aplicaciones Web MVC, podemos utilizar la tecnología
ADO.NET para acceder a bases de datos. Las clases ADO.NET están contenidas en el espacio de
nombres System.Data. ADO.NET soporta una amplia gama de bases de datos mediante el uso de
diferentes proveedores de datos. Por ejemplo:
• Microsoft SQL Server. Este es el servidor de bases de datos de Microsoft, líder en la

industria. ADO.NET incluye el proveedor SqlClient para todas las bases de datos de SQL
Server.
• Microsoft SQL Server Express. Esta es una versión gratuita de SQL Server que incluye una
amplia gama de funcionalidad de base de datos y es muy flexible. Algunas funciones
avanzadas, como el Cluster de base de datos, no se encuentran disponibles en SQL Express.
El proveedor SqlClient es utilizado para SQL Express.
• SQL Server 2012 Express LocalDB. Es una nueva versión de SQL Server Express especialmente
dirigida a los desarrolladores para evitarles una instalación completa de otras ediciones de
SQL Server. De esta forma los desarrolladores se pueden enfocar en el desarrollo de
aplicaciones sin hacer una gran inversión de tiempo instalando y configurando un servidor de
base de datos. SQL Server Express LocalDB se debe usar en lugar de la característica de
instancias de usuario de SQL Server Express, que ha quedado obsoleta.
• Microsoft SQL Server Compact. Esta versión de SQL también es gratuita y utiliza archivos .sdf
para almacenar datos en el disco duro. ADO.NET incluye el proveedor SqlServerCe para
bases de datos SQL Compact.
• Bases de datos Oracle. Este es un servidor de bases de datos ampliamente utilizado.
ADO.NET incluye el proveedor OracleClient para todas las bases de datos Oracle.
• OLE DB. Este es un estándar que diferentes bases de datos adoptan. ADO.NET incluye el
proveedor OleDb para todas las bases de datos OLE DB.
• ODBC. Este es otro viejo estándar que diferentes bases de datos adoptan. ADO.NET incluye el
proveedor ODBC para todas las bases de datos ODBC. En general, debemos utilizar un
proveedor OLE DB si está disponible en lugar de un proveedor ODBC.
Es posible también, utilizar proveedores ADO.NET de terceros para acceder a otras bases de datos.
Bases de datos en la nube (Cloud Databases)

La base de datos de una aplicación Web normalmente se encuentra en el mismo servidor que la
propia aplicación Web o en un servidor dedicado de base de datos en el mismo sitio físico. Sin
embargo, si contamos con una conexión de Internet rápida y confiable, podemos considerar el uso
de una base de datos en la nube. Además, si hemos elegido hospedar una aplicación Web en la nube,
una base de datos en la nube es una solución lógica de almacenamiento. El servicio de base de datos
en la nube de Microsoft se llama SQL Database y es una parte de Microsoft Azure.
Microsoft Azure SQL Database tiene las siguientes ventajas:
• Las bases de datos se encuentran en los centros de datos de Microsoft con la mejor
conectividad y confiabilidad.
• Microsoft garantiza el 99% de disponibilidad.
• No es necesario instalar y administrar nuestros propios servidores de base de datos o
emplear administradores de base de datos.
• Las bases de datos pueden ser escaladas con mucha facilidad.
• Sólo se paga por los datos que se utilizan y distribuyen.
Podemos utilizar Microsoft Azure SQL Database con ADO.NET utilizando el proveedor SqlClient.
Conectando una aplicación Web MVC a una base de datos

Para utilizar ADO.NET y conectarse a una base de datos, es necesario agregar dos elementos a la
aplicación:
1. El primer elemento que debemos agregar es la referencia al Assembly System.Data.dll que

incluye el espacio de nombres System.Data.
2. El segundo elemento que debemos agregar es una cadena de conexión en el archivo
Web.config. Esta cadena especifica el proveedor, la ubicación de la base de datos, las
propiedades de seguridad y otras propiedades dependiendo del proveedor.
El siguiente ejemplo muestra el código de una cadena de conexión en el archivo Web.config para
conectarse a una base de datos llamada NorthWind alojada en el servidor local y utilizando las
credenciales bajo la cuales se ejecuta la aplicación Web.
<connectionStrings>
<add name="NorthWind"
connectionString="Data Source=.;Integrated Security=true;
Initial Catalog=NorthWind"
providerName="System.Data.SqlClient"/>
</connectionStrings>
La siguiente cadena de conexión especifica una conexión a Microsoft Azure SQL Database.
<add name="NorthWindAzure"
connectionString="Data Source=qahac5iuty.database.windows.net;
User id=Developer;Password=DeveloperPassword;Initial Catalog=NorthWind"
Una cadena de conexión para una base de datos SQL Server 2012 Express LocalDB quedaría de la
siguiente forma:
<add name="NorthWindLocalDB"
connectionString="Data Source=(localdb)\v11.0;Integrated
security=true;AttachDbFileName=c:\demosmvc\NorthWind.mdf"
En esta cadena de conexión estamos especificando una conexión con la instancia automática localdb
propiedad del usuario actual utilizando el archivo de base de datos c:\demosmvc\NorthWind.mdf.
La etiqueta <connectionStrings> debe aparecer dentro de la etiqueta <configuration>, después de la

etiqueta <configSections>.
Las plantillas de aplicaciones Web MVC en Microsoft Visual Studio incluyen referencias ADO.NET, así
que no es necesario agregarlas. Sin embargo, se deben agregar las cadenas de conexión. Algunas de
las plantillas, tales como la plantilla de Sitio de Internet, incluyen bases de datos de membresía SQL
Server Express con cadenas de conexión.
Entity Framework
Los desarrolladores escriben código que trabaja con clases y objetos. Por otro lado, las bases de
datos almacenan datos en tablas con columnas y filas. Los administradores de bases de datos crean y
analizan bases de datos mediante la ejecución de consultas de Transact-SQL. Podemos elegir
construir y ejecutar consultas Transact-SQL dentro del código ADO.NET. Sin embargo, ADO.NET
incluye Entity Framework - esta tecnología nos permite leer y escribir datos desde y hacia una base
de datos mediante el uso de clases y objetos.
Entity Framework es un marco de trabajo de Mapeo Relacional de Objetos (Object Relational

Mapping - ORM). Un Framework ORM mapea las tablas y las columnas que se encuentran en una
base de datos a objetos y sus propiedades que podemos utilizar desde el código .NET.
Flujos de trabajo de Entity Framework

La forma en que utilicemos Entity Framework en nuestra aplicación depende de la manera en la cual
queramos construir la base de datos. Los tres flujos de trabajo de Entity Framework disponibles son:
Base de datos primero (database-first), Modelo primero (model-first) y Código primero (code-first):
• Database first. Podemos utilizar el flujo de trabajo Database first cuando tenemos una base
de datos que ya exista o si preferimos crear una nueva base de datos mediante la definición
de tablas, columnas, vistas y otros objetos del esquema de la base de datos. En este flujo de
trabajo, Entity Framework analiza la base de datos y crea un archivo XML con una extensión
.edmx denominado el archivo del Modelo. El archivo del Modelo describe las clases con las
cuales seremos capaces de trabajar en nuestro código. Podemos ajustar el Modelo mediante
el uso de un diseñador en Visual Studio y posteriormente escribir código para utilizar las
clases del Entity Framework.
• Model first. Podemos utilizar el flujo de trabajo Model first cuando aún no disponemos de
una base de datos y preferimos diseñar nuestro Modelo utilizando una herramienta de
modelado ORM. En este flujo de trabajo, creamos el archivo .edmx en el diseñador de Visual
Studio y posteriormente escribimos código para utilizar las clases Modelo generadas por el
diseñador. Al ejecutar la aplicación, Entity Framework crea las tablas y las columnas de la
base de datos para soportar el Modelo. En este flujo de trabajo, Visual Studio también puede
crear una cadena de conexión por nosotros e insertarla en el archivo web.config, basado en
la base de datos que especifiquemos.
• Code first. Podemos utilizar el flujo de trabajo Code first si preferimos crear un Modelo
escribiendo clases .NET. En este flujo de trabajo, no hay un archivo de Modelo. En su lugar,
creamos las clases Modelo en C # o VB. Al ejecutar la aplicación, Entity Framework crea la
base de datos.
Agregando un Contexto de Entity Framework

Al utilizar Entity Framework en el flujo de trabajo de Código primero, debemos asegurarnos de que el
Framework crea la base de datos y las tablas correctas para almacenar las clases Modelo. Para hacer
esto, creamos una clase que herede de la clase DbContext del Entity Framework. Esta clase será
utilizada en los controladores cuando queramos manipular datos en la base de datos. Dentro de esta
clase, agregamos una propiedad DbSet<> para cada tabla de la base de datos que deseamos que
Entity Framework creé en la nueva base de datos.
Asumiendo que tenemos las clases Modelo Category y Product, el siguiente código muestra cómo
agregar un contexto de Entity Framework al Modelo.
public class NorthWindDB:DbContext

{
public DbSet<Category> Categories { get; set; }
public DbSet<Product> Products { get; set; }
}
En el código anterior, Entity Framework busca una cadena de conexión con el nombre NorthWindDB,
que coincide con el nombre de la clase que hereda de DbContext. Entity Framework crea la base de
datos en la ubicación que proporciona la cadena de conexión y crea dos tablas en la nueva base de
datos:
• Categories: Esta tabla tendrá columnas que coincidan con las propiedades de la clase Modelo
Category.
• Products: Esta tabla tendrá columnas que coincidan con las propiedades de la clase Modelo
Product.
Utilizando un Contexto de Entity Framework

Una vez que hayamos definido las clases Modelo y la clase del Contexto del Entity Framework,
podemos utilizarlas en controladores MVC para pasar datos a las vistas para que sean mostrados.
El siguiente código muestra cómo utilizar el contexto de Entity Framework en un controlador MVC
para pasar un conjunto de objetos Modelo Category a una Vista.

{
var Context = new NorthWindDB();
return View(Context.Categories.ToList());
}
Utilizando Inicializadores para llenar bases de datos

Si estamos utilizando el flujo de trabajo code-first o model-first, Entity Framework crea la base de
datos la primera vez que ejecutamos la aplicación y accedemos a los datos. La base de datos
permanece vacía si hemos creado el esquema de la base de datos pero no la hemos llenado con
registros de datos.
Podemos utilizar una clase inicializadora para llenar la base de datos con datos de ejemplo. Esta
técnica asegura que haya datos de ejemplo para trabajar durante el desarrollo.
Las siguientes líneas de código muestran cómo crear una clase inicializadora que agrega dos objetos
Category a la tabla Categories en la base de datos.
public class NorthWindInitializer: DropCreateDatabaseAlways<NorthWindDB>

{
// Remplazamos el método para llenar la base de datos
protected override void Seed(NorthWindDB context)
{
// Creamos una lista de Categorías
var Categories = new List<Category>
{
new Category{CategoryID=1, CategoryName="Bebidas"},
new Category{CategoryID=2, CategoryName="Frutas"}
};
// Agregamos la lista de Categorías a la base de datos
Categories.ForEach(c => context.Categories.Add(c));
context.SaveChanges();
}
}
Después de haber creado la clase inicializadora, necesitamos asegurar que esta se procese mediante
la adición de una línea de código ya sea en el método Application_Start del archivo Global.asax, en
el archivo de configuración Web.config o en la clase Contexto. El siguiente código muestra un
ejemplo del código agregado en el archivo Web.config.
<appSettings>
<add key="DatabaseInitializerForType DemoContexto.Models.NorthWindDB ,
DemoContexto"
value="DemoContexto.Models.NorthWindInitializer , DemoContexto"/>
</appSettings>
La primera parte del atributo key debe ser la palabra DatabaseInitializerForType seguida de un
espacio, el nombre del tipo Contexto incluyendo su espacio de nombres y una coma seguida por el
nombre del Assembly que contiene al tipo Contexto.
El atributo value debe especificar el tipo de la clase inicializadora incluyendo su espacio de nombres
y una coma seguida por el nombre del Assembly que contiene a este tipo.
El siguiente ejemplo muestra el código en el método Application_Start del archivo Global.asax para
establecer la clase Inicializadora.
Database.SetInitializer<NorthWindDB>(new NorthWindInitializer());
LINQ to Entities
El Lenguaje Integrado de Consultas (Language Integrated Query - LINQ) es un conjunto de
características que extienden y proporcionan poderosas capacidades de consultas a la sintaxis del
lenguaje C# y Visual Basic.
Estas capacidades de consulta se pueden utilizar para extraer datos de bases de datos, objetos
numerables, documentos XML y otras fuentes de datos. Las expresiones de consulta son similares a
las consultas Transact-SQL pero utilizan palabras claves de C# o VB y de este modo podemos obtener
soporte de IntelliSense y comprobación de errores en Visual Studio.
¿Qué es LINQ to Entities?

LINQ to Entities es la versión de LINQ que funciona con Entity Framework. LINQ to Entities permite
escribir consultas complejas y sofisticadas para localizar datos específicos o unir datos de varios
objetos de un Contexto de Entity Framework. Si utilizamos Entity Framework, podemos escribir
consultas LINQ en cualquier parte que requiramos una instancia específica de una clase Modelo, un
conjunto de objetos, o para necesidades de aplicaciones más complejas. Podemos escribir consultas
LINQ en sintaxis de consulta similares a la sintaxis SQL o a la sintaxis de métodos en la que las
operaciones como "select" son invocadas como métodos de los objetos.
Utilizando LINQ to Entities

En las siguientes líneas de código, se puede ver cómo obtener una lista de Categorías de la base de
datos. Se incluye tanto ejemplos de sintaxis de consulta como sintaxis de método.
public ActionResult Show(int id=0)

{
// Lista de Categorías a mostrar.
List<Category> Categories;
// Creamos el Contexto de Entity Framework.
var Context = new NorthWindDB();
if(id==0)
{
// Si no se especifica un ID de categoría, mostramos todas.
// Este es un ejemplo de sintaxis de Método.
Categories = Context.Categories.ToList();
}
else
{
// Se ha solicitado ver información de una Categoría específica
// Utilizamos una consulta LINQ con sintaxis de Consulta
// para obtener la información de la base de datos.
Categories = (from c in Context.Categories
where c.CategoryID == id
select c).ToList();
}
return View("Index", Categories);
}
Para obtener más ejemplos de consultas LINQ, puede visitarse el siguiente enlace.
101 LINQ Samples

http://code.msdn.microsoft.com/101-LINQ-Samples-3fb9811b
Acceso a datos en Modelos y Repositorios

En las aplicaciones MVC, podemos colocar el código de acceso a datos en el modelo junto con la
lógica del negocio. Sin embargo, muchos arquitectos de software prefieren separar estos dos tipos de
código debido a que sirven para diferentes propósitos:
• Lógica de Negocios. Este código define los objetos que la aplicación Web administra, sus
propiedades y las relaciones de unos con otros.
• Lógica de Acceso a Datos. Este código define las operaciones necesarias para persistir los
datos a una base de datos. Esto incluye operaciones para crear nuevos registros, leer
registros, actualizar registros y eliminar registros en las tablas de la base de datos. Un simple
objeto en la capa de lógica de negocios puede tomar datos de varias tablas de la base de
datos. Esta abstracción es manejada por la lógica de acceso a datos.
MVC no requiere que separemos la lógica de negocio y la lógica de acceso a datos. Es posible crear
clases modelo MVC que implementen ambas capas. Esto se hace a menudo en aplicaciones Web
pequeñas o sencillas con equipos pequeños de desarrollo. En estos casos, las clases Entity
Framework son utilizadas directamente en las clases Modelo.
En situaciones más complejas, es necesario colocar la lógica de negocios en las clases Modelo MVC y
colocar la lógica de acceso a datos en clases dedicadas llamadas Repositorios. Cuando se adopta este
enfoque, las clases Modelo son independientes de la estructura de la base de datos y no incluyen
código que dependa de los nombres de las tablas, columnas o vistas de la base de datos. Este
enfoque hace que sea más fácil rediseñar la base de datos o mover a un almacenamiento diferente
de datos o tecnología de acceso a datos, sin necesidad de recodificar la aplicación entera. Utilizando
este enfoque, empleamos Entity Framework en las clases Repositorio, pero no en las clases Modelo.
¿Cómo separar las clases Modelo y Repositorio?

Si decidimos separar la lógica de negocio y la lógica de acceso a datos, debemos realizar los
siguientes pasos para cada clase Modelo:
1. Definir una Interface para la clase Repositorio. Esta Interface declara los métodos que la
clase Repositorio utiliza para leer y escribir datos desde y hacia la base de datos.
2. Crear y escribir código para la clase Repositorio. Esta clase debe implementar todos los
métodos de acceso a datos declarados en la Interface.
3. Eliminar todo el código de acceso a datos que exista en la clase Modelo.
4. Modificar la clase Controlador para crear una instancia de la clase Repositorio e invocar sus
métodos para crear el modelo en lugar de llamar a los métodos del Entity Framework.
Para ilustrar cómo separar las clases modelo y las clases repositorio, veamos el siguiente ejemplo.
La clase modelo Product representa un producto de un almacén tal como se ilustra en las siguientes
líneas de código.
public class Product

{
public int ProductID { get; set; }
public string ProductName { get; set; }
public int CategoryID { get; set; }
}
La siguiente Interface para una clase Repositorio Product define sólo un método para obtener los
productos de una categoría determinada como ilustran las siguientes líneas de código.
public interface IProductRepository

{
ICollection<Product> GetProducts(int categoryID);
}
La clase ProductRepository implementa el método GetProducts como ilustran las siguientes líneas
de código.
public class ProductRepository:IProductRepository

{
public ICollection<Product> GetProducts(int categoryID)
{
ICollection<Product> Products;
using(var Context = new NorthWindDB())
{
Products =
Context.Products.Where(p=>p.CategoryID== categoryID).ToList();
}
return Products;
}
}
La clase ProductController utiliza la clase Repositorio en lugar de llamar a los métodos del Entity
Framework como ilustran las siguientes líneas de código.
public ActionResult ShowProducts(int id)

{
IProductRepository Repository =
new ProductRepository();
var Products = Repository.GetProducts(id);
return View(Products);
}
Al utilizar la Interface IProductRepository, el código hace que sea fácil de reemplazar

ProductRespository con otra implementación si necesitáramos hacerlo. Sin embargo, el código del
Controlador aún crea un objeto ProductRespository. Se debe modificar el objeto para hacer el
reemplazo.
En una arquitectura aún mejor, podemos reemplazar ProductRepository con una implementación
diferente de IProductRepository sin ningún cambio en la clase del Controlador. Este es un enfoque
extremadamente flexible y adaptable y se conoce como una arquitectura de acoplamiento débil.
Las arquitecturas de acoplamiento débil también son esenciales para las Pruebas Unitarias.
Programador Jr. de
MVC
Modulo 4: Desarrollando Controladores
ASP.NET MVC
Acerca del módulo

Los Controladores MVC responden a las peticiones del Cliente Web, crean objetos Modelo y los
pasan a las Vistas para que generen el código HTML que los represente y que se muestren en el
explorador Web. En caso de ser requerido, los Controladores también pueden realizar otras acciones,
tal como guardar en la base de datos los cambios de la clase Modelo. Los Controladores son
componentes centrales de las aplicaciones MVC. Es importante entender las funciones de los
Controladores para ser capaces de crear los objetos Modelos correctos, manipularlos y pasarlos a las
Vistas correctas.
Para maximizar la reutilización de código en los Controladores, debemos conocer como programar
filtros de acción. Podemos utilizar filtros de acción para ejecutar código antes o después de cada
acción en la aplicación Web, en cada acción de un Controlador o en otras combinaciones de acciones
del Controlador.
Objetivos
• Agregar un Controlador a una aplicación Web para responder a las acciones de usuario
especificadas en el diseño del proyecto.
• Escribir código en los filtros de acción que se ejecute antes o después de una acción del
Controlador.
• Lección 1: Creando Controladores y Acciones

• Lección 2: Creando Filtros de Acción
Lección 1
Planeación en la fase de diseño del proyecto
Un Controlador es una clase .NET que hereda de la clase base System.Web.Mvc.Controller. Los
Controladores responden a las peticiones de los usuarios. Dentro de una clase Controlador, creamos
acciones para responder a las solicitudes del usuario. La Acciones son métodos dentro de un
controlador que devuelven un objeto ActionResult. El objeto ActionResult es frecuentemente una
Vista que muestra una respuesta a la petición de un usuario, sin embargo, también puede devolver
otro tipo de resultados.
Para procesar las peticiones entrantes de un usuario, manejar la entrada de datos, manejar las
interacciones del usuario e implementar lógica importante de la aplicación, necesitamos conocer la
forma de crear Controladores y Acciones. Debemos también conocer cómo crear parámetros en los
bloques de código de acciones y como pasar objetos a acciones.
Al finalizar esta lección, los participantes contarán con las habilidades y conocimientos para:
• Describir la forma en que un Controlador responde a las acciones del usuario en una
aplicación Web MVC.
• Crear un Controlador.
• Escribir Acciones en el Controlador para responder a las peticiones de los clientes, crear
clases Modelo e invocar Vistas.
• Explicar la forma de utilizar parámetros proporcionados a una Acción del Controlador desde
una petición Web y utilizarlos para cambiar el resultado de la Acción.
• Explicar la forma de pasar información a las Vistas que trabajan con clases Modelo.
• Describir las Fábricas de Controladores.
Respondiendo a las peticiones del Usuario

Cuando una aplicación Web MVC recibe una petición de un explorador Web, los siguientes eventos
ocurren en secuencia:
1. Cuando se recibe la primera petición para la Aplicación, en el archivo Global.asax, los objetos
Route son agregados al objeto colección RouteTable.
2. El módulo UrlRoutingModule utiliza el primer objeto Route de la colección RouteTable que
coincida con el formato de la ruta de la petición para crear un objeto RouteData que es
utilizado para crear un objeto RequestContext.
3. De la ruta seleccionada, el objeto UrlRoutingModule obtiene un objeto MvcRouteHandler
que implementa la interface IRouteHandler y que está asociado con el objeto Route.
4. El objeto MvcRouteHandler crea una instancia de la clase MvcHandler y le pasa la instancia
RequestContext.
5. El objeto MvcHandler utiliza la instancia RequestContext para identificar al objeto
IControllerFactory y crea una Fábrica de Controladores. La fábrica de Controladores es el
objeto que instancia un Controlador para responder a la petición. Normalmente, esta fábrica
es un objeto DefaultControllerFactory pero podemos crear una fábrica de Controladores
personalizada de ser necesario. El objeto MvcHandler selecciona la fábrica de Controladores
basado en el objeto RequestContext, el cual, tiene información acerca de la petición que el
usuario realizó.
6. La fábrica de Controladores crea un objeto Controller, y el objeto MvcHandler invoca al
método BeginExecute de ese Controller.
7. El objeto ControllerActionInvoker asociado al objeto Controller creado examina el objeto
RequestContext y determina la acción a invocar en el objeto Controller.
8. El ControllerActionInvoker utiliza un enlazador de Modelo para determinar los valores que
deben ser pasados como parámetros de la Acción.
9. El ControllerActionInvoker ejecuta la acción. Frecuentemente la Acción crea una nueva
instancia de una clase Modelo probablemente realizando una consulta a una base de datos
con los parámetros que el invocador le pasó. Este objeto Modelo es pasado a la Vista para
mostrar el resultado al usuario. Los métodos de Acción pueden realizar muchas otras tareas,
tales como, generar Vistas y Vistas Parciales, direccionar a otros Sitios Web, mostrar
fragmentos de Contenido o mostrar otros archivos.
La solicitud del usuario

Los usuarios en los exploradores Web realizan solicitudes a nuestro sitio Web escribiendo un URL en
la barra de direcciones o dando clic en algún enlace que los direccione a nuestro sitio Web. Tales
enlaces pueden estar localizados en un sitio Web externo o dentro de nuestro sitio Web, en cuyo
caso nosotros podemos controlar la forma en que son creados. Independientemente de que la
petición se genere dentro de nuestro sitio Web o desde un sitio Web externo, esta petición puede
incluir información que las Acciones del Controlador pueden utilizar como parámetros.
Consideremos los siguientes ejemplos:
• http://www.northwind.com/. Este URL es la página principal del sitio Web y no especifica

información adicional.
• http://www.northwind.com/product. Este URL especifica un valor extra, product. De
manera predeterminada el objeto MvcHandler interpreta esto como el nombre de un
Controlador.
• http://www.northwind.com/product/index. Este URL especifica un segundo valor, index.
De manera predeterminada, el objeto MvcHandler interpreta este valor como el nombre de
una Acción dentro del Controlador.
• http://www.northwind.com/product/display/1. Este URL especifica un tercer valor, 1. De
manera predeterminada, el objeto ControllerActionInvoker interpreta esto como un
parámetro que debe pasar al método de la Acción.
• http://www.northwind.com/product/display?id=1. Este URL incluye una cadena de
consulta, id=1. El ControllerActionInvoker examina las Acciones Display en el Controlador
Product. Si encuentra una Acción con un parámetro llamado id, invoca esa Acción y le pasa
un 1 como parámetro.
Podemos modificar la lógica anterior de diversas formas. Por ejemplo, podemos crear rutas que
interpreten de forma distinta los URLs anteriores. Los ejemplos anteriores son verdaderos cuando
sólo exista la ruta predeterminada.
Supongamos que un usuario solicita un Controlador llamado Product escribiendo el URL en la barra
de direcciones del explorador Web. De manera predeterminada, el objeto DefaultControllerFactory
de MVC nombra esta clase Controlador como ProductController. Debemos mantener esta
convención de nombres al crear y nombrar a los Controladores, de otra forma recibiremos errores
404 inesperados y los Controladores no trabajarán tal y como lo esperamos. Si creamos una fábrica
de Controladores personalizada, podemos definir nuestra propia convención de nombres para las
clases Controller.
Las plantillas de proyectos de Visual Studio incluyen un folder llamado Controllers. Este es un buen
lugar para crear nuestros Controladores. De manera predeterminada, Microsoft Visual Studio coloca
los Controladores en el espacio de nombres NombreDelProyecto.Controllers.
Escribiendo Acciones del Controlador

Los Controladores encapsulan la lógica de interacción del usuario de una aplicación Web MVC. Esta
lógica puede ser especificada mediante la creación de Acciones. Una Acción es un método dentro de
la clase Controlador. El código que escribimos dentro de un método de Acción determina la forma en
que el Controlador responderá a las solicitudes. El código también determina la clase Modelo y la
Vista que MVC utilizará para mostrar una página Web en el navegador.
Cuando agregamos un nuevo Controlador a una aplicación MVC, Visual Studio presenta opciones de
Scaffolding para ayudarnos a crear métodos de Acción y Vistas asociadas.
Scaffolding, es una técnica o mecanismo para generación automática de elementos a través de

plantillas predefinidas. Dependiendo de los elementos que queramos que sean creados
automáticamente, debemos seleccionar el Scaffold adecuado que contenga el conjunto de plantillas
requeridas.
El término Scaffolding puede traducirse literalmente como “Conjunto de andamios” o

estructura exterior desde la cual se organiza y se configura una construcción de algo.
En la industria de la construcción de casas o edificios, un Andamio (scaffold) es un
armazón de tablones o vigas puesto horizontalmente para colocarse encima de él y
trabajar para construir paredes o techos.
Por ejemplo, si seleccionamos el Scaffold “MVC 5 Controller with views, using Entity Framework” y
especificamos una clase Modelo y una clase Contexto de Entity Framework, Visual Studio puede
crear automáticamente las Vistas Create, Delete, Details, Edit e Index, así como los métodos de
Acción Index, Details, Create, Edit, Delete y DeleteConfirmed en el Controlador nuevo. Podemos
utilizar estos elementos como puntos de partida de nuestro código. Conforme vayamos adquiriendo
más experiencia con los métodos de acción, podríamos preferir el agregar un nuevo Controlador
utilizando el Scaffold “MVC 5 Controller - Empty” y escribir nuestros propios métodos sin código
generado automáticamente (código Scaffold).
Las Acciones del Controlador son métodos públicos que devuelven un objeto ActionResult. De la
misma forma, las Acciones pueden devolver objetos de muchas de las otras clases derivadas de la
clase ActionResult. Por ejemplo, podemos escribir el código de un Controlador con una Acción Index
para obtener todos los objetos Product y pasarlos a la vista Index.
Cuando queramos mostrar un objeto modelo específico, debemos obtener la instancia correcta
desde la base de datos. El siguiente código, muestra cómo desplegar los datos de un objeto Product
buscado por su ID.
public ActionResult Details(int id)
{
ActionResult Result;
var Context = new NorthwindEntities();
var Product =
Context.Products.FirstOrDefault((p) => p.ProductID == id);
if(Product != null)
{
Result = View(Product);
}
else
{
Result = HttpNotFound("Producto no encontrado");
}
return Result;
}
Acciones que responden a peticiones HTTP POST

Algunas acciones del usuario se dividen en dos partes: GET y POST.
Por ejemplo, para crear un nuevo Product un usuario puede hacer una petición HTTP GET a la
siguiente URL:
http://www.northwind.com/product/create
El siguiente código muestra una Acción que responde a una petición GET para mostrar un nuevo
formulario que permita la captura de un nuevo Product.
public ActionResult Create()

{
Product NewProduct = new Product();
return View(NewProduct);
}
La Vista Create muestra un formulario donde los usuarios pueden proporcionar el detalle del
producto, tal como, el Nombre, el Proveedor o la Categoría entre otros. Cuando un usuario hace clic
en el botón Create, el Navegador Web realiza una petición HTTP POST.
El siguiente método de acción responde a una petición POST. Notemos que el nombre del método es
el mismo, pero el atributo [HttpPost] es utilizado para especificar que esta acción responde al verbo
HTTP POST.
public ActionResult Create(Product newProduct)

{
if(ModelState.IsValid)
{
Context.Products.Add(newProduct);
Context.SaveChanges();
Result =
RedirectToAction("Details", new {id=newProduct.ProductID});
}
else
{
Result = View(newProduct);
}
return Result;
}
Notemos que la propiedad ModelState.IsValid se utiliza para comprobar si el usuario ha enviado

datos válidos. Podemos especificar la validación de datos mediante el uso de atributos de validación
de datos en la clase modelo. Si los datos son válidos, el objeto modelo es agregado y guardado. De lo
contrario, la aplicación muestra nuevamente la vista Create para que el usuario pueda corregir los
datos no válidos.
Nota: Para que el código anterior funcione, la vista Create debe contener un elemento Form que
utilice el método POST.
Tipos derivados de ActionResult

Normalmente, los métodos de Acción son definidos especificando un valor de retorno de tipo
ActionResult. ActionResult es una clase base de la que derivan distintas clases que también pueden
ser utilizadas para devolver diferentes respuestas al navegador Web.
Las Acciones del controlador por lo general retornan una Vista y pasan una clase Modelo a la misma
para su visualización. Podemos crear una Acción que invoque al método de apoyo (Helper) View del
Controlador para que creé y devuelva un objeto ViewResult. El método Helper View se encuentra
definido en la clase base System.Web.Mvc.Controller de la cual derivan las clases que representan a
los Controladores.
Alternativamente, se puede devolver un error HTTP. Por ejemplo, podemos crear una Acción tal que
si no se encuentra un objeto Product, el código creé un error 404 de recurso no encontrado
mediante el uso del método Helper HttpNotFound.
Algunas veces, es posible que necesitemos devolver un archivo desde un método de Acción. Por
ejemplo, consideremos que en un modelo Category, el archivo de imagen esté almacenado como un
arreglo de bytes en una base de datos. Para mostrar ese arreglo de bytes como una imagen en una
página Web, la Acción debe devolverlo como un archivo de imagen que puede ser utilizado para el
atributo src de un tag HTML <img>. Para devolver archivos, podemos utilizar el Helper File para
devolver un objeto FileContentResult, FileStreamResult o FilePathResult.
Otros posibles resultados de Acciones incluyen:

• PartialViewResult. A través del método Helper PartialView, podemos utilizar este tipo de
resultado para generar una sección de una página HTML pero no una página HTML completa.
Las Vistas parciales pueden ser reutilizadas en diferentes Vistas de una aplicación Web.
• RedirectToRouteResult. A través de los métodos Helper RedirectToAction o
RedirectToRoute, podemos utilizar este resultado de Acción para redirigir al navegador a
otro método de acción o a otra ruta.
• RedirectResult. A través del método Helper Redirect, podemos utilizar este resultado de
Acción para redirigir a un URL específico, ya sea dentro de nuestra aplicación Web o a una
ubicación externa.
• ContentResult. A través del método Helper Content, podemos utilizar este resultado de
Acción para devolver texto al navegador Web. Podemos devolver texto plano, XML, una tabla
delimitada por comas o en otros formatos de texto. Este texto se puede desplegar en el
navegador Web o puede ser analizado con el código del lado del cliente.
• JsonResult. A través del método Helper Json, podemos utilizar este resultado de Acción para
devolver un objeto JSON serializado.
• JavaScriptResult. A través del método Helper JavaScript, podemos utilizar este resultado de
Acción para devolver código JavaScript que puede ser ejecutado en el cliente.
• HttpUnauthorizedResult. Podemos devolver una instancia de HttpUnauthorizedResult como
resultado de Acción para indicar un estatus de error 401 debido a un acceso no autorizado.
• EmptyResult. Podemos devolver una instancia de EmptyResult como resultado si el método

de Acción debe devolver un resultado null (void).
Para conocer más acerca de los Controladores y los métodos de Acción, puedes
consultar las siguientes referencias:
Controllers and Action Methods in ASP.NET MVC Applications

http://msdn.microsoft.com/en-us/library/dd410269(v=vs.100).aspx
ActionResult Class
http://msdn.microsoft.com/en-
us/library/system.web.mvc.actionresult(v=vs.118).aspx
Acciones hijas (Child Actions)

Cuando una Acción devuelve una Vista completa, MVC envía al navegador Web una nueva página
Web completa para que sea mostrada. Algunas veces, podemos tener la necesidad de invocar una
acción desde una Vista para devolver una porción de contenido para mostrarla dentro de una página
Web.
Una Acción Hija es un método de acción que puede devolver de esta manera una pequeña parte del
contenido de la página Web.
Para declarar un método de Acción como una Acción Hija, podemos utilizar la anotación
[ChildActionOnly]. Esta anotación asegura que el método de Acción puede ser invocado únicamente
dentro de una Vista mediante el uso del Helper Html.Action. Utilizando este método, podemos evitar
que un usuario invoque directamente la acción hija escribiendo la URL correcta en la barra de
direcciones.
Utilizando Parámetros
Cuando los usuarios solicitan páginas Web, a menudo especifican información distinta o adicional al
nombre de la página Web misma. Por ejemplo, cuando solicitan una página de detalles de producto,
pueden especificar el nombre o el ID del producto a mostrar. Esa información adicional se conoce
como Parámetros. Debemos entender cómo determinar mediante código, los parámetros que haya
enviado el usuario en su solicitud.
Las clases ControllerActionInvoker y DefaultModelBinder obtienen los parámetros de una solicitud

del usuario y los pasan a los métodos de Acción. El DefaultModelBinder puede localizar parámetros
en un formulario enviado, en los valores de enrutamiento, en la cadena de consulta o en los archivos
enviados. Si el enlazador del modelo encuentra un parámetro en el método de Acción que coincida
con el nombre y el tipo de un parámetro de la solicitud, el método de Acción es invocado y el
parámetro es pasado desde la solicitud. Esta convención nos permite obtener y utilizar parámetros
en nuestras Acciones.
Por ejemplo, si un usuario realiza una solicitud con la siguiente URL:
http://www.norhwind.com/product/getproductbyname/?name=Chai
Podemos obtener fácilmente el valor de name en el método de Acción.
El siguiente ejemplo muestra cómo determinar el valor del parámetro name en una Acción del
controlador.
public ActionResult GetProductByName(string name)

{
var Product =
Context.Products.FirstOrDefault((p) =>
p.ProductName.Contains(name));
if(Product!=null)
{
Result = View("Details", Product);
}
else
{
Result = HttpNotFound(
string.Format("Producto '{0}' no encontrado", name));
}
return Result;
}
Notemos que el código del método de Acción utiliza el parámetro name para formular una consulta
LINQ to Entities. En este caso, la consulta busca un Producto con el nombre especificado.
Los parámetros en los métodos de Acción son utilizados frecuentemente de esta manera.
Pasando información a las Vistas

Mediante el uso del método Helper View en un método de Acción, podemos pasar a la Vista un
objeto Modelo tal como un objeto Product. Esta es una técnica utilizada frecuentemente para pasar
información desde una Acción del Controlador hacia una Vista. Esto es debido a que esta técnica se
adhiere estrechamente al patrón Modelo-Vista-Controlador, en el cual, cada Vista genera el código
HTML que representa los valores de las propiedades de la clase Modelo y que la Vista recibe desde el
Controlador. Siempre que sea posible, debemos utilizar esta técnica.
En algunos casos, es posible que queramos aumentar la información de la clase Modelo con algunos
valores adicionales. Por ejemplo, es posible que queramos enviar a la Vista un título que deba ser
insertado en la cabecera de la página. Además, algunas Vistas no utilizan clases Modelo. La página
principal de un sitio Web, por ejemplo, a menudo no tiene una clase Modelo específica. Para ayudar
en estas situaciones, podemos utilizar otras dos técnicas para proporcionar datos adicionales a la
Vista: ViewBag y ViewData.
Uso de ViewBag
ViewBag es un objeto dinámico que forma parte de la clase base ControllerBase. Debido a que es un
objeto dinámico, desde el método de Acción podemos agregarle propiedades de cualquier tipo. En la
Vista podemos utilizar el objeto ViewBag para obtener los valores agregados desde el método de
Acción.
Podemos agregar propiedades al objeto ViewBag en el método de Acción tal y como se ilustra en las
siguientes líneas de código.
ViewBag.Message = "Proporcione los datos del nuevo producto";

ViewBag.ServerTime = DateTime.Now;
Para obtener y utilizar las mismas propiedades en una Vista, podemos utilizar el siguiente código
Razor.
<h4>@ViewBag.Message</h4>
<h5>La hora actual del servidor es: @ViewBag.ServerTime</h5>
Utilizando el Diccionario ViewData

El objeto ViewBag fue agregado a MVC en la versión 3. En las versiones anteriores, podíamos pasar
datos adicionales a las Vistas utilizando el diccionario ViewData. Esta característica aún se encuentra
disponible por compatibilidad con versiones anteriores y para los desarrolladores que prefieren
utilizar objetos diccionario. De hecho, ViewBag es un objeto dinámico que encapsula al diccionario
ViewData. Esto significa que desde una Acción del controlador podemos guardar un valor utilizando
ViewBag y leer el mismo valor utilizando ViewData.
En los métodos de Acción se puede agregar datos al diccionario ViewData mediante el uso de parejas
Llave/Valor como ilustran las siguientes líneas de código.
ViewData["Message"] = "Proporcione los datos del nuevo producto";

ViewData["ServerTime"] = DateTime.Now;
Para obtener y utilizar los mismos valores en una Vista, podemos utilizar el siguiente código Razor.
<h4>@ViewData["Message"]</h4>
<h5>La hora actual del servidor es: @ViewData["ServerTime"]</h5>
¿Qué son las Fábricas de Controladores?

Una Fábrica de Controladores es un componente MVC que crea instancias de las clases Controller
que creamos. Por ejemplo, cuando un usuario escribe el siguiente URL:
http://www.northwind.com/product/details/5
Una fábrica de controladores debe crear una instancia de la clase ProductController. Posteriormente,
un invocador de Acciones invoca a uno de los métodos de Acción en esa clase, y un enlazador de
Modelo le pasa los parámetros.
En este ejemplo, una fábrica de controladores crea una instancia de la clase ProductController, el
invocador de acciones invoca al método details de esa clase y el enlazador de modelo le proporciona
el valor 5 como parámetro.
El Framework MVC incluye la clase DefaultControllerFactory que satisface los requerimientos de la

mayoría de las aplicaciones Web. Sin embargo, en ocasiones, podríamos necesitar crear una fábrica
de controladores personalizada para implementar nuestra propia lógica de creación del Controlador.
Cómo localiza la clase DefaultControllerFactory una clase

Controlador
Aunque la clase DefaultControllerFactory satisface los requerimientos de la mayoría de las
aplicaciones Web, es recomendable entender cómo DefaultControllerFactory determina la clase
controlador que necesita crear.
La clase DefaultControllerFactory identifica clases Controlador utilizando los siguientes criterios:
• El ámbito de la clase debe ser public.

• La clase no debe estar marcada como abstract.
• La clase no debe tener parámetros genéricos.
• La clase debe tener un nombre que termine en Controller.
• La clase debe implementar la interfaz IController.
Cuando la aplicación Web MVC inicia, DefaultControllerFactory crea una lista de todas las clases en
la aplicación que satisfagan estos criterios. Esta lista ayuda a crear rápidamente el Controlador
correcto. Para escribir un Controlador, debemos asegurarnos de implementar todos los criterios
antes mencionados. Por lo general, se cumple con el criterio de la interfaz IController heredando de
la clase base Controller.
De forma predeterminada, DefaultControllerFactory obliga a que todas las clases Controlador

finalicen con la palabra Controller. Por ejemplo, siguiendo esta convención, para la clase Modelo
Product, debemos crear un controlador llamado ProductController.
Razones para crear una Fabrica Personalizada de Controladores

En ocasiones, es posible que queramos implementar una fábrica personalizada de controladores. Hay
dos razones comunes para hacer esto:
• Para modificar los criterios de selección de los Controladores. Los criterios descritos
anteriormente, son adecuados para la mayoría de las aplicaciones Web, pero a veces, es
posible que queramos cambiarlos. Por ejemplo, podríamos no querer nombrar los
controladores con la palabra Controller al final, o podríamos querer agregar criterios propios
adicionales.
• Para soportar inyección directa (direct injection) para pruebas. Inyección Directa, es una
técnica de programación que permite especificar clases en tiempo de ejecución en lugar de
especificar clases al escribir el código. Esto es útil para pruebas unitarias ya que se puede
inyectar una clase de prueba con datos simulados en lugar de los datos reales. La clase
DefaultControllerFactory no soporta Inyección Directa.
Creando una Fábrica personalizada de Controladores

El siguiente ejemplo muestra el código de una fábrica personalizada de controladores
implementando la interface IControllerFactory.
Nótese que se deben implementar los métodos CreateController, GetControllerSessionBehavior y

ReleaseController para cualquier fábrica personalizada de controladores que queramos crear.
public class CustomControllerFactory : IControllerFactory

{
public IController CreateController(System.Web.Routing.RequestContext
requestContext, string controllerName)
{
// Aquí podemos instanciar la dependencia a inyectar
ILogger Logger = new DefaultLogger();
// Obtenemos el espacio de nombres de los Controladores

Assembly a = Assembly.GetExecutingAssembly();
string ns =
a.GetTypes().Select(t => t.Namespace)
.Where(n=>n.EndsWith(".Controllers"))
.FirstOrDefault();
// Formamos el nombre completo del controlador

string TypeName = ns + "." + controllerName + "Controller";
// Obtenemos el Tipo del controlador a crear

Type ControllerType = Type.GetType(TypeName);
// Creamos la instancia del controlador y le pasamos el parámetro del

// constructor
IController Controller =
Activator.CreateInstance(ControllerType,
new[] { Logger }) as Controller;
// Devolvemos la instancia del controlador

return Controller;
}
public SessionStateBehavior GetControllerSessionBehavior(

RequestContext requestContext,
string controllerName)
{
// Utilizamos la lógica predeterminada de ASP.NET para determinar el
// comportamiento del estado de sesión de la petición
return System.Web.SessionState.SessionStateBehavior.Default;
}
public void ReleaseController(IController controller)

{
IDisposable Disposable = controller as IDisposable;
if(Disposable!=null)
{
Disposable.Dispose();
}
}
}
La lógica en un controlador personalizado real debería ser más sofisticada que en este ejemplo. Sin
embargo, el ejemplo ilustra el código mínimo requerido para crear una fábrica personalizada de
controladores.
Registro de una fábrica de controladores personalizada

Aunque hayamos creado una fábrica personalizada de controladores en nuestra aplicación, MVC
seguirá utilizando la clase DefaultControllerFactory a menos que registremos nuestra fábrica
personalizada.
Registramos una fábrica personalizada de controladores, utilizando la clase ControllerBuilder en el

archivo Global.asax como se muestra en las siguientes líneas de código.
protected void Application_Start()

{
AreaRegistration.RegisterAllAreas();
RouteConfig.RegisterRoutes(RouteTable.Routes);
ControllerBuilder.Current.SetControllerFactory(
new CustomControllerFactory());
}
Lección 2
Creando Filtros de Acción
En algunas situaciones, es posible que necesitemos ejecutar código antes o después de que se
ejecuten algunas Acciones del Controlador. Por ejemplo, antes de que un usuario ejecute alguna
Acción que modifique datos, es posible que queramos ejecutar el código que verifica el detalle de la
cuenta de usuario. Si agregamos dicho código a las Acciones mismas, tendríamos que duplicar el
código en todas las acciones donde queramos que se ejecute ese código.
Los filtros de Acción proporcionan una manera conveniente para evitar la duplicación de código, por
lo tanto, es necesario conocer cómo crear, y como y cuando utilizar filtros de acción en nuestras
aplicaciones Web.
• Describir los filtros de Acción.

• Crear filtros de Acción.
• Determinar cuándo utilizar filtros de Acción.
¿Qué son los Filtros?

El modelo de programación MVC impone la separación de responsabilidades. Por ejemplo, la lógica
del negocio en las clases Modelo está separada de la lógica de entrada en los Controladores y de la
lógica de interfaz de usuario en las Vistas. Cada clase Modelo también es claramente distinta de otras
clases Modelo. Sin embargo, hay escenarios donde los requerimientos pueden ser de interés para
diversas partes de la aplicación y atraviesan los límites lógicos. Por ejemplo, la autorización debe ser
realizada por muchas acciones y controladores sensibles independientemente del Modelo y las Vistas
que devuelven. Estos tipos de requerimientos son conocidos como responsabilidades transversales
(cross-cutting concerns).
Algunos ejemplos comunes de responsabilidades transversales incluyen autorización, registro

(logging) y almacenamiento en caché.
Filtros
Los filtros son clases MVC que podemos utilizar para administrar las responsabilidades transversales
en nuestras aplicaciones Web. Podemos aplicar un filtro a una Acción del controlador anotándole el
atributo apropiado. Por ejemplo, una Acción anotada con el atributo [Authorize] sólo puede ser
ejecutada por usuarios autenticados. También podemos aplicar un filtro para cada Acción en un
controlador, anotando a la clase Controlador con el atributo correspondiente.
Tipos de filtro
Existen cinco tipos principales de filtros que podemos utilizar en MVC. Estos filtros se ejecutan en
diferentes etapas durante el procesamiento de una petición.
La siguiente tabla muestra los principales tipos de filtros que podemos utilizar en MVC.
Tipo de Filtro Interface Clase Descripción

predeterminada
Authentication IAuthenticationFilter Se ejecuta antes que cualquier
otro filtro y antes que el código
en el método de Acción. Se utiliza
para especificar lógica de
autenticación por Acción, por
Controlador o Globalmente para
todos los controladores.
Authorization IAuthorizationFilter AuthorizeAttribute Se ejecuta después del filtro de
Autenticación y antes que el
código en el método de Acción.
Se utiliza para verificar los
derechos de acceso de usuario

para la Acción.
Action IActionFilter ActionFilterAttribute Se ejecuta antes y después del
código del método de Acción. Se
utiliza para realizar
procesamiento adicional tal como
proporcionar datos adicionales al
método de Acción, inspeccionar
el valor devuelto o cancelar la
ejecución del método de Acción.
Result IResultFilter ActionFilterAttribute Se ejecuta antes y después que el
método de Acción devuelva el
resultado. Se puede utilizar para
realizar procesamiento adicional
al resultado tal como la
modificación de la respuesta
HTTP.
Exception IExceptionFilter HandleErrorAttribute Se ejecuta sólo si el método de
Acción o algún otro Filtro
disparan una excepción.
Se utiliza para manejar errores.
Creando y Utilizando Filtros de Acción

Si tenemos una responsabilidad transversal en una aplicación Web, podemos implementarla
mediante la creación de un filtro de Acción personalizado o un filtro de resultado personalizado.
Podemos crear filtros personalizados mediante la implementación de la Interface IActionFilter o de

la interface IResultFilter. Sin embargo, la clase base ActionFilterAttribute implementa ambas
interfaces IActionFilter e IResultFilter por nosotros. Mediante la derivación de un filtro a partir de la
clase ActionFilterAttribute, podemos crear un filtro que pueda ejecutar código antes y después de
que se ejecute la Acción, y antes o después de que el resultado sea devuelto.
El siguiente código muestra un ejemplo de un filtro de acción que escribe texto a la ventana Output
de Visual Studio en el orden en el cual se ejecutan los eventos IActionFilter e IResultFilter.
public class CustomActionFilter : ActionFilterAttribute

{
// Este método es invocado por el Framework MVC antes de que
// el método de Acción se ejecute.
public override void OnActionExecuting(ActionExecutingContext filterContext)
{
WriteValues(filterContext.Controller,
filterContext.ActionDescriptor, filterContext.RouteData);
}
// Este método es invocado por el Framework MVC después de que

// el método de Acción se ejecute.
public override void OnActionExecuted(ActionExecutedContext filterContext)
{
WriteValues(filterContext.Controller,
filterContext.ActionDescriptor, filterContext.RouteData);
}
// Este método es invocado por el Framework MVC justo antes de que la

// instancia de ActionResult que es devuelta por la Acción sea invocada.
// Este método es útil para realizar acciones de Log y caché.
public override void OnResultExecuting(ResultExecutingContext filterContext)
{
WriteValues(filterContext.Controller, null,
filterContext.RouteData);
}
// Este método es invocado por el Framework MVC justo después de que la

// instancia de ActionResult que es devuelta por la Acción ha sido invocada.
// Este método es útil para realizar acciones de Log y caché.
public override void OnResultExecuted(ResultExecutedContext filterContext)
{
WriteValues(filterContext.Controller, null,
filterContext.RouteData);
}
// Método auxiliar para registrar los datos.

// Puede ser a un archivo, al log de Windows, a una Base de datos,
// a un servicio Web, a la ventana de salida, etc.
private void WriteValues(ControllerBase controllerBase,
ActionDescriptor actionDescriptor, System.Web.Routing.RouteData routeData,
[CallerMemberName] string methodName = "")
{
string Message = String.Format("Evento disparado: {0}", methodName);
Debug.WriteLine(Message, "CustomActionFilter");
string ActionName =
actionDescriptor != null ? actionDescriptor.ActionName : "";
Message = string.Format(
"Controller: {0}, Action: {1}",
controllerBase,
ActionName);
Debug.WriteLine(Message, "Controlador y Acción");
foreach (var KeyValue in routeData.Values)
{
Message = string.Format(
"key: {0}, Value: {1}", KeyValue.Key, KeyValue.Value);
Debug.WriteLine(Message, "Dato de la ruta");
}
}
}
Es posible crear también un filtro de autorización personalizado mediante la implementación de la

Interfaz IAuthorizationFilter. Sin embargo, la implementación predeterminada AuthorizeAttribute es
altamente útil y satisface casi todos los requerimientos de autenticación. Debemos tener cuidado
cuando remplacemos (override) el código de seguridad predeterminado en MVC o cualquier otro
modelo de programación. Si hacemos esto sin una comprensión completa de las implicaciones,
podemos introducir vulnerabilidades de seguridad que un usuario malicioso puede explotar.
Utilizando un filtro de Acción personalizado

Después de haber creado un filtro de Acción personalizado, podemos aplicarlo a cualquier método
de acción o clase en una aplicación Web, utilizando el nombre del filtro de acción para anotar al
método o clase.
En las siguientes líneas de código, CustomActionFilter es aplicado a la acción Index del controlador
Product.
[CustomActionFilter]
{
return View();
}
Programador Jr. de
MVC
Modulo 5: Desarrollando Vistas
ASP.NET MVC
Acerca del módulo

Las Vistas son uno de los tres componentes principales del modelo de programación MVC con las
cuales se puede construir la interfaz de usuario de la aplicación Web.
Una Vista es una mezcla de marcado HTML y código que se ejecuta en el servidor Web, por lo tanto,
es importante conocer la forma de escribir marcado HTML y el código que se encuentra en una Vista.
Al trabajar con Vistas, también es importante conocer la forma de utilizar las diversas clases de ayuda
conocidas como Helpers HTML que vienen integradas en MVC. De igual forma, es necesario conocer
la forma de crear Vistas Parciales, las cuales generan secciones de marcado HTML que pueden ser
reutilizadas en diversos lugares de nuestras aplicaciones Web.
El conocimiento de la creación de Vistas, nos ayudará a desarrollar páginas Web para presentar
contenido dinámico.
Objetivos
• Crear una Vista MVC y agregarle código Razor para mostrar datos a los usuarios.
• Utilizar Helpers HTML en una Vista para generar controles, enlaces y otros elementos HTML.
• Re-utilizar código Razor en diversos lugares de una aplicación.

• Lección 1: Creando Vistas con sintaxis Razor
• Lección 2: Utilizando HTML Helpers
• Lección 3: Reutilizando código en Vistas
Lección 1
Creando Vistas con sintaxis Razor
Cuando un usuario realiza una petición a una aplicación Web MVC, un Controlador responde.
Comúnmente, la Acción del Controlador crea una instancia de un objeto Modelo, por ejemplo, un
Producto. El controlador podría obtener el Producto consultando una base de datos o, mediante la
creación de un nuevo Producto o, realizando algún otro paso. Para mostrar el Producto, el
controlador crea una Vista y le pasa el Producto. La Vista construye una página Web insertando en el
marcado HTML las propiedades del Producto y, en algunas ocasiones, de otras fuentes. Finalmente,
MVC envía la página Web construida al navegador.
Para crear Vistas, es necesario comprender la forma en que MVC interpreta el código que colocamos
en las Vistas y cómo se construye una página HTML completamente. De manera predeterminada, el
motor de Vistas Razor, realiza esta interpretación, pero también es posible utilizar otros motores de
Vistas. Si nos tomamos el tiempo para entender Razor, descubriremos que Razor es un motor de
Vistas excelente y versátil que proporciona un alto grado de control sobre el código HTML generado.
Otros motores de Vistas tienen sintaxis muy diferente, que es posible que podamos preferir si hemos
trabajado con versiones anteriores de ASP.NET u otras tecnologías Web del lado del servidor, tales
como Ruby on Rails.
• Agregar Vistas a una aplicación Web MVC.

• Utilizar el símbolo @ en una Vista Razor para identificar el código del lado del servidor.
• Describir las características de la sintaxis Razor.
• Enlazar Vistas a clases Modelo para mostrar datos.
• Explicar cómo generar HTML que sea accesible a los visitantes con problemas de visión.
• Listar algunos motores de Vista alternativos al motor de Vistas Razor.
Agregando Vistas
En una aplicación MVC, por lo general hay un controlador para cada clase Modelo. Por ejemplo, una
clase Modelo llamada Product suele tener un controlador llamado ProductController que contiene
todas las acciones relevantes a los productos. Puede haber algunos controladores que no
corresponden a ninguna clase Modelo, tal como HomeController. Sin embargo, cada controlador
puede tener múltiples vistas. Por ejemplo, podríamos querer crear las Vistas siguientes para objetos
Product:
• Vista Details. La vista Details, puede mostrar el detalle de un producto, su precio, número de
catálogo, etc.
• Vista Create. La vista Create, puede permitir a los usuarios agregar un nuevo producto al
catálogo.
• Vista Edit. La vista Edit, puede permitir a los usuarios modificar las propiedades de un
producto existente.
• Vista Delete. La vista Delete, puede permitir a los usuarios eliminar un producto del catálogo.
• Vista Index. La vista Index puede mostrar todos los productos del catálogo.
Por convención, una aplicación web MVC crea todas las vistas dentro de la carpeta Views que se
encuentra en la raíz de la aplicación Web. Dentro de esta carpeta, hay una carpeta para cada
controlador en la aplicación. En el ejemplo anterior, la carpeta Views contendría una carpeta
Product. Esta carpeta contendría las vistas Details, Create, Edit, Delete e Index.
Cuando utilizamos el motor de vista Razor y el lenguaje C#, las vistas son archivos con una extensión
.cshtml. Si utilizamos el motor de vista Razor y el lenguaje Visual Basic, las vistas son archivos con una
extensión .vbhtml. Otros motores de vistas utilizan diferentes extensiones.
Cómo crear un archivo Vista

Se puede agregar un archivo Vista en Visual Studio mediante la realización de los siguientes pasos:
1. En la ventana Explorador de soluciones, seleccionamos la carpeta donde deseamos crear la

Vista. Por ejemplo, para un controlador llamado ProductController, MVC espera que los
archivos de Vistas sean ubicados en la carpeta Views/Product.
2. Damos clic con el botón derecho del mouse sobre la carpeta seleccionada, seleccionamos la
opción Add y a continuación seleccionamos la opción View.
Como alternativa, se puede crear un archivo de Vista para una acción particular de un controlador,
abriendo el archivo de código del controlador y dando clic con el botón derecho del mouse sobre la
acción del controlador. A continuación, seleccionamos la opción Add View para mostrar el cuadro de
dialogo Add View.
En la siguiente tabla se describen las propiedades que debemos completar en el cuadro de diálogo
Add View.
Propiedad Descripción
Nombre de la Vista Este es el nombre de la vista. A la vez, este es el nombre del
(View name) archivo de la Vista con la adición de la extensión apropiada. El
nombre que se elija debe coincidir con el nombre que devuelve
la acción del controlador correspondiente. Si la acción del
controlador no especifica el nombre de la Vista a utilizar, MVC
asume que el nombre de la Vista es el mismo nombre de la
acción del controlador.
Plantilla Una plantilla es una Vista básica que Visual Studio puede utilizar
(Template) para crear la Vista. Visual Studio puede crear plantillas simples
para las Vistas Create, Edit, Details, Delete y List para lo cual
debemos especificar un Modelo. Cuando tengamos más
experiencia en el uso de Vistas, podríamos preferir crear una
Vista a partir de la plantilla vacía en lugar de utilizar los otros
tipos de plantillas disponibles. Cuando utilizamos un Modelo, se
dice que estamos creando Vistas fuertemente tipadas. Al trabajar
con Vistas fuertemente tipadas, obtenemos ayuda adicional del
IntelliSense y comprobación de errores en Visual Studio a medida
que escribimos el código en la Vista.
Clase Modelo Si creamos una vista fuertemente tipada, es necesario especificar
(Model class) la clase Modelo que enlazaremos a la Vista. Visual Studio utilizará
esta clase cuando muestre avisos de IntelliSense y compruebe los
errores en tiempo de compilación.
Clase del contexto de Si estamos utilizando Entity Framework, podemos seleccionar la
datos clase que representa el contexto de datos asociado a la clase
(Data context class) Modelo.
Crear como una vista Una vista parcial es una sección de código Razor que se puede
parcial reutilizar en múltiples Vistas de la aplicación.
(Create as a partial view)
Referencia a Bibliotecas de Cuando se selecciona esta casilla de verificación, los enlaces a
scripts archivos de scripts comunes del lado del cliente son incluidos en
(Reference scripts la Vista. Estos enlaces incluyen la biblioteca JavaScript jQuery.
libraries)
Usar una página de diseño Una página de diseño o maestra puede ser utilizada para
(Use a layout or master imponer un diseño estándar personalizado a muchas páginas
page) dentro de la aplicación Web.
Diferenciando el código del servidor y el código HTML

El motor de Vistas Razor interpreta archivos de Vista y ejecuta cualquier código del lado del servidor
contenido en los archivos de Vista. Para hacer esto, Razor debe distinguir entre el código del lado del
servidor y el contenido HTML que deberá ser enviado al navegador sin sufrir cambios.
El motor de Vista Razor busca el símbolo @ para identificar el código del lado del servidor.
En el siguiente ejemplo de código, Razor ejecuta la línea con el símbolo @ como código C# en el
servidor Web. Este ejemplo de código muestra la hora actual del servidor.
<p>Razor no interpretará este texto como código

ya que no se encuentra el símbolo Arroba "at" </p>
<p>La hora actual del servidor es: </p>
@DateTime.Now.ToShortTimeString()
Una sección de código marcada con el símbolo @ es denominada como una expresión de código
Razor. En la sintaxis Razor, marcamos el inicio de una expresión de código Razor con el símbolo @,
pero a diferencia del motor de vista ASPX, Razor carece de un símbolo final de expresión. En lugar de
ello, Razor infiere el final de una expresión de código mediante el uso de un motor de análisis
(parsing) sofisticado.
Modificando la interpretación de Código y Contenido

Algunas veces, podríamos necesitar modificar la lógica que Razor utiliza para interpretar expresiones
de código. Por ejemplo, si deseamos mostrar un símbolo @ en el navegador, utilizamos @@. Razor
interpreta esto como una secuencia de escape y genera un único símbolo @. Esta técnica es útil para
representar direcciones de correo electrónico.
Razor tiene lógica sofisticada para distinguir entre el código y el contenido, y a menudo, el símbolo @
es todo lo que se requiere. Sin embargo, algunas veces, podemos encontrar que ocurre un error
porque Razor malinterpreta contenido como si fuera código. Para solucionar este tipo de errores,
podemos utilizar el delimitador @: que declara explícitamente una línea como contenido y no como
código.
Si deseamos declarar varias líneas como contenido, podemos utilizar la etiqueta <text> en lugar del
delimitador @:. Razor elimina las etiquetas <text> y </text> antes de devolver el contenido al
navegador.
En el siguiente ejemplo de código, Razor interpreta el delimitador @: para mostrar el texto plano.
@{
@: Este texto se encuentra en un bloque de código, pero el delimitador lo declara como contenido.
string Mensaje = "Hola, Mundo!!!!";
@: <div>
@Mensaje
@:</div>
}
Características de la Sintaxis Razor

Razor incluye muchas características útiles que podemos utilizar para controlar la forma en que
ASP.NET MVC genera la Vista como HTML. Estas características incluyen lo siguiente:
Comentarios Razor
Podemos incluir comentarios en nuestro código Razor para describirlo a otros desarrolladores en el
equipo. Esta es una técnica importante que mejora la productividad del desarrollador, facilitándole el
entendimiento del código.
Podemos declarar un comentario Razor utilizando el delimitador @*, como se muestra en el

siguiente código ejemplo.

@* Este texto es un comentario de código y no debe ser generado por el motor
de Vista Razor *@
Expresiones de Código Implícito y Paréntesis

Razor utiliza expresiones de código implícito para determinar las partes de una línea que son código
del lado del servidor. Por lo general, las expresiones de código implícito generan el código HTML que
deseamos, pero ocasionalmente, podríamos encontrar que Razor interpreta una expresión como
HTML cuando debería ser ejecutada como código del lado del servidor.
Por ejemplo, si la propiedad Product.UnitPrice contiene el valor 2.00, el siguiente código genera
"Precio Incluyendo impuestos: 2.00 * 1.16".
<span>Precio Incluyendo impuestos: @Model.UnitPrice * 1.16</span>
Podemos controlar y alterar este comportamiento mediante el uso de paréntesis para encerrar la
expresión que Razor evalúa. El uso de paréntesis nos permite delimitar expresiones de forma
explícita.
Por ejemplo, si la propiedad Product.UniPrice contiene el valor 2.00, el siguiente código genera
"Precio Incluyendo impuestos: 2.32".
<span>Precio Incluyendo impuestos: @(Model.UnitPrice * 1.16)</span>
Bloques de código Razor, Ciclos y Condiciones

Si deseamos escribir múltiples líneas de código del lado del servidor, lo podemos hacer sin anteponer
a cada línea el símbolo @ mediante el uso de un bloque de código Razor.
@{
// Razor interpreta todo el texto dentro de estas llaves como código del lado del
// servidor y no lo genera como código HTML.
}
Razor también incluye bloques de código que ejecutan sentencias condicionales o ciclos a través de
colecciones.
Por ejemplo, Razor ejecuta el siguiente código solamente si el valor de la propiedad booleana
Model.Discontinued devuelve true.
@if(Model.Discontinued)
{
<p>El producto se encuentra discontinuado</p>
}
Los ciclos Razor son útiles para crear Vistas de índices que muestren muchos objetos de una clase
Modelo particular. Una página de catálogo de productos, la cual muestra muchos de los productos de
la base de datos, es un buen ejemplo de una Vista de índice. Para implementar una Vista de índice,
una acción del controlador pasa una colección enumerable de objetos a la Vista.
Podemos iterar a través de todos los objetos de una colección enumerable utilizando el bloque de
código foreach.
@foreach(var item in Model)

{
<div>@item.ProductName</div>
}
Enlazando Vistas a Modelos

Muchas vistas Razor están diseñadas para mostrar propiedades de una clase Modelo específica. Si
enlazamos esas Vistas a la clase que ellas muestran, obtenemos ayuda adicional tal como la
retroalimentación de IntelliSense a medida que escribimos el código Razor. Algunas vistas podrían
mostrar propiedades de diferentes clases Modelo o bien, podrían no utilizar alguna clase Modelo.
Estas vistas no pueden ser enlazadas a una clase Modelo y son llamadas Vistas dinámicas. Es
importante entender cómo escribir código Razor para ambas situaciones.
Vistas fuertemente tipadas

En muchos casos, cuando creamos una Vista, sabemos que la acción del controlador pasará siempre
un objeto de una clase Modelo específica. Por ejemplo, si estamos escribiendo la Vista Display para
la acción Display en el controlador Product, sabemos por el código del método de la acción, que la
acción siempre pasará un objeto Product a la Vista.
En tales casos, podemos crear una Vista fuertemente tipada. Una Vista fuertemente tipada es una
Vista que incluye una declaración de la clase Modelo. Cuando declaramos la clase Modelo en la Vista,
Visual Studio nos ayuda con retroalimentación adicional IntelliSense y comprobación de errores
conforme escribimos el código. Esto es posible debido a que Visual Studio puede verificar las
propiedades que la clase Modelo incluye. Siempre que podamos, debemos crear Vistas fuertemente
tipadas para beneficiarnos de esta ayuda extra de IntelliSense y verificación de errores. Si seguimos
esto como una buena práctica, cometeremos menos errores de codificación. Una Vista fuertemente
tipada sólo trabaja con un objeto Modelo del mismo tipo que el que se declara en la Vista.
Para crear una vista fuertemente tipada en Visual Studio, seleccionamos desde el cuadro de diálogo
Add View, cualquiera de las plantillas disponibles distintas a Empty (without model) y, después,
elegimos la clase Modelo que deseamos enlazar a la Vista.
Por ejemplo, podemos elegir la clase Modelo Product de modo que Visual Studio pueda enlazar la
Vista a la clase Product agregando la siguiente línea de código en la parte superior del archivo de
Vista.
@model M05.Models.Product
Posteriormente en el archivo Vista, podemos acceder a las propiedades del objeto Modelo utilizando
el Helper Model. Por ejemplo, podríamos acceder al nombre del producto de la siguiente forma:
@Model.ProductName.
Enlazando a una lista Enumerable
Algunas Vistas muestran diferentes instancias de una clase Modelo. Por ejemplo, una página con el
catálogo de productos muestra diferentes instancias de la clase Modelo Product. En tales casos, la
acción del controlador pasa una lista de objetos Modelo a la Vista en lugar de un único objeto
Modelo. Aun en este caso, podemos crear una Vista fuertemente tipada, pero debemos utilizar una
declaración de Modelo diferente. Tradicionalmente, realizamos una iteración sobre los elementos de
la lista utilizando un ciclo foreach Razor.
El siguiente ejemplo, muestra una Vista de múltiples elementos con la declaración del Modelo y el
ciclo que enumera todos los objetos Product pasados por la acción.
@model IEnumerable<M05.Models.Product>
@foreach (var item in Model) {

<tr>
<td>
@Html.DisplayFor(modelItem => item.ProductName)
</td>
</tr>
}
Utilizando Vistas dinámicas

Algunas veces, la acción del controlador no pasa ninguna clase Modelo a la Vista. El ejemplo más
común de este tipo de Vistas sin clase Modelo es la página principal del sitio. En este caso, podemos
crear una Vista que no incluya la declaración @model en la parte superior de la página.
Por otra parte, en algunas situaciones, podríamos desear crear una Vista que pueda mostrar más de
una clase Modelo. Por ejemplo, podríamos desear crear una Vista que pueda mostrar tanto nuestros
propios productos como los productos de un proveedor externo. Estas clases modelo podrían
llamarse Product y ExternProduct. Algunas propiedades podrían ser similares, mientras que otras
podrían ser diferentes. Por ejemplo, la clase ExternProduct podría incluir una propiedad ExternID
adicional para almacenar la clave con la que el proveedor externo identifica el producto.
En estos casos, podemos crear una Vista dinámica. Una Vista dinámica incluye la declaración
@model dynamic en la parte superior de la página. Si lo deseamos, posteriormente podríamos
modificar la declaración @model para cambiar la Vista dinámica a una Vista fuertemente tipada.
Cuando creamos Vistas dinámicas, recibimos menos ayuda del IntelliSense y de verificación de
errores debido a que Visual Studio no puede comprobar las propiedades de la clase Modelo para
verificar el código. En tales escenarios, debemos asegurarnos de acceder sólo a las propiedades que
existan. Para acceder a una propiedad que pueda o no existir, tal como la propiedad
ExternProduct.Supplier del ejemplo anterior, debemos comprobar si la propiedad existe antes de
utilizarla.
Generando código HTML accesible

Internet es para todos, independientemente de cualquier discapacidad que un usuario pueda tener.
Además, si los usuarios con discapacidad no pueden navegar fácilmente por nuestro sitio Web,
podrían visitar sitios Web de la competencia y la empresa puede perder negocios. Por consiguiente,
debemos asegurar que las personas con discapacidades tales como aquellas que tienen una baja
visión o tienen problemas auditivos, puedan utilizar la aplicación Web y que sus navegadores Web
puedan analizar el contenido HTML que el sitio presenta. Debido a que las Vistas MVC son
responsables de generar el código HTML en una aplicación Web MVC, debemos generar código
HTML accesible creando Vistas que sigan guías de accesibilidad. Cuando escribimos Vistas, debemos
tener en mente los siguientes desafíos y mejores prácticas.
Los usuarios tienen diferentes necesidades dependiendo de sus capacidades y discapacidades. Por
ejemplo, consideremos los factores siguientes:
• Los usuarios con baja visión pueden utilizar un navegador estándar, pero pueden aumentar
el tamaño del texto con un ampliador de pantalla para que puedan leer el contenido.
• Los usuarios con problemas más fuertes de visión pueden utilizar un navegador con un
software de conversión de texto a voz o con un hardware de conversión de texto a Braille.
• Los usuarios con problemas para ver los colores apropiadamente pueden tener dificultades si
utilizamos un color diferente para resaltar el texto.
• Los usuarios con problemas auditivos podrían no ser capaces de acceder a los contenidos de
audio.
• Los usuarios con problemas de movimiento podrían tener dificultades para hacer clic en
elementos pequeños.
• Los usuarios con epilepsia podrían tener convulsiones si se le presenta el contenido
parpadeante.
Podemos asegurar que nuestro contenido sea accesible a la más amplia gama de usuarios si
seguimos las siguientes pautas:
• No basarse en el uso de diferentes colores para resaltar texto u otro contenido. Por ejemplo,
los enlaces deberían estar subrayados o en negritas para enfatizarlos a los usuarios con
problemas para distinguir colores.
• Proporcionar siempre un contenido alternativo equivalente al contenido visual y auditivo.
Por ejemplo, siempre completar el atributo alt para las imágenes. Se debe utilizar este
atributo para describir la imagen de manera que el software de texto a voz o hardware de
texto a Braille pueda generar palabras significativas para el usuario.
• Utilizar marcado HTML y Hojas de estilo para separar el contenido HTML y, el código
relacionado con la estructura y presentación. Esto sirve de ayuda al software de
interpretación de texto para generar el contenido a los usuarios sin que se confunda entre el
código estructural y el código de presentación. Por ejemplo, deberíamos aplicar las
siguientes mejores prácticas para mostrar el contenido en una página Web:
o Evitar el uso de tablas para mostrar el contenido. Se debe utilizar tablas solamente
para presentar contenido tabulado. Las tablas se pueden utilizar para mostrar
gráficos y los distintivos de una página Web, pero en un sitio accesible, se deben
utilizar hojas de estilo para posicionamiento del contenido. Los lectores de texto no
leen hojas de estilo.
o Evitar el uso de tablas anidadas. En una tabla anidada, una celda de la tabla contiene
otra tabla. Esto confunde a los lectores de texto ya que ellos leen cada celda de la
tabla en orden secuencial. Es probable que los usuarios se desorienten y no puedan
determinar qué celda se está leyendo y lo que significa.
o Evitar el uso de imágenes que incluyan texto importante. Los lectores de texto no
pueden generar el texto que se encuentre dentro de un archivo de imagen. En su
lugar, utilizar marcado HTML para representar ese texto.
World Wide Web Consortium (W3C) tiene un proyecto llamado la Iniciativa

de Accesibilidad Web (Web Accessibility Initiative - WAI), que promueve el
contenido Web accesible. Este proyecto ha publicado guías para crear
contenido Web accesible - Web Content Accessibility Guidelines (WCAG).
Las directrices completas pueden ser encontradas en el siguiente enlace:
Web Content Accessibility Guidelines 1.0

http://www.w3.org/TR/WCAG10/
En ASP.NET MVC, el desarrollador tiene el control total sobre el código HTML que el servidor Web
envía al navegador Web. Sin embargo, debemos entender los principios de accesibilidad para escribir
Vistas MVC accesibles. Debemos asegurar que todo el equipo de desarrollo está familiarizado con los
requerimientos de accesibilidad y las mejores prácticas relacionadas.
Motores de Vistas alternativos

Un motor de Vista es un componente del Framework MVC que es responsable de la localización de
los archivos de Vistas, la ejecución del código del lado del servidor que contienen las Vistas y, de la
generación del código HTML que el navegador puede mostrar al usuario.
Muchas Vistas trabajan con el motor de Vistas Razor. Razor es el motor de Vista predeterminado en
MVC y es un motor de Vistas altamente flexible y eficiente. Sin embargo, algunos desarrolladores
prefieren utilizar un motor de Vista diferente por las razones siguientes:
• Lógica de ubicación de Vistas. Razor asume que todas las Vistas se encuentran ubicadas en la
carpeta de nivel superior Views. Dentro de esta carpeta, Razor asume que cada controlador
tiene una carpeta separada. Por ejemplo, las Vistas de ProductController están ubicadas en
la carpeta Product dentro de Views. Razor busca también algunas Vistas en la subcarpeta
Shared. Estas Vistas pueden ser utilizadas por más de un controlador. Si no deseamos esta
lógica de ubicación de Vistas, podemos utilizar un motor de Vista alternativo, o crear un
motor de Vista personalizado.
• Sintaxis de Vistas. Cada motor de Vista utiliza una sintaxis diferente en los archivos de Vista.
Por ejemplo, en Razor, el símbolo @ delimita el código del lado del servidor. En contraste,
con el motor de Vistas ASPX, se utilizan los delimitadores <% %>. Esto es familiar para los
desarrolladores que han trabajado con Web Forms.
Es posible que se prefiera una sintaxis sobre otra por las siguientes razones:
o Experiencia. Las tecnologías con las que los desarrolladores hayan trabajado
previamente pueden facilitar el aprendizaje de la sintaxis de un motor de Vista
específico.
o Legibilidad. Algunos motores de Vista trabajan con archivos de Vista que son de fácil
lectura para cualquier persona que conozca HTML. Los diseñadores Web, que no
conocen C# u otros lenguajes de programación, pueden ser capaces de aprender las
sintaxis legibles.
o Concisión. Algunos motores de Vista trabajan con archivos de Vista que son breves y
generan HTML con cantidades relativamente pequeñas de código.
Motores de Vistas comunes

La siguiente tabla describe y compara cuatro motores de Vista populares.
Motor de Vista Descripción Ejemplo de código

Razor Este es el motor de Vistas predeterminado @model IEnumerable
en MVC. Es fácil de aprender para cualquier <MyWebSite.Models.Product>
persona que tenga
experiencia en HTML y C# <ul>
@foreach (var p in Model)
o Visual Basic. Visual Studio
{
proporciona buena retroalimentación <li> Nombre: @p.Name </ li>

IntelliSense para el código Razor y }
es compatible con las Pruebas Unitarias.
ASPX Este era el motor de Vistas predeterminado <%@Control Inherits =
para MVC 1 y 2. Es fácil de aprender para "System.Web.Mvc.ViewPage
los desarrolladores con experiencia en <IEnumerable <Product>>"
ASP.NET Web Forms y también es conocido %>
<ul>
como el motor de Vistas Web Forms.
<%Foreach (var p in model) {%>
Incluye buena retroalimentación <li> <%= p.Name%> </ li>
IntelliSense. <%}%>
NHaml NHaml es una versión .NET del motor de @type = IEnumerable <Product>
(pronuciado Vistas Haml utilizado con Ruby on Rails, un % ul
como enamel) competidor de ASP.NET MVC. Los - foreach (var p in model)
desarrolladores que han desarrollado sitios % li = p.Name
Web con Ruby on Rails pueden preferir este
motor de Vistas. Visual Studio no
proporciona retroalimentación IntelliSense
para este motor de Vistas. La sintaxis
NHaml es concisa y eficiente, pero a
menudo menos inteligible para
desarrolladores con poca experiencia.
Spark Este motor de Vistas utiliza archivos de <viewdata
Vista que son de fácil lectura y similar a los products="IEnumerable[[Product]]"/>
archivos estáticos HTML. Este diseño da <ul if="products.Any()">
como resultado archivos de Vista que <li each="var p in products"> $
{p.Name}
pueden ser leídos por cualquier persona
</ li>
que conozca HTML. Podemos obtener </ ul>
soporte IntelliSense para Spark en Visual
Studio.
Para obtener más información acerca de motores de vista alternativos,

podemos visitar los siguientes enlaces:
ASP.NET MVC View Engine Comparison

http://go.microsoft.com/fwlink/?LinkID=288956&clcid=0x409
Developer Review - Four ASP.NET MVC View Engines

Creación de Motores de Vista Personalizados

Nosotros también podemos crear nuestros propios motores de Vista para implementar lógica
personalizada de ubicación de Vistas o para implementar sintaxis personalizada de los archivos de
Vista. Es raro crear motores de Vista personalizados debido a que los motores de Vista existentes son
potentes, flexibles y fáciles de aprender. La lógica predeterminada para la búsqueda de archivos de
Vista también es simple y rara vez necesita modificación. Para crear un motor de Vista personalizado,
debemos seguir los siguientes pasos:
1. Crear una clase Vista. Esta clase debe implementar la interface IView y debe implementar un
método Render. Debemos escribir la lógica personalizada en el método Render para
interpretar la sintaxis personalizada. Es normal que este código incluya expresiones regulares
y algún otro código sofisticado de análisis de cadenas.
2. Crear una clase motor de Vistas. Esta clase debe heredar de la clase
VirtualPathProviderViewEngine e incluir los métodos CreateView y CreatePartialView. Al
heredar de la clase ViewPathProviderViewEngine, es posible modificar la propiedad
ViewLocationFormat para implementar una lógica personalizada de localización de Vistas.
3. Registrar el motor de Vistas personalizado. Para registrar el motor de Vistas personalizado

con MVC, debemos invocar al método ViewEngines.Engines.Add en el archivo Global.asax.
Para obtener más información acerca de la creación de motores de Vista

personalizados en ASP.NET MVC, podemos visitar el siguiente enlace:
Creating a Custom View Engine in ASP.NET MVC

Lección 2
Utilizando HTML Helpers
El Framework ASP.NET MVC incluye muchas funciones de ayuda HTML conocidas comúnmente como
Helpers y que podemos utilizar en las Vistas. Los Helpers HTML son métodos C# que podemos
invocar para generar valores, etiquetas y controles de entrada tales como cuadros de texto.
Los Helpers incluyen lógica común que nos facilita la generación de código HTML para las
propiedades de clases Modelo MVC y para otras tareas. Algunos Helpers HTML examinan la
definición de propiedades de clases Modelo para posteriormente generar el código HTML apropiado.
Algunos Helpers HTML invocan acciones del Controlador y otros validan los datos de entrada del
usuario. También podemos crear Helpers HTML personalizados. Es importante conocer el Helper
HTML apropiado para utilizar en cualquier situación y la forma de pasar los parámetros correctos a
los Helpers HTML correspondientes.
• Utilizar los Helpers Html.ActionLink y Url.Action para invocar una acción de un Controlador.
• Utilizar los Helpers Html.DisplayNameFor y Html.DisplayFor para mostrar el valor de una
propiedad de una clase de Modelo.
• Utilizar los Helpers Html.LabelFor y Html.EditorFor para generar un control editor para una
propiedad de una clase Modelo.
• Utilizar el Helper Html.BeginForm para generar un formulario para una acción de un
Controlador.
• Utilizar Helpers HTML para validar los datos escritos por los usuarios.
• Utilizar distintos Helpers HTML para construir la interfaz de usuario de una aplicación Web.
Utilizando Helpers Action

Los Helpers HTML son simples métodos que en la mayoría de los casos devuelven una cadena de
caracteres. Esta cadena es una pequeña sección de código HTML que el motor de Vista puede
insertar en el archivo de Vista para generar la página Web completa.
El uso de los Helpers HTML es opcional. Si lo deseamos, podemos escribir Vistas que generen
cualquier tipo de contenido HTML sin necesidad de utilizar Helpers HTML. Sin embargo, los Helpers
HTML hacen más fácil la tarea de manejo de contenido HTML mediante la generación de cadenas
HTML comunes para escenarios utilizados frecuentemente. Los Helpers Html.ActionLink y Url.Action
permiten generar código HTML para invocar acciones de Controladores.
El Helper Html.ActionLink
Cuando el usuario realiza una petición a una aplicación Web MVC, el Framework ASP.NET MVC
reenvía la petición al Controlador y a la acción correcta, proporcionando además los parámetros
correctos. Es posible que los usuarios realicen tales peticiones escribiendo una dirección URL en la
barra de direcciones de un navegador Web, pero rara vez conocen el nombre del Controlador, la
acción, o los parámetros. En lugar de eso, por lo general hacen clic en un enlace.
El Helper Html.ActionLink puede ser utilizado para generar enlaces a acciones. El asistente devuelve
un elemento <a> con el valor correcto del parámetro href cuando los usuarios hacen clic en un
enlace de una página Web.
En el siguiente ejemplo, el asistente Html.ActionLink genera un elemento <a> que llama a la acción
Display en el Controlador Product y pasa un entero para el identificador del producto.
@Html.ActionLink("Display Product", "Display", "Product", new { id=5}, null)
De manera predeterminada, el ejemplo genera el siguiente HTML.
<a href="/Product/Display/5">Display Product</a>
Notemos que pasamos los parámetros al Helper mediante el uso de un objeto anónimo. De esta
manera, podemos pasar múltiples parámetros.
El Helper Html.ActionLink trabaja con el motor de enrutamiento para generar el URL correcto para el
enlace. Existen varias sobrecargas del Helper ActionLink que nos permiten utilizarlas para invocar a
acciones de los Controladores que necesitemos.
El Helper Url.Action
El Helper Url.Action genera un URL utilizando el motor de enrutamiento sin generar el elemento <a>.
Por ejemplo, podemos utilizar el Helper Url.Action para proporcionar el valor del atributo src de un
elemento <img> o <script>. Este Helper será útil siempre que queramos obtener un URL a una acción
de un Controlador sin la generación de un hipervínculo.
El siguiente ejemplo muestra la forma de presentar una imagen mediante una llamada al Helper
Url.Action dentro del atributo src de un elemento img.
<img alt="Esta imagen viene de una Acción"

src="@Url.Action("GetImage", "Product", new {id=5} )"/>
Para obtener más información acerca de los Helpers Html.ActionLink y Url.Action,

se recomienda visitar los siguientes enlaces:
LinkExtensions.ActionLink Method
UrlHelper.Action Method
Utilizando Helpers Display

MVC incluye diversos Helpers que muestran propiedades de las clases Modelo. Podemos utilizar esos
Helpers para construir Vistas que muestren detalles de las clases Modelo. Html.DisplayNameFor
genera el nombre de una propiedad de una clase Modelo. Html.DisplayFor genera el valor de una
propiedad de una clase Modelo. Ambos Helpers examinan la definición de la propiedad en la clase
del Modelo, incluyendo las anotaciones de visualización de datos para asegurar que generan el
código HTML más apropiado.
El Helper Html.DisplayNameFor
Utilizamos el Helper Html.DisplayNameFor para generar el nombre de una propiedad de la clase
Modelo que se desea mostrar. Si la Vista es fuertemente tipada, Visual Studio verifica si la clase
Modelo contiene una propiedad con el nombre correcto conforme escribimos el código. Si la Vista no
es fuertemente tipada, debemos asegurarnos de utilizar una propiedad que exista antes de usarla.
Especificamos la propiedad de la clase Modelo al Helper Html.DisplayNameFor mediante una
expresión lambda.
El siguiente ejemplo, genera el nombre a mostrar de la propiedad ProductName utilizando el Helper

HTML Html.DisplayNameFor.
@Html.DisplayNameFor(m => m.ProductName)
El texto generado por el Helper Html.DisplayNameFor depende de la clase Modelo. Si utilizamos una
anotación Display para darle un nombre más descriptivo a una propiedad, entonces
Html.DisplayNameFor utilizará el valor de la anotación Display, de lo contrario, generará el nombre
de la propiedad.
El Helper Html.DisplayFor
El Helper Html.DisplayFor considera cualquier anotación de visualización que especifiquemos en la
clase Modelo y posteriormente genera el valor de la propiedad. Si utilizamos la anotación
DisplayFormat en la clase Modelo con DataFormatString establecido en "{0:c}", entonces el Helper
Html.DisplayFor asegura que el valor de la propiedad UnitPrice sea mostrado en formato de
moneda.
En el siguiente ejemplo, el asistente Html.DisplayFor es utilizado para generar una cadena con
formato de moneda.
@Html.DisplayFor(m => m.UnitPrice)
El Helper BeginForm
Para aceptar la entrada de datos de los usuarios, debemos proporcionar un formulario en la página
Web. Un formulario típico consiste en un conjunto de etiquetas y controles de entrada. Las etiquetas
indican al usuario la propiedad para la que debe proporcionar un valor. Los controles de entrada
permiten al usuario introducir un valor. Los controles de entrada pueden ser cuadros de texto,
casillas de verificación, botones de opciones, selectores de archivos, listas desplegables, u otros tipos
de control. Por lo general, en los formularios podemos encontrar un botón Enviar y un botón
Cancelar.
Generando Formularios HTML

Para incorporar un formulario en HTML, debemos iniciar con un elemento <form> en la página Web
HTML. Todas las etiquetas y controles de entrada deben ser ubicados dentro del elemento <form>.
En una Vista MVC, podemos utilizar el Helper Html.BeginForm() para generar este elemento y
establecer la acción del Controlador a la que el formulario enviará la información.
También podemos especificar el método HTTP que el formulario utilizará para enviar datos. Si el
formulario utiliza el método POST, que es el valor predeterminado, el navegador enviará los valores
del formulario al servidor Web en el cuerpo del formulario. Si el formulario utiliza el método GET, el
explorador enviará los valores del formulario al servidor Web en la cadena de consulta en el URL.
En el código HTML generado, el elemento <form> debe estar cerrado con una etiqueta </form>. En
las Vistas Razor, podemos asegurar que el elemento <form> este cerrado mediante el uso de un
bloque de código @using. Razor genera el tag </form> en la llave de cierre del bloque de código
using.
El siguiente ejemplo muestra la forma de generar un formulario que envía datos a la acción Create de
ProductController. El formulario utiliza el verbo HTTP POST.
@using(Html.BeginForm("Create", "Product", FormMethod.Post))

{
}
Utilizando Formularios para subir archivos

En HTML, si deseamos permitir a los usuarios del sitio Web subir archivos, debemos utilizar un
formulario HTML con propiedades especiales. Específicamente, el elemento <form> debe incluir el
atributo enctype establecido con el valor multipart/form-data. Adicionalmente, el formulario debe
utilizar el verbo HTTP POST.
Podemos especificar atributos adicionales para el elemento <form> pasándolos en un parámetro

htmlAttributes a través de un tipo anónimo. Este es el método recomendado a utilizar para agregar
el atributo enctype.
El siguiente ejemplo muestra la forma de generar un formulario para subir archivos. Los datos
proporcionados por el usuario, incluyendo los archivos, son enviados a la acción UploadPhoto del
Controlador Category. El formulario utiliza el verbo POST y establece el atributo enctype.
@using(Html.BeginForm("UploadPhoto", "Category", FormMethod.Post,

new {enctype="multipart/form-data"}))
{
<input type="file" name="file"/>
/* Poner controles de entrada aquí */
<input type="submit" value="ok"/>

}
Utilizando Helpers de edición

Dentro de los formularios HTML, existen distintos controles de entrada HTML que podemos utilizar
para recopilar datos de los usuarios. En las vistas Razor, los Helpers Html.LabelFor y Html.EditorFor
facilitan la generación de los controles de entrada más apropiados para las propiedades de una clase
Modelo. Para entender la forma en que estos Helpers generan código HTML, primero debemos
entender los controles de entrada HTML. En la siguiente tabla se describen algunos de los controles
HTML comunes.
Control Ejemplo Descripción

Caja de texto <input type="text" Un cuadro de texto de una sola línea en la cual el
name="ProductName"/>
(TextBox) usuario puede proporcionar un texto. El atributo
name es utilizado para identificar el valor
proporcionado en la cadena de consulta
(QueryString) o para enviar datos del formulario
utilizando el método POST.
Caja de texto de <textarea Una caja de texto de múltiples líneas en la cual el
name="Description"
múltiples líneas rows="20" cols="80">
usuario puede proporcionar cadenas de
(Multiline </textarea> caracteres largas.
TextBox)
Casilla de <input Una Casilla de verificación que envía un valor
type="checkbox"
verificación name="Discontinued">
booleano
(CheckBox) Discontinuado
Para obtener más información sobre todos los elementos de formulario HTML, se
recomienda visitar el siguiente enlace:
The INPUT element

El Helper Html.LabelFor
El Helper Html.LabelFor es similar al Helper Html.DisplayNameFor ya que genera el nombre de la
propiedad que nosotros especifiquemos tomando en cuenta la anotación DisplayName si esta es
especificada en la clase Modelo. Sin embargo, a diferencia del Helper Html.DisplayNameFor, el
asistente Html.LabelFor genera un elemento <label>.
El siguiente ejemplo genera un elemento <label> para la propiedad ProductName.
@Html.LabelFor(model=>model.ProductName)
El Helper Html.EditorFor
El Helper Html.EditorFor genera elementos HTML <input> y otros controles de formulario para las
propiedades de una clase Modelo. Este Helper genera el elemento más adecuado para cada tipo de
dato de la propiedad. Por ejemplo, el Helper Html.EditorFor genera <input type="text"> para una
propiedad de tipo string. Pero si la propiedad de tipo string está anotada con
[DataType(DataType.MultilineText)], el Helper Html.EditorFor genera un elemento <textarea> en su
lugar. La tabla siguiente describe el código HTML que Html.EditorFor genera para diferentes tipos de
propiedades de las clases Modelo.
Control Propiedad de la clase modelo Elemento HTML generado por

EditFor()
Caja de public string ProductName{get;set;} <input class="text-box single-line"
id="ProductName" name="ProductName"
texto type="text" value="" />
(TextBox)
Caja de [DataType(DataType.MultilineText)] <textarea class="text-box multi-
Public string ProductName{get;set;} line" id="ProductName"
texto de name="ProductName">
múltiples </textarea>
líneas
(Multiline
TextBox)
Casilla de [Display(Name="Producto <input class="check-box" data-
discontinuado")] val="true" data-val-required="The
verificación
public bool Discontinued{get;set;} Producto discontinuado field is
(CheckBox) required." id="Discontinued"
name="Discontinued" type="checkbox"
value="true" />
<input name="Discontinued"
type="hidden" value="false" />
Texto <input data-val="true" data-val-
number="The field ProductID must be
oculto [HiddenInput(DisplayValue=false)]
a number." data-val-required="The
Hidden public int ProductID { get; set; }
ProductID field is required."
id="ProductID" name="ProductID"
type="hidden" value="0" />
Si la acción pasa un objeto Modelo existente a la vista, el Helper Html.EditorFor también llena cada
control con el valor actual de cada propiedad.
El siguiente ejemplo genera una casilla de verificación para la propiedad Discontinued.
@Html.EditorFor(model=>model.Discontinued)
Utilizando Helpers de Validación

Cuando solicitamos información a los usuarios, a menudo requerimos que los datos sean
proporcionados en un determinado formato para su posterior uso en la aplicación Web. Por ejemplo,
podríamos querer asegurar que los usuarios introduzcan un valor para la propiedad Apellidos.
También podríamos querer asegurar que los usuarios introduzcan una cuenta de correo electrónico
válida para la propiedad Correo. Podemos establecer estos requerimientos mediante el uso de
anotaciones de validación de datos en la clase Modelo. En las acciones del Controlador podemos
comprobar el valor de la propiedad ModelState.IsValid para determinar si un usuario ha introducido
datos válidos.
Cuando los usuarios envían un formulario, en caso de que hayan proporcionado datos no válidos, la
mayoría de los sitios Web muestran mensajes de validación. Estos mensajes son frecuentemente
resaltados en rojo, pero se pueden utilizar otros colores o formatos. A menudo, hay un resumen de
validación en la parte superior de la página tal como "Por favor ingrese la información válida para
los siguientes campos: Apellidos, Dirección de correo electrónico". El formulario puede mostrar
mensajes detallados de validación junto a cada control en el que el usuario ha introducido datos no
válidos o resaltar con un asterisco los problemas en los datos proporcionados por el usuario.
Cuando una Vista MVC despliegue un formulario, podemos mostrar fácilmente mensajes de
validación mediante el uso de Helpers de validación. Los Helpers de validación generan código HTML
sólo cuando los usuarios han introducido datos no válidos.
El Helper Html.ValidationSummary
Utilizamos el Helper Html.ValidationSummary para generar un resumen de todos los datos no
válidos en el formulario. Este Helper es usualmente invocado en la parte superior del formulario.
Cuando el usuario envía datos no válidos, los mensajes de validación son mostrados para cada campo
no válido en una lista con viñetas. Podemos controlar los mensajes de validación en la clase Modelo
utilizando la siguiente sintaxis en la anotación:
[Required(ErrorMessage="Debe proporcionar el nombre del producto")]
El siguiente ejemplo genera un resumen de mensajes de validación.
@Html.ValidationSummary("Por favor ingrese información válida para los siguientes

campos:")
El asistente Html.ValidationMessageFor
Utilizamos el asistente Html.ValidationMessageFor para generar mensajes de validación junto a cada
control de entrada de datos en el formulario.
El siguiente ejemplo genera un mensaje de validación para la propiedad ProductName de la clase

Modelo.
@Html.ValidationMessageFor(model=>model.ProductName)
Codificación HTML
Por razones de seguridad, cuando Razor ejecuta cualquier código de servidor que devuelva una
cadena de texto, este codifica la cadena como HTML antes de devolverla al navegador. Por ejemplo,
podríamos tener una clase modelo Comentario con las siguientes propiedades:
• Asunto. Esta propiedad contiene el título para el comentario como una simple cadena sin
información de formato.
• ComentarioHtml. Esta propiedad contiene el texto mismo del comentario. Lo más importante
es que incluye la información de formato como etiquetas HTML. Por ejemplo, podría incluir
etiquetas <i> para poner una palabra en cursiva.
Si utilizamos la sintaxis normal @Model.ComentarioHtml para devolver el texto formateado del

comentario, Razor codifica "<" como "&lt" y ">" como "&gt" en el código fuente HTML. Esto resulta
en que el usuario ve "<i>" en la página Web. Este no es el comportamiento que esperamos ya que lo
que queremos es que los usuarios vean el texto en cursiva.
Para representar texto sin codificación HTML, podemos utilizar el Helper Html.Raw. Por ejemplo,
podemos utilizar @Html.Raw(Model.ComentarioHtml).
Razor codifica texto como HTML por una razón específica de seguridad: para detener a usuarios
malintencionados de inyectar código malicioso en la aplicación Web. Si este tipo de ataques tienen
éxito, el código inyectado puede eludir las restricciones de seguridad en la aplicación Web y negar el
servicio a los usuarios, o pueden acceder a información sensible. Por lo tanto, sólo se debe utilizar el
asistente Html.Raw cuando sea absolutamente necesario. Además, si debemos utilizar el asistente
Html.Raw, debemos asegurar de que no opere en cadenas no verificadas introducidas por los
usuarios.
Creación de Helpers HTML personalizados

Hasta este momento, hemos visto diversos Helpers que podemos utilizar en nuestras Vistas. Hemos
visto Helpers Action, Helpers Display, Helper BeginForm, Helpers de Edición y Helpers de Validación.
Existen además otro tipo de Helpers que permiten generar controles Checkbox, Dropdown, campos
ocultos, ListBox, elementos para leer passwords, Radio Button, TextArea y TextBox entre otros. Sin
embargo, podría ser que necesitemos algún Helper para generar código personalizado como por
ejemplo un Helper que nos genere el contenido HTML mostrando la fecha actual del servidor o el
contenido de una lista de instancias de clase Modelo en una tabla. En estos casos, podemos crear
nuestros propios Helpers.
Para crear un Helper personalizado utilizamos la característica de métodos de extensión para

extender la clase HtmlHelper.
El siguiente ejemplo muestra un método de extensión para crear un Helper que devuelve la hora
actual del servidor.
// El método de extensión debe ser estático y típicamente devuelve

// contenido HTML. Para evitar que Razor trate de codificarlo a HTML
// nuevamente, devolvemos un tipo MvcHtmlString
public static MvcHtmlString CurrentTime(this HtmlHelper helper)
{
// Generamos el contenido HTML a devolver
return new MvcHtmlString(DateTime.Now.ToShortTimeString());
}
Para utilizar el Helper en una Vista primero debemos importar su espacio de nombres como en el
siguiente ejemplo:
@using M0502.CustomHelpers
Podemos utilizar el helper de la siguiente manera:
@Html.CurrentTime()
Este es un ejemplo sencillo de Helper, pero podemos crear Helpers con código más sofisticado.
El siguiente ejemplo muestra un Helper que permite generar el código que muestra los datos de un
Modelo en una Tabla HTML. El Modelo en este caso representa una colección.
public static MvcHtmlString DataGridFor(this HtmlHelper helper, IEnumerable items)

{
var sb = new StringBuilder();
if (items != null)
{
sb.Append("<table class=\"DataGrid\">");
string[] PropertyNames = null;
// Recorremos cada elemento de la Colección

bool Alt = false; // Para diferenciar renglones
foreach (var item in items)
{
if (PropertyNames == null)
{
// Obtener los nombres de las propiedades de los elementos de la
// colección que sean de Tipo Valor o del Tipo String
PropertyNames =
item.GetType().GetProperties()
.Where(p => !p.PropertyType.IsClass ||
p.PropertyType == typeof(string))
.Select(p => p.Name).ToArray();
// Agregar el encabezado a la tabla

sb.Append("<tr>");
foreach (var e in PropertyNames)
{
string DisplayName =
ModelMetadataProviders.Current
.GetMetadataForProperty(null, item.GetType(), e)
.DisplayName; // Obtenemos la metadata del Modelo
DisplayName = DisplayName ?? // Si no hay metadata DisplayName
e; // mostrar el nombre del campo
sb.AppendFormat("<th>{0}</th>", DisplayName);
}
sb.Append("</tr>");
}
// Agregar los valores del registro actual
// Agregamos class="Alt" para renglones Alternos
sb.AppendFormat("<tr {0}>", Alt ? "class=\"Alt\"" : "");
foreach (var p in PropertyNames)
{
sb.AppendFormat("<td>{0}</td>",
item.GetType().GetProperty(p).GetValue(item));
}
sb.Append("</tr>");
Alt = !Alt; // Para alternar renglones y poder colorear con CSS
}
sb.Append("</table>");
}
return new MvcHtmlString(sb.ToString());
}
En una Vista podemos utilizar el Helper de la siguiente manera:
@Html.DataGridFor(Model)
Lección 3
Reutilizando código en Vistas
En una aplicación Web, con frecuencia generamos bloques similares de contenido HTML en
diferentes páginas. Por ejemplo, en una aplicación Web de comercio electrónico, es posible que
queramos mostrar los productos más populares en la página de inicio, en la primera página del
catálogo de productos, en la parte superior de la página de búsqueda de productos, y tal vez en otros
lugares.
Para generar tal contenido HTML en una aplicación MVC, podríamos copiar y pegar el código desde
una Vista Razor hacia otras. Sin embargo, más adelante, para cambiar la visualización de los
principales productos en el proyecto, tendríamos que hacer los mismos cambios en muchos lugares.
Una mejor práctica es utilizar una Vista Parcial. Una Vista Parcial genera una sección de contenido
HTML que puede ser insertado en muchas otras Vistas en tiempo de ejecución.
Debido a que la Vista parcial es un simple archivo que es reutilizado en varios lugares, cuando
implementamos un cambio en un solo lugar, los cambios son actualizados en otras ubicaciones de la
aplicación Web. Las Vistas Parciales incrementan la capacidad de administración de las aplicaciones
Web MVC y facilitan una presentación consistente de contenido a través de una aplicación Web.
• Describir la forma en que las Vistas Parciales permiten reutilizar código Razor.
• Crear Vistas Parciales en una aplicación Web MVC.
• Utilizar Vistas Parciales en una aplicación Web MVC.
Creando Vistas Parciales

Podemos utilizar Vistas Parciales para generar código HTML idéntico o similar en diferentes lugares
de nuestra aplicación Web. Consideremos una aplicación Web en la cual los usuarios puedan realizar
comentarios sobre los productos. En la vista Product, al final de la página, deseamos mostrar los
comentarios para ese artículo específico. De manera similar, en la página principal, deseamos
mostrar los comentarios más populares sobre cualquier producto. Podemos construir una simple
vista parcial de comentarios para este escenario de la siguiente manera:
1. Creamos una Vista Parcial que muestre una colección de comentarios en el formato
requerido.
2. Creamos una acción de Controlador que obtenga los comentarios más populares y luego los
pase a la Vista Parcial.
3. Creamos otra acción de Controlador que utilice el ID del producto para encontrar los
comentarios específicos a ese producto. La acción del Controlador pasa entonces esta
colección de comentarios a la Vista Parcial.
4. Finalmente, invocamos a las acciones apropiadas desde la página principal y desde la Vista de
productos.
Debido a que la Vista Parcial genera una colección de comentarios, podemos reutilizarla para varias
situaciones pasándole diferentes colecciones desde acciones de Controladores.
Creando y Nombrando Vistas Parciales

En Visual Studio, podemos crear una Vista Parcial utilizando el cuadro de diálogo Add View de la
misma manera en que creamos cualquier otra Vista. Debemos asegurarnos de seleccionar la casilla
de verificación Create as a Partial View. Debido a que las vistas parciales generan una pequeña
sección de código HTML en lugar de una página Web completa, Visual Studio no agrega a la Vista
Parcial etiquetas como <head> y <body>. Por convención, las Vistas Parciales son nombradas con un
carácter de subrayado como prefijo, por ejemplo, _CommentsList.cshtml. Esta convención es
opcional, pero es muy útil para distinguir Vistas Parciales en el Explorador de soluciones.
Las Vistas Parciales a menudo son creadas dentro de la carpeta Views/Shared del sitio. Las Vistas de
la carpeta Shared son accesibles a varios Controladores, mientras que las Vistas de la carpeta
Views/Comment son accesibles sólo desde el Controlador CommentController.
Vistas parciales fuertemente tipadas y dinámicas

Similar a otras Vistas, podemos crear Vistas Parciales fuertemente tipadas si estamos seguros de que
la Vista Parcial siempre mostrará la misma clase Modelo. Visual Studio puede proporcionar
retroalimentación IntelliSense más informativa y realizar comprobación de errores con las Vistas
Parciales fuertemente tipadas en comparación con otros tipos de Vistas. Una Vista fuertemente
tipada tiene la declaración de la directiva @model al inicio del archivo. Alternativamente, podemos
crear una Vista Parcial dinámica si no estamos seguros de que la Vista Parcial siempre mostrará la
misma clase Modelo. Podemos crear Vistas Parciales dinámicas omitiendo la declaración de la
directiva @model.
En el siguiente ejemplo de una Vista Parcial, podemos ver la declaración @model que hace que la
Vista Parcial sea fuertemente tipada. También podemos ver que la Vista Parcial sólo genera una lista
sin ordenar y no una página Web HTML completa tal y como lo indican las siguientes líneas de
código.
@model IEnumerable<M0502.Models.Comment>
<ul>
@foreach(var item in Model)
{
<li>
Asunto: @item.Subject
</li>
}
</ul>
Utilizando Vistas Parciales

Además de saber cómo crear Vistas Parciales, necesitamos saber cómo utilizarlas dentro de otras
muchas Vistas en el sitio. Podemos reutilizar Vistas Parciales mediante el uso de los Helpers HTML
Html.Partial y Html.Action.
El Helper Html.Partial
Podemos utilizar el Helper Html.Partial para generar una Vista Parcial dentro de otro archivo de
Vista. MVC inserta dentro de la Vista padre, el código HTML que la Vista Parcial genera y devuelve la
página Web completa al navegador. El primer parámetro es el nombre del archivo de Vista Parcial sin
su extensión de archivo. El segundo parámetro opcional es un objeto Modelo que la Vista Parcial
utilizará para generar el código HTML. Este es el mismo objeto Modelo que la Vista padre utiliza
debido a que otros objetos Modelo no están disponibles en este contexto.
Las siguientes líneas de código invocan a la Vista Parcial _Comments.cshtml sin pasar un objeto
Modelo.
@Html.Partial("_CommentsList")
Recordemos que podemos utilizar las colecciones ViewBag y ViewData para pasar datos entre el
método de acción y la Vista. Una Vista padre comparte los mismos objetos ViewBag o ViewData con
la Vista Parcial. Esta es una buena forma de compartir datos entre la acción del Controlador, la Vista
y la Vista Parcial.
El Helper Html.Action
Podemos pasar un objeto Modelo desde la Vista padre a una Vista Parcial cuando utilizamos
Html.Partial. Sin embargo, la Vista padre sólo puede pasar el mismo objeto Modelo disponible en la
Vista padre. Algunas veces, desde la Vista Parcial, podríamos querer utilizar un objeto Modelo
diferente al de la Vista padre. En estos casos, podemos utilizar el Helper Html.Action. Este invoca a
un método de acción que devuelve la Vista Parcial correcta. El método de acción puede crear una
instancia de cualquier clase Modelo.
Consideremos una Vista Product que muestra el texto y el título de un objeto Product. Queremos
mostrar comentarios al final de esta Vista en una Vista Parcial. Podemos utilizar el Helper
Html.Action para invocar una acción en el Controlador Comment que devuelva tal Vista Parcial. La
Vista Parcial puede trabajar con una colección de objetos Comment.
En el siguiente ejemplo, el Helper Html.Action invoca a una acción en el Controlador

CommentController y pasa el ID del objeto Modelo Producto actual.
@Html.Action("_CommentListByID", "Comment", new { id=Model.ProductID})
Programador Jr. de
MVC
Modulo 6: Probando, Depurando y
Solucionando problemas en
aplicaciones Web ASP.NET MVC
Acerca del módulo

Los sistemas de software tales como las aplicaciones Web, en ocasiones pueden ser complejos y
pueden requerir múltiples componentes que frecuentemente son creados por distintos
desarrolladores que trabajan en grupo.
Las suposiciones incorrectas, el entendimiento inexacto, los errores de codificación y muchas otras
fuentes, pueden crear “bugs” que dan como resultado excepciones o comportamiento inesperado.
Para mejorar la calidad de nuestras aplicaciones Web y crear experiencias de usuario satisfactorias,
debemos identificar y eliminar “bugs” de cualquier fuente. Tradicionalmente, la mayoría de las
pruebas se realizan al final del proyecto de desarrollo, sin embargo, se ha aceptado ampliamente que
la realización de pruebas a través de todo el ciclo de vida del proyecto mejora la calidad y asegura
que no haya “bugs” en el software en producción.
Es necesario entender cómo realizar pruebas de los pequeños componentes de nuestra aplicación
Web para asegurar que estos funcionen como lo esperamos antes de incorporarlos dentro de la
aplicación Web completa. También necesitamos conocer cómo utilizar las herramientas disponibles
en Microsoft Visual Studio para depurar y dar seguimiento a excepciones cuando estas aparezcan.
Objetivos
• Ejecutar pruebas unitarias sobre los componentes MVC, tales como clases Modelo y
Controladores.
• Localizar “bugs” potenciales.
• Construir una aplicación MVC que maneje excepciones de una manera confiable y robusta.

• Lección 1: Realizando pruebas unitarias de los componentes MVC.
• Lección 2: Implementando una estrategia para el manejo de Excepciones.
Lección 1
Realizando pruebas unitarias de los componentes MVC
Una Prueba Unitaria es un procedimiento que crea una instancia de un componente que hemos
creado, invoca un aspecto de las funcionalidades del componente y verifica que el componente
responde correctamente de acuerdo con el diseño.
En la Programación Orientada a Objetos, las Pruebas Unitarias tradicionalmente instancian una clase
e invocan uno de sus métodos. En una aplicación Web MVC, las Pruebas Unitarias pueden instanciar
clases Modelo o Controladores e invocar sus métodos y acciones. Como desarrolladores Web,
necesitamos conocer cómo crear un proyecto para Pruebas y agregar pruebas a estos proyectos. Las
pruebas verifican aspectos individuales de nuestro código sin preocuparse de los servidores de bases
de datos, conexiones de red y otra infraestructura. Esto es debido a que las Pruebas Unitarias se
enfocan en el código que escribimos.
• Describir el uso de las Pruebas Unitarias para mejorar la calidad del código que escribimos.
• Listar los principios del Desarrollo Guiado por Pruebas – Test Driven Development (TDD).
• Describir la forma en que los componentes débilmente acoplados (loosely-coupled)
incrementan la facilidad de hacer pruebas y el mantenimiento de nuestra aplicación.
• Escribir Pruebas Unitarias para las clases Modelo y Controladores en una aplicación Web
MVC.
• Describir cómo los contenedores Inversión de Control –Inversion of Control (IoC) – pueden
instanciar Controladores y clases Modelo.
• Ejecutar Pruebas Unitarias en Visual Studio.
• Utilizar una Herramienta de Simulación – Mocking Tool - para automatizar la creación de
simulaciones – mock - en Pruebas Unitarias.
¿Por qué realizar Pruebas Unitarias?

Los errores de software son conocidos comúnmente como “Bugs”. Existen 3 tipos de pruebas que
podemos utilizar para identificar “Bugs” en nuestras aplicaciones:
• Pruebas Unitarias (Unit Tests). Las Pruebas Unitarias comprueban aspectos pequeños de
funcionalidad. Por ejemplo, una Prueba Unitaria podría verificar el tipo devuelto de un único
método. Mediante la definición de muchas Pruebas Unitarias en nuestro proyecto, podemos
asegurar que estas cubran todos los aspectos de funcionalidad de nuestra aplicación Web.
• Pruebas de Integración (Integration Tests). Las Pruebas de Integración comprueban la forma
en que 2 o más clases interactúan entre ellas. Las Pruebas de Integración también pueden
ser utilizadas para comprobar la forma en que la aplicación Web entera, incluyendo la base
de datos y los servicios Web externos trabajan para proporcionar contenido.
• Pruebas de aceptación (Acceptance Test). Las Pruebas de Aceptación se enfocan en un
requerimiento funcional o técnico que debe funcionar para que los Stakeholders acepten la
aplicación. Al igual que las Pruebas de Integración, las Pruebas de Aceptación
tradicionalmente comprueban múltiples componentes trabajando en conjunto.
Las Pruebas Unitarias son importantes debido a que pueden ser definidas en una etapa temprana del
proceso de desarrollo. Las Pruebas de Integración y de Aceptación por lo general se ejecutan más
tarde, cuando varios componentes están a punto de ser terminados.
¿Qué es una Prueba Unitaria (Unit Test)?

Una Prueba Unitaria es un procedimiento que verifica un aspecto específico de funcionalidad.
Múltiples Pruebas Unitarias pueden ser realizadas para una sola clase e incluso para un solo método
en una clase. Por ejemplo, podemos escribir una prueba que verifique que el método Validate
siempre devuelva un valor booleano. Podríamos escribir una segunda prueba que verifique que
cuando enviemos un valor específico al método Validate, el método devuelva un valor true. Es
posible ensamblar diversas Pruebas Unitarias dentro de una sola clase llamada Accesorio de Prueba
(Test Fixture). Frecuentemente, un Accesorio de Prueba contiene todas las pruebas para una clase
específica. Por ejemplo, la clase ProductTestsFixture podría incluir todas las pruebas que verifican
métodos de la clase Product.
Una sola Prueba Unitaria generalmente consiste de código que se ejecuta en tres fases:
1. Preparar (Arrange). En esta fase, la prueba crea una instancia de la clase que será probada.
También asigna cualquier propiedad requerida y crea cualquier objeto requerido para
completar la prueba. Únicamente propiedades y objetos que son esenciales para la prueba
son creados.
2. Actuar (Act). En esta fase, la prueba ejecuta la funcionalidad que debe probar. Normalmente,
en esta fase, la prueba invoca a un método y almacena el resultado en una variable.
3. Asegurar (Assert). En esta fase, la prueba verifica el resultado comparándolo contra un

resultado esperado. Si el resultado es igual al esperado, la prueba pasa, de lo contrario, la
prueba falla.
¿Cómo ayudan las Pruebas Unitarias a detectar errores?

Debido a que las Pruebas Unitarias verifican un aspecto pequeño y especifico de código, es fácil
diagnosticar el problema cuando las pruebas fallan. Las Pruebas Unitarias, normalmente trabajan con
una sola clase y aíslan la clase de otras clases siempre que sea posible. Si otras clases son esenciales,
el menor número posible de clases es creado en la fase de Preparación. Este enfoque nos permite
resolver problemas rápidamente debido a que el número de fuentes potenciales de un error es
pequeño.
Las Pruebas Unitarias deberían comprobar el código que nosotros escribimos y no los aspectos de
infraestructura sobre el cual es sistema en producción será alojado. Por ejemplo, las Pruebas
Unitarias deberían ejecutarse sin conectarse a una base de datos real o a un servicio Web debido a
que los problemas de red o fallas del servicio Web podrían causar una falla. Utilizando este enfoque,
podemos distinguir entre los errores que surgen desde el código, los cuales deben ser arreglados
modificando el código, y los errores que surgen por fallos de la infraestructura y que deben ser
solucionados cambiando de Hardware, reconfigurando servidores Web, reconfigurando cadenas de
conexión, o realizando otros cambios de configuración.
Pruebas Unitarias Automatizadas

Es importante entender que las Pruebas Unitarias, después de que son definidas, pueden volverse a
ejecutar fácil y rápidamente durante todo el ciclo de vida del proyecto. De hecho, las versiones Visual
Studio Ultimate, Premium o Enterprise pueden ser configuradas para ejecutar las pruebas
automáticamente cuando compilamos el proyecto de pruebas. También, es posible iniciar las
pruebas manualmente en cualquier momento. Esto es importante debido a que un nuevo código
agregado puede causar errores en cualquier fase del proceso de desarrollo.
Como un ejemplo, consideremos un proyecto que es desarrollado en tres fases. Una prueba unitaria
definida para la fase 1 ayuda a resaltar problemas en las fases 2 y 3 que de otro modo podrían pasar
inadvertidas:
1. Fase 1. La clase ProductController es definida y la Prueba Unitaria Test_Index_Action es

codificada. La prueba verifica que la acción Index trabaje con un parámetro entero. Cuando
invocamos la acción Index con un valor entero, la acción devuelve una colección que incluye
el mismo número de objetos Product. La prueba pasa.
2. Fase 2. Un desarrollador modifica la acción Index para que devuelva una Vista Parcial. El
desarrollador renombra la acción Index por _Index para cumplir con la convención de
nombres de Vistas Parciales del equipo de desarrollo. La prueba falla debido a que el nombre
ha cambiado. El desarrollador modifica la prueba para que ahora invoque a la acción

renombrada y la prueba pasa.
3. Fase 3. Un desarrollador modifica la acción _Index escribiendo una consulta LINQ diferente
para implementar la funcionalidad de un nuevo requerimiento. Sin embargo, el desarrollador
comete un error en la sintaxis LINQ. La acción _Index ahora devuelve cero productos
independientemente del valor entero que le es pasado como parámetro. La prueba falla.
En la fase 2, la falla en la prueba se presentó debido a que el nombre de la acción había cambiado, no
por un error en el código de la acción. La solución fue cambiar el nombre de la acción invocada en el
método de prueba y esto puede recordar a los desarrolladores modificar las llamadas a la acción
renombrada en toda la solución.
En la fase 3, la falla en la prueba se presentó debido a que el desarrollador no entendía muy bien
LINQ o cometió un error de escritura en la sintaxis LINQ. La Prueba Unitaria resaltó el error tan
pronto como este se presentó. Esto ayuda al desarrollador a enfocarse en una solución para resolver
la falla de la prueba y asegura que nueva funcionalidad no cause fallas en el código escrito
previamente en el proyecto.
Principios del Desarrollo Guiado por Pruebas

Podemos utilizar Pruebas Unitarias para detectar errores potenciales y mejorar la calidad de la
aplicación final en cualquier metodología de desarrollo, incluyendo proyectos en cascada, proyectos
iterativos o proyectos Ágiles. Cualquier proyecto puede beneficiarse de las Pruebas Unitarias
independientemente de la metodología de desarrollo utilizada en el proyecto. Sin embargo, una
metodología específica de desarrollo llamada Desarrollo Guiado por Pruebas (en inglés Test Driven
Development o simplemente TDD), coloca a las Pruebas Unitarias en el centro de las prácticas de
trabajo. TDD es frecuentemente descrito como una metodología de desarrollo independiente.
Algunos autores lo consideran como el principio fundamental de la metodología de programación
extrema (en inglés Extreme Programming).
Escribe la prueba, Pasa la Prueba, Refactoriza

En TDD, los desarrolladores repiten el siguiente ciclo corto para implementar un requerimiento
funcional:
1. Escribir la Prueba. El desarrollador empieza creando y codificando la prueba unitaria. Este

paso requiere un entendimiento completo del requerimiento funcional que puede ser
obtenido a partir de los casos de uso o historias de usuario. Dado que el desarrollador no ha
escrito código alguno en la aplicación, la prueba falla.
2. Aprobar la Prueba. El desarrollador escribe algo de código rápido y simple en la aplicación
para que pase la prueba. Durante la primera iteración, este código frecuentemente no es
elegante y puede incluir falsas suposiciones tales como valores en código duro.
3. Refactorizar. El desarrollador limpia el código de la aplicación, elimina código duplicado,
elimina valores en código duro, mejora la legibilidad y realiza otras mejoras técnicas. El
desarrollador vuelve a ejecutar la prueba para asegurar que la refactorización no ha causado
una falla.
Después de esto, el ciclo es repetido. En cada iteración, el desarrollador agrega nuevas partes de la
funcionalidad final con su correspondiente prueba.
Es importante que el código en nuestras pruebas sea tratado como código en producción. Debe estar
bien pensado y fácil de leer para que otros desarrolladores puedan entender la prueba y diagnosticar
rápidamente cualquier falla en la prueba.
Principios del Desarrollo Guiado por Pruebas

TDD es diferente de los enfoques tradicionales de desarrollo de aplicaciones. Para utilizar TDD de
manera efectiva, debemos entender sus principios fundamentales:
• Escribir pruebas antes que código. En el ciclo de desarrollo TDD, la prueba es creada un paso
antes que cualquier código de la aplicación. Esto significa que la prueba debe fallar la primera
vez que es ejecutada. Podemos entender la prueba como una especificación de la

funcionalidad que estamos desarrollando. Al escribir primero la prueba, aseguramos que
estamos iniciando con un amplio entendimiento del problema que estamos tratando de
resolver.
• Moverse a pasos pequeños. Al dividir una aplicación grande en elementos pequeños de
funcionalidad, podemos mejorar la productividad del desarrollador. Podemos realizar esto
dando al desarrollador un problema pequeño a resolver en cada iteración. El desarrollador
puede resolver ese simple problema rápidamente y entender todas las posibles
circunstancias en las cuales su código se ejecuta.
• Escribir únicamente el código suficiente para pasar la prueba. En cada iteración, no
debemos tratar de agregar código extra que no esté relacionado con la prueba. Por ejemplo,
si sabemos que los usuarios invocarán una acción con otros parámetros distintos a los de la
prueba, no debemos escribir código para manejar esos parámetros, en vez de eso, durante la
siguiente iteración, podemos escribir una segunda prueba para esos parámetros. Después de
esto, escribir y refactorizar ese código.
Los desarrolladores pueden referirse a las pruebas como ejemplos de la forma en que debemos
utilizar una clase o método. Esto puede incrementar la productividad del desarrollador debido a que
los desarrolladores pueden ver el código que demuestra el método o la clase.
Creando Componentes MVC débilmente acoplados (Loosely-Coupled)

Una aplicación débilmente acoplada es aquella en la cual cada componente requiere poco o nada de
detalle interno de los otros componentes del sistema. En la Programación Orientada a Objetos, por
ejemplo, dos clases pueden ser descritas como débilmente acopladas si una de las clases puede
invocar métodos de la otra clase sin requerir código que sea específico de la otra clase. Cuando los
componentes del sistema están débilmente acoplados de esta manera, es fácil remplazar una clase
con otra implementación de la misma funcionalidad. Los componentes débilmente acoplados son
esenciales para la implementación de pruebas unitarias debido a que las clases que tienen que ver
con los datos reales, tales como datos de una base de datos, pueden ser fácilmente remplazadas con
clases que tienen que ver con datos de prueba.
Utilizando acoplamiento débil en Pruebas

Una aplicación débilmente acoplada es fácil de probar debido a que podemos realizar pruebas
simples remplazando una instancia completamente funcional de una clase con una instancia
simplificada que es diseñada específicamente para la prueba. El remplazo de clases en pruebas de
esta manera sólo puede ser realizado cuando los componentes están débilmente acoplados. Las
instancias de remplazamiento utilizadas para Pruebas Unitarias son conocidas como Dobles de
pruebas (Test doubles) o Falsificaciones (Fakes). Un Doble de Prueba o falsificación incluye
solamente el código y propiedades suficientes para pasar la prueba correspondiente y probar la
funcionalidad. Un Doble de Prueba puede pensarse como la persona que hace las acciones peligrosas
de un actor en una película y que se conoce comúnmente como el Doble del actor.
Otros beneficios del acoplamiento débil

El acoplamiento débil tiene otros beneficios además del de las Pruebas Unitarias. El acoplamiento
débil facilita remplazar componentes simples con otros componentes más sofisticados, por ejemplo,
en la versión 1 de una aplicación podríamos escribir una clase que realice una simple operación
aritmética. En la versión 2, podríamos remplazar esta clase con una nueva clase que realice la
operación aritmética basada en un algoritmo más complejo. Si los componentes están débilmente
acoplados, podemos realizar este remplazamiento sin modificar código alguno fuera de estas clases.
Utilizando Interfaces para acoplamiento débil

En la Programación Orientada a Objetos, una Interface define un conjunto de propiedades y
métodos. Cualquier Clase que implemente la Interface, como mínimo debe implementar todas las
propiedades y métodos que la Interface define. Esto crea un acoplamiento débil debido a que no
necesitamos especificar una clase en el código. En lugar de eso, podemos especificar cualquier
implementación de una Interface particular.
Acoplamiento débil en una aplicación Web MVC

Para mostrar cómo puede ser utilizado el acoplamiento débil en una aplicación Web MVC,
consideremos el siguiente escenario:
Estamos escribiendo una aplicación Web MVC que muestra un catálogo de productos
y permite a los usuarios dar clic a un producto para ver su detalle completo. En la
página de detalles del producto, los usuarios pueden ver y agregar comentarios de
ese producto. Queremos asegurar durante la prueba que la propiedad
Product.Comments, que es una colección de objetos Comment, únicamente incluya
comentarios con el valor correcto de ProductID.
Recordemos que las Pruebas Unitarias no deberían depender de la infraestructura tal como
conexiones de red o servidores de datos, las Pruebas Unitarias dependen únicamente del código de
prueba. En contraste, en producción, la aplicación obtendrá todos los comentarios de productos
desde una base de datos. Para satisfacer las necesidades de prueba y producción, podemos construir
los siguientes componentes:
• Una interface IProduct. Esto incluye una definición de la propiedad Comments junto con
otras propiedades y métodos. Esta interface es conocida como un Repositorio.
• Una clase Product. Esta es la implementación del repositorio IProduct que la aplicación
utiliza en producción. Cuando el usuario invoca la propiedad Comments, todos los
comentarios del producto actual son obtenidos desde la base de datos.
• Una clase TestProduct. Esta es la implementación Doble de prueba o Falsificación del
repositorio IProduct que la prueba utiliza. La prueba prepara un objeto TestProduct y
falsifica comentarios con diferentes valores de ProductID. La prueba invoca la propiedad
TestProduct.Comments y verifica que únicamente los comentarios correctos sean
retornados.
Notemos que, en la prueba, el Doble de Prueba TestProduct, utiliza datos en memoria establecidos
durante la fase de preparación (Arrange) por lo cual no requiere de la base de datos. Por
consiguiente, podemos probar nuestro código sin depender de la conexión de red hacia la base de
datos o del servidor mismo de base de datos. Este enfoque también asegura que la prueba se ejecuta
rápido, lo cual es importante dado que las pruebas lentas desalientan a los desarrolladores a ejecutar
las pruebas de forma regular.
Laboratorio:
Creando Pruebas Unitarias para componentes MVC
El modelo de programación ASP.NET MVC facilita su integración con los principios de las Pruebas
Unitarias y del Desarrollo Guiado por Pruebas - Test Driven Development (TDD) debido a su
separación de responsabilidades en Modelos, Vistas y Controladores. Los Modelos son simples de
probar debido a que son clases independientes que podemos instanciar y configurar durante la fase
de Preparación (Arrange) de una prueba. Los Controladores son clases simples que podemos probar,
pero resulta complejo probar Controladores con datos en memoria en lugar de utilizar una base de
datos. Para probar los Controladores con datos en memoria, creamos una clase Repositorio Doble de
Prueba, también conocida como Repositorio Falso (Fake Repository). Los objetos de esta clase
pueden ser llenados con datos de prueba en memoria sin consultar a una base de datos. Es necesario
entender cómo escribir Dobles de prueba y como escribir una prueba típica para clases MVC.
Para ejemplificar el uso de pruebas unitarias, desarrollarás una aplicación que muestre una página
Web con los datos de las categorías de productos de la empresa ficticia Northwind. La aplicación
Web debe ser capaz de mostrar la imagen y el detalle de una categoría de productos especificada.
Para implementar la funcionalidad de la aplicación, crearás una aplicación ASP.NET Web MVC, que
contendrá una clase modelo Category y un controlador llamado Category con los siguientes métodos
de acción:
a) Index. Este método devolverá una vista llamada Index. La vista Index hará uso de la vista
parcial _CategoryList para mostrar los datos de una o más categorías de productos.
b) _CategoryList. Este método devolverá una vista parcial cuyo modelo será una lista de uno o
más objetos Category.
c) Display. Este método devolverá una vista cuyo modelo será un objeto Category. La vista
invocará a un método de acción GetImage para mostrar la imagen de una categoría de
productos.
d) GetImage. Este método devolverá un archivo con la imagen de una categoría solicitada.
Objetivos
Al finalizar este laboratorio, serás capaz de:
• Realizar Pruebas Unitarias de los componentes de una aplicación Web MVC.

• Crear e implementar Interfaces Repositorio para ser utilizadas en ambientes de pruebas y de
producción.
Requisitos
Para la realización de este laboratorio es necesario contar con un equipo de desarrollo con:
• Visual Studio 2013 o posteriores.

• Microsoft SQL Server 2012 o posteriores.
• Base de datos Northwind.
Puedes utilizar una máquina virtual como equipo de desarrollo.
Tiempo estimado para completar este laboratorio: 120 minutos.
Ejercicio 1:
Creando Pruebas Unitarias
En Microsoft Visual Studio podemos probar un proyecto de aplicación Web MVC agregando a la
solución un nuevo proyecto basado en la plantilla Unit Test Project. El proyecto Unit Test podemos
agregarlo durante la creación del proyecto de aplicación Web MVC o podemos agregarlo a un
proyecto de aplicación Web MVC ya existente. Es importante recordar que para cumplir con los
principios del Desarrollo Guiado por Pruebas (TDD), debemos implementar la funcionalidad de las
clases de prueba antes de implementar la funcionalidad de las clases que serán probadas.
Para adherirnos a los principios de TDD con Visual Studio, haremos lo siguiente:
1. Crearemos la aplicación Web MVC y durante la creación agregaremos el proyecto de pruebas

utilizando la plantilla Unit Test.
2. Agregaremos el Controlador y los métodos de acción requeridos. Es importante mencionar
que para adherirnos a los principios de TDD, no implementaremos la funcionalidad de los
métodos de acción en este paso.
3. Agregaremos las clases y métodos en el proyecto de pruebas para probar la funcionalidad del
Controlador.
4. Implementaremos la funcionalidad mínima del Controlador que sea suficiente para que las
pruebas sean ejecutas y aprobadas con éxito.
Tarea 1: Crear un proyecto de pruebas
En esta tarea, crearás una aplicación Web ASP.NET MVC y un proyecto de pruebas unitarias para
probar la aplicación Web.
1. Abre Visual Studio y selecciona la opción File/New Project de la barra de menús.

2. En la ventana New Project, selecciona la plantilla ASP.NET Web Application, proporciona
Northwind como nombre de la aplicación y da clic en OK para continuar.
3. En la ventana New ASP.NET Project, selecciona la plantilla Empty, la casilla MVC y la casilla
Add unit tests. Acepta el nombre propuesto para el proyecto de pruebas formado por el
nombre del proyecto de la aplicación Web más la extensión .Tests y da clic en OK para
continuar.
Nota: El Framework de pruebas utilizado en este laboratorio es Microsoft Unit Test

Framework for Managed Code, sin embargo, existen muchos otros Frameworks de prueba
disponibles para aplicaciones Web MVC de los cuales podemos seleccionar el de nuestra
preferencia. Muchos de esos Frameworks pueden ser agregados utilizando el
administrador de paquetes NuGet disponible en Visual Studio.
Microsoft Unit Test Framework se encuentra definido en el assembly

Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll.
Si utilizamos Visual Studio Express, no es posible utilizar la plantilla Unit Test Project, pero
podemos agregar otros Frameworks de Prueba utilizando NuGet.
Tarea 2: Configurar el proyecto de pruebas
Una vez agregado el proyecto de pruebas, debemos agregarle referencias para que el código de las
pruebas unitarias pueda acceder a clases en el proyecto de la aplicación Web MVC. También
necesitamos agregar una referencia a System.Web.Mvc y System.Web.Webpages.
1. Verifica que en las referencias del proyecto Northwind.Tests se ha agregado la referencia al

proyecto de la aplicación Web Northwind y al Framework de pruebas unitarias de Microsoft.
4. En el proyecto Northwind.Tests agrega la referencia del Assembly System.Web.Mvc
Después de agregar la referencia, esta se mostrará en la sección References.
5. De la misma forma, en el proyecto Northwind.Tests, agrega una referencia del Assembly

System.Web.Webpages.
Tarea 3: Preparar la aplicación Web
Para aplicar las técnicas del desarrollo guiado por pruebas (TDD) para el proyecto de la aplicación
Web, debemos escribir la prueba unitaria para un método de acción antes de escribir el propio
método de acción. Sin embargo, si deseamos que la prueba unitaria compile, debemos crear la
declaración (method stub) del método de acción planeado.
En nuestro caso, la aplicación Web que deseamos probar debe mostrar una página web con los datos
de las categorías de productos de la empresa Northwind y además debe mostrar la imagen de una
Categoría especifica. Para implementar las funcionalidades requeridas, crearemos una clase modelo
Category y un controlador llamado Category que contendrá los métodos de acción necesarios.
1. Agrega una clase llamada Category en la carpeta Models. Esta clase representará una
categoría de productos. Por el momento la clase Category no será implementada.
2. Utiliza la plantilla MVC 5 Controller – Empty para agregar un Controlador llamado Category
en el proyecto de la aplicación Web.
Tarea 4: Escribir las pruebas
En TDD, los desarrolladores repiten un ciclo corto para implementar un requerimiento funcional. El
primer paso del ciclo es Escribir la prueba. En este paso el desarrollador empieza creando y
codificando la prueba unitaria. Este paso requiere un entendimiento completo del requerimiento
funcional que puede ser obtenido a partir de los casos de uso o historias de usuario.
1. En el proyecto Northwind.Tests, renombra la clase UnitTest1 por CategoryControllerTests.

Esta clase será el Accesorio de Prueba (Test Fixture) que contendrá todas las pruebas
unitarias que comprobarán métodos de la clase Controlador Category de la aplicación Web.
En un proyecto de pruebas de Visual Studio, los Accesorios de prueba son clases marcadas
con la anotación [TestClass]. Las pruebas unitarias son métodos marcados con la anotación
[TestMethod] y tradicionalmente devuelven void como se puede ver en la siguiente imagen.
2. Localiza la declaración del espacio de nombres Microsoft.VisualStudio.TestTools.UnitTesting
Este espacio de nombres contiene las clases que proporcionan el soporte de pruebas
unitarias.
3. Agrega las siguientes declaraciones para importar los espacios de nombres requeridos.
4. Renombra el método TestMethod1 por Test_Index_Return_View.

Esta prueba comprobará que el método de acción Index devuelva una vista llamada Index.
5. Una sola prueba unitaria generalmente consiste de código que se ejecuta en tres fases. En la
primera fase llamada Preparar (Arrange en Inglés), la prueba crea una instancia de la clase
que será probada. También asigna cualquier propiedad requerida y crea cualquier objeto
requerido para completar la prueba. Únicamente propiedades y objetos que son esenciales
para la prueba son creados.
Agrega el siguiente código en el cuerpo de la prueba unitaria Test_Index_Return_View. Este

código es el que se ejecutará en la primera fase de la prueba unitaria.
6. En la segunda fase llamada Actuar (Act en inglés), la prueba ejecuta la funcionalidad que
debe probar. Normalmente, en esta fase, la prueba invoca a un método y almacena el
resultado en una variable.
Agrega el siguiente código a la prueba unitaria. Este código es el que se ejecutará en la

segunda fase de la prueba unitaria.
7. En la tercera fase llamada Asegurar (Assert en inglés), la prueba verifica el resultado

comparándolo contra un resultado esperado. En esta fase, la prueba unitaria invoca algún
método de la clase Microsoft.VisualStudio.TestTools.UnitTesting.Assert tal como
Assert.AreEqual() para verificar el resultado. Si el resultado es igual al esperado, la prueba
pasa, de lo contrario, la prueba falla.
Agrega el siguiente código a la prueba unitaria para comprobar que el método de acción
Index devuelva una vista llamada Index. Este código es el que se ejecutará en la tercera fase
de la prueba unitaria.
8. Una funcionalidad requerida en la aplicación Web es la de mostrar los datos de las categorías
de productos de la empresa. Para implementar esta funcionalidad, necesitaremos un método
de acción que devuelva una lista con los datos de cada categoría.
Agrega la prueba unitaria Test_CategoryList_Model_Type que comprobará que el método

de acción _CategoryList proporcione una lista enumerable de objetos Category a la vista
parcial _CategoryList.
9. La fase Arrange de la prueba creará una instancia del controlador Category, por lo tanto,
agrega el siguiente código a la prueba unitaria.
10. La fase Act de la prueba invocará al método de acción _CategoryList del controlador, por lo
tanto, agrega el siguiente código a la prueba unitaria.
En este momento, el método de acción _CategoryList no existe, si queremos que el proyecto

de pruebas unitarias compile, debemos agregar la declaración del método.
11. Selecciona la opción Generate / Method Stub del menú contextual del código que hace la
llamada al método _CategoryList.
Esto creará la definición del método (method Stub) _CategoryList en el controlador Category
similar al siguiente.
12. La fase Assert de la prueba comprobará que el tipo de datos del Modelo de la vista parcial
devuelta sea del tipo List<Category>, por lo tanto, agrega el siguiente código a la prueba
unitaria.
La prueba unitaria completa quedará de la siguiente forma.
13. Otra funcionalidad requerida es la de mostrar la imagen de una categoría especificada, en

este caso, necesitaremos un método de acción que reciba un ID de categoría y que devuelva
un archivo en lugar de una vista.
Agrega la prueba unitaria Test_GetImage_Return_Type que comprobará que el método de

acción GetImage devuelva un archivo y no una vista.
14. La fase Arrange de la prueba creará una instancia del controlador Category, por lo tanto,
agrega el siguiente código a la prueba unitaria.
15. La fase Act de la prueba invocará al método de acción GetImage del controlador pasándole
el ID de la categoría a mostrar, por lo tanto, agrega el siguiente código a la prueba unitaria.
En este momento, el método de acción GetImage no existe, si queremos que el proyecto de

pruebas unitarias compile, debemos agregar la declaración del método.
16. Selecciona la opción Generate / Method Stub del menú contextual del código que hace la
llamada al método GetImage.
Esto creará la definición del método GetImage en el controlador Category similar al

siguiente.
17. La fase Assert de la prueba comprobará que el tipo del resultado devuelto por el método de
acción sea el tipo FileContentResult, por lo tanto, agrega el siguiente código a la prueba
unitaria.
La prueba unitaria completa quedará de la siguiente forma.
18. Agrega la prueba unitaria Test_Display_Model_Type para verificar que el método Display
proporcione un tipo Category a la vista que devuelve. Sigue los mismos pasos que realizaste
para implementar la prueba unitaria Test_CategoryList_Model_Type. La prueba unitaria
debe ser similar a la siguiente.
El primer paso del ciclo TDD termina cuando se han creado las pruebas.
Es importante que el código en las pruebas sea tratado como un código en producción. Debe
estar bien pensado y fácil de leer para que otros desarrolladores puedan entender la prueba
y diagnosticar rápidamente cualquier falla en la prueba.
19. En el menú de Visual Studio, selecciona la opción TEST / Run / All Test para ejecutar las
pruebas.
La ventana Test Explorer se abrirá mostrando el resultado de las pruebas. Dado que no has
escrito código en la aplicación, las pruebas fallarán.
20. En la ventana Test Explorer da clic en la prueba Test_CategoryList_Model_Type para ver la

descripción del resultado de la prueba. Puedes notar que el problema fue que se lanzó una
excepción System.NotImplementedException.
21. Da clic en las otras pruebas para ver la descripción del resultado de cada una de ellas. En el
caso de la prueba Test_Index_Return_View, la descripción indica que se esperaba <Index> y
se recibió <>.
22. En la ventana Test Explorer, da clic en el botón Close para cerrar la ventana Test Explorer.
Tarea 5: Implementar la funcionalidad para aprobar las pruebas
El segundo paso del ciclo que en TDD los desarrolladores repiten para implementar un requerimiento
funcional es Aprobar la prueba. En este paso, el desarrollador escribe algo de código rápido y simple
en la aplicación para que pase la prueba. Durante la primera iteración, este código frecuentemente
no es elegante y puede incluir falsas suposiciones tales como valores en código duro.
1. Modifica el método Index del controlador Category para que pase la prueba.
2. Es posible configurar a Visual Studio para que ejecute las pruebas unitarias automáticamente
cada vez que compilemos el proyecto de pruebas. Para hacer esto, selecciona la opción Test
/ Test Setings/ Run Test After Build. Ahora cada vez que compiles el proyecto de pruebas, las
pruebas serán ejecutadas automáticamente.
3. Compila el proyecto de pruebas Northwind.Tests.
Al finalizar la compilación, se mostrará la ventana Test Explorer indicando que la prueba

Test_Index_Return_View ha sido aprobada.
4. Cierra la ventana Test Explorer.

5. Modifica el método _CategoryList para que pueda pasar con éxito la prueba.
6. Modifica el método GetImage para que pueda pasar con éxito la prueba.
7. Modifica el método Display para que pueda pasar con éxito la prueba.
8. Compila el proyecto de pruebas Northwind.Tests.
9. Al finalizar la compilación, se mostrará la ventana Test Explorer indicando que las pruebas
han paso con éxito.
Recuerda que en este paso, el desarrollador escribe algo de código rápido y simple en la
aplicación para que pase la prueba. El código frecuentemente no es elegante y puede incluir
falsas suposiciones tales como valores en código duro.
Tarea 6: Probar clases Modelo y de Lógica de Negocio
En MVC, las clases Modelo que representan entidades de datos no dependen de otros componentes
o infraestructura. Podemos instanciarlas fácilmente en memoria, preparar los valores de sus
propiedades, actuar sobre ellas invocando un método y confirmando que el resultado fue el
esperado.
Algunas veces creamos lógica de negocio en las clases Modelo, en esos casos, la fase Actuar (Act)
envuelve la invocación a un método de la clase Modelo misma. Si por el contrario, hemos creado una
capa de lógica de negocio independiente, el código en la fase Actuar (Act) debe invocar a un método
del objeto de negocio y pasarle una instancia de la clase Modelo.
En esta tarea crearás una prueba unitaria que permita verificar que el método GetProducts de la
clase modelo Category devuelva una lista de objetos Product. Agregarás en la aplicación Web
Northwind el código suficiente para que la prueba unitaria sea ejecutada con éxito.
1. Para que el proyecto de pruebas unitarias pueda compilar, agrega la clase vacía Product en la
carpeta Models del proyecto web Northwind.
2. En el proyecto Northwind.Tests agrega un nuevo elemento Unit Test.
3. Renombra el archivo y clase creada como CategoryModelTests.
4. Cambia el nombre de la prueba unitaria TestMethod1 por Test_Category_Products.
5. En la clase CategoryModelTests, agrega el siguiente código para importar los espacios de

nombres necesarios.
6. Agrega el siguiente código a la prueba unitaria para crear una instancia de la clase modelo
Category y asignar un valor a su propiedad CategoryID. La prueba unitaria deberá verificar
que en estas circunstancias, el método GetProducts() devuelva una lista de objetos Product.
7. Agrega la declaración de la propiedad CategoryID de la clase Category.
8. Agrega la declaración del método GetProducts de la clase Category.
9. Compila el proyecto Northwind.Tests.
La ventana Test Explorer mostrará que la prueba unitaria Test_Category_Products ha

fallado.
10. Agrega al método GetProducts de la clase Category el código suficiente para que pase la
prueba.
11. Compila nuevamente el proyecto Northwind.Tests. La ventana Test Explorer mostrará que
todas las pruebas han sido aprobadas.
Recuerda nuevamente que en este paso, el desarrollador escribe algo de código rápido y
simple en la aplicación para que pase la prueba.
Ejercicio 2:
Creando Interfaces Repositorio
Un Repositorio es una interface que define propiedades y métodos que MVC puede utilizar para
almacenar datos en una aplicación Web. Es común crear una sola interface Repositorio para toda la
aplicación Web.
La interface Repositorio define métodos para interactuar con datos, pero no indica la forma en que
los datos serán establecidos y almacenados. Cuando trabajamos con pruebas unitarias, debemos
proporcionar dos implementaciones del Repositorio.
1. Una implementación del Repositorio para utilizarlo en producción y desarrollo. Esta

implementación utilizará datos de una base de datos o de algún otro mecanismo de
almacenamiento.
2. Una implementación del Repositorio para uso en pruebas. Esta implementación utilizará
datos en memoria establecidos durante la fase de Preparación de cada prueba.
En este ejercicio crearás e implementarás un repositorio, refactorizarás el controlador Category para

utilizar el repositorio y refactorizarás las pruebas unitarias para utilizar un Repositorio de Simulación
(mock repository).
Tarea 1: Crear un Repositorio
En esta tarea crearás la interface repositorio que definirá los miembros necesarios para interactuar
con los datos de la aplicación.
1. Agrega una nueva interface llamada INorthwindContext en la carpeta Models del proyecto
Northwind.
2. Agrega el modificador de acceso public a la interface.
3. Agrega a la interface INorthwindContext las siguientes definiciones de miembros:

a) La propiedad Categories de sólo lectura que permitirá implementar la funcionalidad para
evaluar consultas sobre el catálogo de categorías de la aplicación Northwind.
b) La propiedad Products de sólo lectura que permitirá implementar la funcionalidad para

evaluar consultas sobre el catálogo de productos de la aplicación Northwind.
c) El método FindCategoryByID que permitirá implementar la funcionalidad para buscar

una categoría mediante su ID.
d) El método FindProductByID que permitirá implementar la funcionalidad para buscar un

producto mediante su ID.
e) El método genérico Add que permitirá agregar una Entidad T al Repositorio donde T es
un tipo referencia (Reference-Type).
f) El método genérico Delete que permitirá eliminar una Entidad T del Repositorio donde T
es un tipo referencia (Reference-Type).
g) El método SaveChanges que permitirá implementar la funcionalidad para hacer

persistente los cambios en el Repositorio hacia la fuente de datos.
Tarea 2: Implementar el Repositorio para utilizarlo en producción y desarrollo
En esta tarea implementarás el Repositorio para utilizarlo en producción y desarrollo. Esta

implementación accederá a los datos de la base de datos Northwind a través de Entity Framework
por lo que antes de implementar el Repositorio, generarás el modelo de la base de datos.
Nota: Existen diversas formas de implementar el Repositorio, por simplicidad, la

implementación que realizarás será dependiente de las entidades Category y Product
utilizadas por la aplicación Northwind. Implementaciones más genéricas del Repositorio
permiten utilizarlas en cualquier aplicación independientemente de las entidades
utilizadas.
1. Utiliza los siguientes datos para agregar un nuevo elemento ADO.NET Entity Data Model en
la carpeta Models del proyecto Northwind:
a. Nombre: NorthwindDBModel
b. Tipo de modelo: EF Designer from database
c. Base de datos: Northwind

d. Versión de Entity Framework: Entity Framework 6.x
e. Tablas: Categories y Products
Después de agregar el modelo NorthwindDBModel, las clases originales Category y Product

de la carpeta Models serán remplazadas automáticamente por el generador de código de
Entity Framework.
2. Compila la solución.
Después de compilar la aplicación obtendrás el siguiente mensaje de error.
La razón del error es que la clase original Category contenía al método GetProducts que la
nueva clase Category del modelo generado por Entity Framework no contiene.
3. Agrega una nueva clase llamada CategoryPartial en la carpeta Models del proyecto
Northwind.
4. Modifica el código de la clase para generar una clase parcial Category que implemente el
método GetProducts.
Nota: No debes renombrar el archivo CategoryPartial.cs. El nombre del archivo puede

tener cualquier nombre válido excepto el nombre Category.cs ya que el generador de
código lo remplazará al regenerar el código del modelo de la base de datos
NorthwindDBModel.
La solución se compilará con éxito y las pruebas serán aprobadas también con éxito.
6. Para implementar el Repositorio que interactúe con el modelo de la base de datos

NorthwindDBModel, agrega una nueva clase llamada NorthwindContext en la carpeta
Models del proyecto Northwind.
7. Modifica el código para indicar que la clase implementará la interface INorthwindContext.
8. Agrega a la clase el siguiente código para crear el Contexto Entity Framework que será
utilizado para interactuar con la base de datos Northwind.
La implementación de cada miembro de la interfaz INorthwindContext simplemente

envolverá miembros de la clase NorthwindEntities a través del objeto Context.
9. Implementa la propiedad Categories que devuelva el conjunto de entidades Categories del

contexto.
10. Implementa la propiedad Products que devuelva el conjunto de entidades Products del
contexto.
11. Implementa el método FindCategoryByID para devolver el objeto Category con el ID

solicitado.
12. Implementa el método FindProductByID para devolver el objeto Product con el ID solicitado.
13. Implementa el método Add para agregar al Repositorio una Entidad y devolver la Entidad
agregada como resultado.
14. Implementa el método Delete para eliminar del Repositorio una Entidad y devolver la
Entidad eliminada como resultado.
15. Implementa el método SaveChanges para hacer persistentes los cambios del repositorio
hacia la base de datos Northwind.
Verifica que no haya errores y que las pruebas hayan aprobado.
Tarea 3: Refactorizar el Controlador para utilizar el Repositorio
Ahora que has implementado un Repositorio para interactuar con la fuente de datos a través de
Entity Framework, modificarás el controlador Category para utilizar el repositorio implementado.
1. Abre el archivo CategoryController.cs de la carpeta Controllers en el proyecto Northwind.

2. Agrega el código para importar el espacio de nombres Northwind.Models que te permitirá
referenciar la interface Repositorio y su implementación.
3. Dentro de la clase CategoryController, declara la variable privada Context. Esta variable

almacenará una instancia de una implementación del Repositorio.
Especificando el Contexto apropiado
Cuando utilizamos Dobles de Prueba para Pruebas Unitarias de Controladores MVC,

debemos asegurar que el Controlador utilice el contexto correcto en dos diferentes
escenarios:
• En Pruebas Unitarias. En una Prueba Unitaria, debemos probar el código sin

depender de la infraestructura subyacente tal como las bases de datos. Podemos
utilizar una clase Doble de Prueba que se comporte como un contexto Entity
Framework pero que utilice datos en memoria. Si utilizáramos un contexto Entity
Framework para Pruebas Unitarias, todas las pruebas podrían fallar.
• En otros momentos. Cuando no estamos realizando Pruebas Unitarias del código,
utilizamos el contexto Entity Framework actual en el código del Controlador. Dicho
contexto interactúa con la base de datos. Si utilizáramos el código del Doble de
Prueba en producción, no podrían ser almacenados los datos en la base de datos.
4. Agrega un constructor sin parámetros a la clase CategoryController. El propósito del

constructor predeterminado es el de crear una instancia de la clase NorthwindContext que
permitirá interactuar con los datos de la base de datos Northwind.
Utilizando Constructores para especificar un Repositorio
Podemos especificar el Repositorio correcto que debe utilizar un Controlador a través de

sus constructores. Cuando no se está ejecutando una Prueba Unitaria, la fábrica de
controladores MVC invocará al Constructor predeterminado (sin parámetros) del
Controlador. Esto significa que en el Constructor predeterminado debemos especificar el

Repositorio que interactúa con el contexto Entity Framework.
5. Agrega un segundo constructor a la clase CategoryController. El propósito de este

constructor es el de recibir una instancia de cualquier clase que implemente el Repositorio.
Esto nos permitirá interactuar con cualquier fuente de datos que sea proporcionada, incluso
con datos ficticios de prueba.
Utilizando Constructores para especificar un Repositorio
Durante una Prueba Unitaria, debemos invocar un constructor que reciba una instancia de
la interface Repositorio como parámetro. El parámetro puede ser la instancia de la clase
Repositorio Doble de prueba que se comporte como un contexto Entity Framework pero
que utilice datos en memoria.
Utilizando Contenedores Inversión de Control – Inversion of Control (IoC) Container
También es posible asegurar que la clase Repositorio correcta sea utilizada en cada
escenario mediante el uso de un Contenedor de Inversión de Control (Inversion of
Control (IoC) Container). Un Contenedor de Inversión de Control es un Framework que
podemos agregar a nuestra aplicación para instanciar clases. Debemos configurar el
contenedor IoC para que pueda identificar la clase de objeto a crear cuando la aplicación
espera una interface específica. Por ejemplo, cuando utilizamos código para crear una
nueva instancia de la interface INorthwindContext, el contenedor IoC verificará su
configuración y encontrará que debe instanciar la clase NorthwindContext, que es un
contexto Entity Framework que implementa la interface INorthwindContext.
Los Frameworks IoC también son conocidos como Frameworks de Inyección de

Dependencia, en inglés Dependency Injection o simplemente DI. La razón de esto es que
ellos inyectan dentro de los constructores de las clases, instancias de clases que
implementan las interfaces correctas.
Al utilizar un contenedor IoC, evitamos la necesidad de crear dos constructores para las
clases Controller. Durante las pruebas, podemos instanciar al Doble de Prueba y pasarlo al
constructor del controlador. En otros momentos, el contenedor IoC instanciará el contexto
Entity Framework actual y lo pasará al constructor del Controlador.
Existen diversos contenedores IoC diseñados para utilizarse en aplicaciones web ASP.NET
MVC. Estos remplazan ciertos componentes del Framework MVC para soportar IoC. Por
ejemplo, remplazan la Fábrica de Controladores predeterminada con una fábrica que crea
instancias de controladores con la clase Contexto correcta. Muchos contenedores IoC se
encuentran disponibles en la biblioteca de paquetes NuGet tales como NinJect y
StructureMap.
¿Cuál enfoque para especificar el Contexto apropiado es más débilmente acoplado:

Utilizando Constructores o utilizando Contenedores IoC?
El enfoque más débilmente acoplado es utilizando un Contenedor IoC. Si queremos

modificar la implementación del Repositorio, podemos hacerlo simplemente cambiando la
configuración del contenedor IoC y no será necesario modificar código alguno en el
Controlador.
6. Modifica el método Display de la clase CategoryController para buscar en el Repositorio el

objeto Category cuyo ID sea igual al requerido. El método devolverá una instancia de una
implementación de la clase ActionResult: HttpNotFound si la categoría no se encuentra o la
vista Display en caso de que la categoría haya sido encontrada.
7. Agrega la Vista para el método de acción Display utilizando la siguiente información:
8. En la vista Display, modifica el elemento <title> y agrega un elemento <h2> para mostrar el
nombre de la categoría.
9. Agrega a la Vista el tag IMG para mostrar la imagen de la Categoría utilizando el método de
acción GetImage del controlador Category y pasando como parámetro el ID de la categoría
del objeto modelo actual.
10. Agrega a la vista el siguiente código para mostrar la descripción de la categoría.
11. En el controlador Category, modifica el método de acción GetImage para buscar en el

Repositorio el objeto Category cuyo ID sea igual al requerido. El método debe devolver la
imagen de la categoría como archivo o null en caso de que la categoría no sea encontrada.
12. En el controlador Category, modifica el método de acción _CategoryList para que obtenga
desde el Repositorio la lista de categorías a devolver.
13. En el folder Views del proyecto Northwind, agrega la carpeta Shared para poder crear ahí la
vista parcial _CategoryList.
14. En la carpeta Shared, agrega la vista parcial _CategoryList utilizando los siguientes datos:
15. En la vista parcial _CategoryList agrega el siguiente código para definir el modelo.
16. A continuación, agrega el siguiente código que el motor de vistas Razor utilizará para generar
el código HTML con los datos de cada categoría del Modelo.
17. Agrega ahora la vista Index para el método de acción Index del controlador Category
utilizando los siguientes datos:
18. En la vista Index creada, modifica el elemento Title y agrega un elemento <h2> para agregar
el título de la página.
19. A continuación, agrega el código para invocar el método de acción que devuelve la vista
parcial _CategoryList.
20. Compila el proyecto Northwind y verifica que compile exitosamente.

21. Modifica las propiedades del proyecto Northwind para que al ejecutar la aplicación inicie con
el método Index del controlador Category.
22. Ejecuta la aplicación Northwind.
Se mostrará una instancia del Internet Explorer similar a la siguiente.
23. Da clic en el enlace Display de cualquiera de las categorías para ver su detalle. Deberá
mostrarse una página similar a la siguiente.
24. Detén la aplicación y regresa a Visual Studio.

25. Compila ahora el proyecto de pruebas unitarias Northwind.Test.
Verifica que las pruebas unitarias que hacen acceso al Repositorio no han podido ejecutarse
exitosamente. Observa que el problema es debido a que en tiempo de diseño la cadena de
conexión no se ha encontrado.
Recuerda que las pruebas unitarias no deben depender de la infraestructura tal como
conexiones de red o servidores de datos, las pruebas unitarias dependen únicamente del
código de prueba. En contraste, en producción, la aplicación obtendrá todos los datos desde
una base de datos. Para satisfacer las necesidades de prueba será necesario implementar un
repositorio para ser utilizado por las pruebas unitarias.
Tarea 4: Implementar el Repositorio Doble de Prueba
La segunda implementación de la interface Repositorio, es la implementación que será utilizada en

las pruebas unitarias. Esta implementación utilizará datos en memoria y una colección de objetos con
llaves para proporcionar una funcionalidad similar a un contexto Entity Framework, pero sin trabajar
con una base de datos.
La implementación de este Repositorio falso permitirá remplazar la instancia del Repositorio

verdadero que interactúa con la base de datos. Las instancias de remplazamiento utilizadas para
pruebas unitarias son conocidas como Dobles de pruebas (Test doubles), Simulación (Mock) o
Falsificaciones (Fakes). Un Doble de prueba incluye solamente el código y propiedades suficientes
para aprobar la prueba correspondiente y probar la funcionalidad.
Construyamos entonces el Repositorio falso (Fake Repository) también conocido como Repositorio
Doble de Prueba (Repository Test Double) o Repositorio de Simulación (Mock Repository).
1. En el proyecto Northwind.Tests, agrega una nueva carpeta llamada Doubles. En esta carpeta
almacenarás posteriormente el Repositorio Doble de Prueba.
Nota: Se recomienda utilizar el nombre Doubles para la carpeta donde se almacenarán

las clases Doble de prueba que serán utilizadas por las pruebas unitarias, sin embargo, el
nombre no es obligatorio y puede utilizarse cualquier otro nombre deseado.
2. En la carpeta Doubles, agrega una clase llamada FakeNorthwindContext. En esta clase

implementarás el Repositorio falso.
3. En la clase FakeNorthwindContext, importa el espacio de nombres Northwind.Models que

es el espacio de nombres donde se encuentra definida la interface INorthwindContext.
4. Modifica la clase FakeNorthwindContext para indicar que implementará la interface

INorthwindContext.
Para simular un contexto de Entity Framework en memoria, definiremos una clase privada
que implemente a la clase abstracta KeyedCollection<TKey, TItem>. La clase
KeyedCollection proporciona una clase base abstracta para una colección cuyas llaves están
incrustadas en los valores.
5. Agrega el siguiente código para importar el espacio de nombres

System.Collections.ObjectModel donde se encuentra definida la clase
KeyedCollection<TKey, TItem>.
6. Dentro de la clase FakeNorthwindContext, agrega la siguiente definición de la clase

DbContext_Mock.
Esta clase representa una colección con llaves que utilizarás para simular un contexto Entity
Framework en memoria. La llave de los elementos de la colección DbContext_Mock es de
tipo System.Type y cada elemento simulará un objeto System.Data.Entity.DbSet<T>.
7. Agrega el siguiente método a la clase DbContext_Mock para permitir almacenar un

elemento a la colección. Recuerda que cada elemento de la colección DbContext_Mock
simulara un objeto System.Data.Entity.DbSet<T> del DbContext que estás simulando.
Cada elemento de la colección será almacenado como una instancia de la clase HashSet<T>.
La clase HashSet<T> proporciona operaciones del alto rendimiento para colecciones de
objetos que no contienen elementos duplicados y que no se encuentran en un orden
específico. HashSet<T> proporciona un comportamiento similar a
System.Data.Entity.DbSet<T>.
8. Agrega el siguiente método a la clase DbContext_Mock que permitirá acceder a un

elemento de la colección. Este método simulará al método
System.Data.Entity.DbContext.Set<TEntity>.
Este método devuelve el elemento de la colección cuya llave sea del tipo T.
9. Agrega el siguiente método a la clase DbContext_Mock. Este método permitirá extraer la

llave de un elemento de la colección. Recuerda que la clase KeyedCollection proporciona una
clase base abstracta para una colección cuyas llaves están incrustadas en los valores.
Estos 3 métodos permiten simular la funcionalidad básica de System.Data.Entity.DbContext.

Puedes ahora continuar con la implementación de la interface Repositorio.
10. Justo al principio del cuerpo de la clase FakeNorthwindContext, agrega el siguiente código
para crear una instancia del contexto falso.
11. Agrega el siguiente código en la clase FakeNorthwindContext para implementar la propiedad

Categories de la interface INorthwindContext.
12. Agrega el siguiente código en la clase FakeNorthwindContext para implementar la propiedad

Products de la interface INorthwindContext.
13. Agrega el siguiente código en la clase FakeNorthwindContext para implementar el método

FindCategoryByID de la interface INorthwindContext.

FindProductByID de la interface INorthwindContext.

Add de la interface INorthwindContext.

Delete de la interface INorthwindContext.

SaveChanges de la interface INorthwindContext.
18. Compila el proyecto Northwind.Tests y verifica que compile exitosamente. Nota que aunque
el proyecto ha compilado con éxito, las pruebas unitarias aún siguen fallando.
Tarea 5: Refactorizar las Pruebas Unitarias para utilizar el Repositorio de simulación
Una vez que hayamos implementado una clase Doble de Prueba para el repositorio, podemos
utilizarlo para probar un Controlador en una Prueba Unitaria.
En la fase de Preparación de la prueba, creamos un nuevo objeto de la clase Doble de prueba y lo

pasamos al constructor del Controlador. El Controlador utiliza este objeto para su contexto Entity
Framework durante la fase Actuar de la prueba. Esto nos permite verificar el resultado.
Ahora que has implementado el Repositorio Doble de prueba o Mock Repository, modificarás las
Pruebas Unitarias para utilizar este Repositorio.
1. Abre el archivo CategoryControllerTests.cs del proyecto Northwind.Tests.

2. En la ventana de código de CategoryControllerTests.cs, agrega el siguiente código para
importar los espacios de nombres System.Linq y Northwind.Test.Doubles.
3. Modifica el código de la Prueba Unitaria Test_Index_Return_View para que en la fase de

Preparación de la Prueba unitaria sea creado un nuevo objeto de la clase Doble de prueba
FakeNorthwindContext y sea pasado al constructor del Controlador CategoryController. El
Controlador utilizará este objeto para su contexto Entity Framework durante la fase Actuar
de la prueba lo que nos permitirá verificar el resultado.
4. Modifica el código de la Prueba Unitaria Test_CategoryList_Model_Type para:

a. Crear un nuevo objeto de la clase Doble de prueba FakeNorthwindContext
b. Agregar 4 nuevos objetos Category a la colección Categories del objeto
FakeNorthwindContext creado
c. Pasar el objeto FakeNorthwindContext al constructor del Controlador

CategoryController.
Observa que en el código se ha creado una colección de 4 objetos Category y se ha

convertido esa colección al tipo IQueryable para poder asignarla a la propiedad Categories
de tipo IQueryable del objeto FakeNorthwindContext.
5. Modifica el código de la Prueba Unitaria Test_GetImage_Return_Type para:

FakeNorthwindContext creado utilizando la siguiente información:
i. CategoryID: Un valor único entero
ii. Picture: Un nuevo arreglo de bytes de longitud 0.
CategoryController.
6. Modifica el código de la Prueba Unitaria Test_Display_Model_Type para:

FakeNorthwindContext creado utilizando la siguiente información:
i. CategoryID: Un valor único entero
CategoryController.
7. Compila el proyecto Northwind.Tests y verifica que compile con éxito. Verifica también que
las pruebas unitarias se ejecuten exitosamente.
8. Ejecuta la aplicación Northwind y verifica que todo esté funcionando con éxito.
Utilizando Frameworks de simulación (Mocking Frameworks)
Cuando escribimos una prueba unitaria, durante la fase de Preparación debemos crear los
datos de prueba sobre los cuales la prueba se ejecutará. Mediante el uso de un Doble de
Prueba para suplir los datos de prueba, podemos probar nuestro código en aislamiento de
otras clases y de los elementos de infraestructura tales como bases de datos y conexiones
de red sobre los cuales la aplicación dependerá. Podemos crear Dobles de prueba
codificando manualmente su instanciación, estableciendo sus propiedades y llenando sus
colecciones. Tales Dobles de Prueba son conocidos como Objetos de Simulación (mock
objects) Manuales.
Alternativamente, en lugar de crear objetos mock manualmente con nuestro propio

código, podemos utilizar un Framework de Simulación (Mocking Framework) para
automatizar este trabajo. Un Framework Mocking crea automáticamente objetos Mock
mediante el uso de interfaces que nosotros especificamos. En el caso de contenedores IoC,
existen muchos Frameworks Mocking que pueden ser utilizados para probar aplicaciones
web MVC. Podemos encontrar diversos Frameworks Mocking utilizando el administrador
de paquetes NuGet.
Algunos de los Frameworks de simulación para ASP.NET MVC que podemos mencionar se
encuentran Moq, RhinoMocks y NSubstitute entre otros. Todos esos Frameworks están
disponibles en NuGet.
¿Por qué utilizar un Framework de Simulación?
Existen diversas situaciones en las cuales los frameworks de simulación pueden simplificar
significativamente las pruebas unitarias. Incluso para pruebas simples, los frameworks
mocking reducen la cantidad de código inicial que tenemos que desarrollar. Después de
familiarizarnos con el framework mocking que hayamos seleccionado y hayamos
aprendido a escribir el código de preparación para él, empezaremos a ahorrar tiempo. En
situaciones más complejas, tales como las siguientes, los frameworks mocking tienen
grandes ventajas:
• Creación de múltiples objetos mock de un sólo tipo. Debemos tratar de mantener

cada prueba unitaria tan simple como sea posible, pero inevitablemente, algunas
pruebas requieren muchos objetos mock para trabajar con ellos. Por ejemplo, si
estamos probando un método relacionado con funcionalidad de paginación en
nuestra aplicación web, debemos crear suficientes objetos mock para llenar
múltiples páginas. Los frameworks mocking pueden automatizar la creación de
múltiples objetos mock del mismo tipo.
• Objetos mock con múltiples interfaces. En algunas pruebas, donde existen varias
dependencias entre clases de tipos diferentes, debemos crear muchos objetos
mock de diferentes clases. En tales situaciones, es tedioso codificar manualmente
muchos objetos mock. Los frameworks mocking pueden ayudar mediante la
generación automática de objetos a partir de las interfaces que nosotros
especifiquemos.
En cada prueba unitaria, nos interesamos en un área pequeña y especifica de

funcionalidad. Algunas propiedades y métodos de una interface serán cruciales a nuestras
pruebas mientras que otras serán irrelevantes. Un framework mocking nos permite
especificar las propiedades y métodos irrelevantes en una prueba dada. Cuando el
framework crea un objeto mock para una prueba, este crea implementaciones simples
con poco código para las propiedades y métodos irrelevantes, estas implementaciones
simples son conocidas como stubs. De esta forma, el framework mocking nos libera de
tener que implementar todos los requerimientos laboriosos de la interface.
¿Cuál es la diferencia entre un contenedor IoC y un Framework Mocking?
Un contenedor IoC asegura que las clases correctas sean creadas e inyectadas para cada
dependencia cuando la aplicación Web se ejecuta. En contraste, un Framework Mocking
asegura que los Dobles de prueba u objetos mock sean creados y utilizados durante las
pruebas.
Tarea 6: Agregar pruebas adicionales
Se ha solicitado un cambio en la aplicación para que en caso de que sea requerido, se muestre un
número específico de categorías de productos en lugar de mostrar todas las categorías de productos
disponibles. Para implementar esta nueva funcionalidad, modificarás el método de acción
_CategoryList del Controlador Category para que acepte un parámetro opcional indicando el número
de categorías que serán devueltas en el Modelo. Si el parámetro no es proporcionado, devolverá
todas las categorías de productos disponibles.
Siguiendo con los principios de TDD, antes de implementar la nueva funcionalidad, crearás dos
pruebas unitarias que comprueben el funcionamiento del método _CategoryList: una prueba unitaria
Test_CategoyList_Int_Parameter que proporcione un valor al método y otra prueba unitaria
Test_CategoyList_No_Parameter que no proporcione valor.
1. En el archivo CategoryControllerTests.cs, agrega una nueva prueba unitaria llamada

Test_CategoyList_No_Parameter. Esta prueba unitaria verificará que cuando invoques al
método _CategoryList sin un parámetro, el método de acción proporcione a la vista parcial
_CategoryList todas las categorías en el Contexto.
2. Modifica el código de la Prueba Unitaria Test_CategoyList_No_Parameter para que en la

fase Preparar (Arrange) la prueba pueda:
CategoryController.
3. Agrega el siguiente código a la prueba unitaria para invocar al método _CategoryList sin
proporcionarle argumentos. Este código es el que se ejecutará en la fase Actuar (Act) de la
prueba unitaria.
4. Agrega el siguiente código a la prueba unitaria para verificar que el número de elementos del
Modelo de la vista parcial devuelta sea igual a 4, este es el número de elementos que
agregaste al Repositorio. Este código se ejecutará en la fase Assert.
5. Compila el proyecto Northwind.Tests y verifica que todas las pruebas sean ejecutadas y
aprobadas exitosamente.
6. En el archivo CategoryControllerTests.cs, agrega una nueva prueba unitaria llamada
Test_CategoyList_Int_Parameter. Esta prueba unitaria verificará que cuando invoques al
método _CategoryList con un parámetro entero, el método de acción proporcione a la vista
parcial _CategoryList el número de categorías correspondiente.
7. Modifica el código de la Prueba Unitaria Test_CategoyList_Int_Parameter para que en la fase

Preparar (Arrange) la prueba pueda:
CategoryController.
8. Agrega el siguiente código a la prueba unitaria para invocar al método _CategoryList

pasándole el valor 3 como argumento. Este código es el que se ejecutará en la fase Actuar
(Act) de la prueba unitaria.
9. Agrega el siguiente código a la prueba unitaria para verificar que el número de elementos del
Modelo de la vista parcial devuelta sea igual a 3, este es el valor que proporcionaste al
método _CategoryList. Este código se ejecutará en la fase Assert.
10. Modifica la firma del método _CategoryList del controlador Category para que reciba un
parámetro opcional entero. De esta forma el proyecto Northwind.Tests podrá compilar
exitosamente.
11. Compila el proyecto Northwind.Test. Verifica que compile exitosamente y que la prueba
Test_CategoyList_Int_Parameter ha fallado debido a que la prueba esperaba un valor 3 pero
recibió un valor 4. El código actual del método _CategoryList devuelve todos los elementos
de la colección Categories que en este caso es de 4 elementos.
12. Modifica ahora el método _CategoryList del controlador Category para implementar la
funcional requerida. El método debe aceptar un parámetro opcional indicando el número de
categorías que serán devueltas en el Modelo. Si el parámetro no es proporcionado,
devolverá todas las categorías de productos disponibles.
13. Ejecuta las pruebas unitarias y verifica que sean ejecutadas exitosamente.
14. Modifica el código de la vista Index del controlador Category para que muestre únicamente
los datos de las 2 primeras categorías.
15. Ejecuta la aplicación y verifica que únicamente se muestren las 2 primeras categorías.
Resumen
En este laboratorio, se presentó una técnica que podemos utilizar para eliminar errores en una
aplicación web ASP.NET MVC. Esta técnica inicia de manera temprana en la fase de desarrollo del
proyecto, cuando definimos pruebas unitarias que aseguren que cada clase y método en la aplicación
se comporte exactamente como fue diseñado.
Es posible configurar Visual Studio para que las pruebas unitarias se vuelvan a ejecutar de forma
automática cada vez que compilemos la aplicación para que podamos estar seguros de que los
métodos y clases que funcionaban antes sigan funcionando después de agregar nuevo código.
Mejores prácticas:
• Si estamos utilizando TDD o Programación Extrema, debemos definir cada prueba antes de
escribir el código que implementa un requerimiento. Utilicemos la prueba como una
especificación completa que nuestro código debe satisfacer. Esto requiere una comprensión
completa del diseño.
• Debemos investigar y elegir un Framework de Simulación (Mocking Framework) que nos
ayude a crear objetos Doble de Prueba para utilizarlos en las pruebas unitarias. A pesar de
que puede tomarnos tiempo el elegir el mejor Framework y el aprender a codificar objetos
de simulación (mock objects), nuestra inversión de tiempo valdrá la pena durante la
realización del proyecto.
• Debemos evitar la tentación de saltarnos las pruebas unitarias cuando estemos bajo presión
de tiempo. Si lo hacemos, podemos introducir errores en el sistema que nos puede llevar a
necesitar más tiempo para realizar la depuración.
Lección 2
Implementando una estrategia para el manejo de
Excepciones
Los eventos inesperados ocurren de vez en cuando en cualquier sistema complejo incluyendo a las
aplicaciones Web MVC. Ocasionalmente, tales eventos inesperados en tiempo de ejecución causan
errores. Cuando esto sucede, ASP.NET o el .NET Framework generan una excepción que es un objeto
que podemos utilizar para diagnosticar y resolver el error. La excepción contiene información que
podemos utilizar para diagnosticar el problema.
Las excepciones que no son manejadas en nuestro código causarán que la aplicación Web se detenga
y un mensaje de error sea mostrado al usuario. Como desarrollador Web, necesitamos conocer cómo
detectar, manejar, disparar excepciones e identificar la causa del problema. Visual Studio
proporciona una amplia gama de herramientas para depurar excepciones y mejorar la robustez de
nuestro código. También podemos registrar excepciones en bases de datos y otros tipos de
almacenamiento.
• Explicar cómo disparar y atrapar excepciones.

• Explicar cómo configurar el manejo de excepciones utilizando el Web.config.
• Explicar cómo dar seguimiento a excepciones utilizando la herramienta IntelliTrace.
• Describir como registrar excepciones.
• Describir las opciones de monitoreo de salud para las aplicaciones Web MVC.
Disparando y atrapando excepciones

Un error es un evento inesperado en tiempo de ejecución que evita que una aplicación pueda
finalizar una operación. Cuando una línea de código causa un error, ASP.NET o el CLR crean una
excepción. Esta excepción es un objeto de una clase que hereda de la clase base System.Exception.
Existen muchas clases Excepción. Normalmente, los objetos excepción identifican lo que sucedió mal.
Por ejemplo, si existe un ArgumentNullException, esto indica que un valor null fue enviado a un
método que no acepta un valor null como argumento.
Excepciones no manejadas
Cuando una excepción no es manejada explícitamente por una aplicación, la aplicación se detiene y
el usuario ve un mensaje de error. En las aplicaciones ASP.NET MVC, este mensaje de error se
muestra en una página Web. Podemos remplazar las páginas de error predeterminadas de ASP.NET
MVC para mostrar nuestra propia información de error a los usuarios.
Si una excepción no manejada se dispara mientras estamos ejecutando la aplicación en modo Debug
desde Visual Studio, la ejecución se interrumpe en la línea que generó la excepción. Podemos utilizar
las herramientas de depuración de Visual Studio para investigar qué fue lo que falló, aislar el
problema y depurar nuestro código.
Algunas veces, también podríamos querer lanzar nuestras propias excepciones como una forma de
comunicación entre partes de nuestra aplicación. Por ejemplo, consideremos una aplicación que
muestra productos en un sitio Web. En el Repositorio, implementamos un método FindProduct que
devuelva un producto con un nombre igual al proporcionado como argumento del método. Si el
método FindProduct no encuentra al producto con el nombre especificado, podríamos desear lanzar
una excepción. Este enfoque permite al código en el Controlador que invoca al método FindProduct,
manejar el evento que indica que no se han encontrado productos. Podemos utilizar la palabra clave
throw para lanzar errores en código C#.
Atrapando errores con bloques Try/Catch

La forma más familiar de atrapar una excepción y que funciona en cualquier código .NET es utilizando
el bloque try/catch. El código en el bloque try es ejecutado. Si alguna parte de ese código genera una
excepción, el tipo de excepción es comparado contra el tipo declarado en el bloque catch. Si el tipo
es el mismo o si es de un tipo derivado del tipo declarado en el bloque catch, el código en el bloque
catch es ejecutado. Podemos utilizar el código del bloque catch para obtener información acerca de
lo que falló y resolver la condición de error.
El siguiente ejemplo de código, atrapa cualquier objeto ProductNotFoundException.
try
{
var Product =
repository.FindProduct(ProductName);
}
catch(ProductNotFoundException ex)
{
ErrorMessage = ex.Message;
}
En Controladores MVC, hay 2 métodos para atrapar excepciones: el método OnException y la

anotación [HandleError].
Atrapando Excepciones de Controladores con el método

OnException
El método OnException está definido en la clase base Controller por lo que podemos sobrescribirlo
en cualquier Controlador MVC. Cuando sobrescribimos el método OnException en un Controlador
personalizado, MVC ejecuta el método cuando una excepción es generada y no es manejada en un
bloque try/catch. Utilizando este enfoque, podemos manejar los errores en cualquier parte del
Controlador sin agregar muchos bloques try/catch por todas partes del código.
En el método OnException, podemos atrapar tipos específicos de excepciones examinando la

propiedad Exception del objeto ExceptionContext que recibe como parámetro. Nuestro código debe
establecer la propiedad Result del objeto ExceptionContext para mostrar una Vista al usuario. Si no
establecemos esta propiedad, el explorador Web muestra una página en blanco al usuario. También
es importante indicar que ya hemos evaluado la Excepción estableciendo el valor true a la propiedad
ExceptionHandled del objeto ExceptionContext. De esta forma se mostrará la Vista especificada en
filterContext.Result y no la página de error predeterminada.
Si la propiedad filterContext.ExceptionHandled se establece en true y no se establece el valor para la

propiedad filterContext.Result, al usuario se le muestra una página en blanco. Por otro lado, si la
propiedad filterContext.ExceptionHandled se establece en false o no se le asigna valor (false es el
valor predeterminado de esta propiedad), se mostrará al usuario la página de error predeterminada
ya que esto indicará que no se ha manejado la Excepción.
En el siguiente ejemplo de código, el método OnException es utilizado para atrapar objetos

ProductNotFoundException.
protected override void OnException(

ExceptionContext filterContext)
{
if(filterContext.Exception is
ProductNotFoundException)
{
// Encapsulamos información del error
var ControllerName =
filterContext.RouteData.Values["Controller"].
ToString();
var ActionName =
filterContext.RouteData.Values["Action"].ToString();
var Model =
new HandleErrorInfo(
filterContext.Exception, ControllerName, ActionName);
// Establecemos la Vista que mostrará el error
var Result = new ViewResult
{
ViewName = "Error",
// La vista recibe un Modelo HandleErrorInfo
ViewData =
new ViewDataDictionary<HandleErrorInfo>(Model),
// Pasamos TempData porque podría contener
// información de diagnóstico
TempData = filterContext.Controller.TempData
};
// Si no establecemos esta propiedad, se muestra
// al usuario una página en blanco
filterContext.Result = Result;
// Indicar que ya hemos evaluado la Excepción para que
// se muestre la Vista filterContext.Result y no la
// página de error predeterminada.
// Si filterContext.ExceptionHandled = true y no se
// establece el valor para filterContext.Result, al
// usuario se le muestra una página en blanco.
// Si filterContext.ExceptionHandled = false, se
// muestra la página de error predeterminada.
filterContext.ExceptionHandled = true;
}
}
El siguiente ejemplo muestra el código de la Vista que proporciona el detalle de la excepción al

usuario. Nota que la Vista recibe una instancia System.Web.Mvc.HandleErrorInfo como Modelo.
@model System.Web.Mvc.HandleErrorInfo
@{
Layout = null;
}
<!DOCTYPE html>
<html>
<head>
<meta name="viewport" content="width=device-width" />
<title>Error</title>
</head>
<body>
@if (Model != null)
{
<div>
Controlador: @Model.ControllerName <br />
Acción: @Model.ActionName<br />
Mensaje: @Model.Exception.Message
</div>
}
</body>
</html>
Atrapando excepciones de controladores con HandleError

Utilizando la anotación [HandleError], podemos utilizar un atributo sobre métodos de acción
individuales o sobre la clase Controller misma, en cuyo caso, la anotación [HandleError] atrapa los
errores de cualquier acción. Cuando utilizamos la anotación [HandleError] sin propiedades, todas las
excepciones son capturadas y enviadas a una vista MVC llamada Error.cshtml. Esta vista
predeterminada de error debe ser creada en el folder /Views/Shared. Para activar la funcionalidad
del atributo HandleError debemos habilitar el manejo de errores personalizado en el archivo de
configuración Web.config.
Podemos utilizar 2 propiedades para controlar el comportamiento de [HandleError]:
• ExceptionType. De manera predeterminada, la anotación [HandleError] atrapa todas las

excepciones. Si nosotros establecemos un tipo más específico con la propiedad
ExceptionType, únicamente las excepciones de ese tipo específico serán atrapadas.
• View. De manera predeterminada, la anotación [HandleError] redirige a los usuarios a la
Vista Error.cshtml. Nosotros podemos especificar otro archivo de Vista utilizando la
propiedad View. Al establecer tanto la propiedad ExceptionType como la propiedad View,
podemos desviar excepciones de tipos específicos a Vistas diseñadas específicamente para
ellos.
En el siguiente código de ejemplo, la segunda anotación [HandleError] desvía errores

ProductNotFoundException hacia la Vista ProductNotFound. Todos los demás errores son desviados
hacia la Vista de error Error.cshtml.
[HandleError]
[HandleError(
ExceptionType = typeof(ProductNotFoundException),
View = "ProductNotFound")]
{
return null;
}
La Vista invocada recibe una instancia System.Web.Mvc.HandleErrorInfo como Modelo desde el cual
podemos acceder a los datos de la excepción.
Configurando el manejo de Excepciones

Las aplicaciones ASP.NET MVC muestran una página de error predeterminada a los usuarios cuando
una excepción no manejada ocurre en la aplicación Web MVC. Hay 2 razones del porque quisiéramos
cambiar la página de error predeterminada:
• Queremos mostrar una página de error con el mismo diseño de las otras páginas del sitio
Web y que incluyen el logo de la empresa.
• Queremos ocultar el detalle de la tecnología que utiliza el sitio. Al dar a conocer a los
usuarios maliciosos que un sitio ejecuta una determinada tecnología, puede animarlos a
atacarlo mediante el uso de métodos que han funcionado en el pasado.
Para configurar una página de error personalizada para nuestra aplicación, utilizamos el archivo
Web.config de nivel superior. La página de error personalizada será mostrada cuando una excepción
no sea manejada por la aplicación.
Modos de errores personalizados

Para configurar errores personalizados, debemos agregar el elemento <customErrors> al archivo
Web.config. Este elemento debe ser un hijo del elemento <system.web>. Utilizamos los siguientes
atributos:
• mode: El atributo mode puede ser establecido con uno de tres posibles valores:
o Off: Los errores no manejados son mostrados en la página de error ASP.NET
predeterminada.
o On: Los errores no manejados son mostrados en la página que nosotros
especifiquemos en el atributo defaultRedirect.
o RemoteOnly: En este modo, los errores no manejados son mostrados de forma
diferente para el explorador Web en computadoras remotas y el explorador Web en
el servidor. En un sitio en producción, todos los navegadores son remotos y los
errores son mostrados en la página que especifiquemos en el atributo
defaultRedirect. En ambientes de desarrollo, el desarrollador navega por el sitio en
la computadora local. Cuando un error ocurre, el desarrollador es dirigido a la página
de error ASP.NET predeterminada la cual incluye información de depuración tal
como el seguimiento del stack. Utilizamos el modo RemoteOnly en computadoras de
desarrollo.
• defaultRedirect: Este atributo especifica la dirección URL predeterminada a la que hay que
dirigir a un explorador Web para mostrar excepciones no manejadas.
El siguiente código de ejemplo, habilita errores personalizados y especifica que las excepciones no
manejadas sean dirigidas a la página Error.html ubicada en la raíz de la aplicación.
<system.web>
<customErrors mode="On" defaultRedirect="~/Error.html"/>
</system.web>
Páginas de error HTTP

Algunos errores HTTP no pueden ser atrapados por Vistas de error MVC personalizadas especificadas
en el archivo Web.config o en la anotación [HandleError]. Para tales errores, podemos utilizar el
elemento <error> en el archivo Web.config como un elemento hijo del elemento <customErrors>.
En el siguiente ejemplo de código, el elemento <error> es utilizado para especificar el archivo HTML
con la respuesta a errores HTTP 500.
<customErrors mode="On" defaultRedirect="Error">

<error statusCode="500"
redirect="~/Error/Error500.html"/>
</customErrors>
Utilizando Visual Studio IntelliTrace en MVC

Cuando algo va mal en nuestra aplicación Web, independientemente de que se encuentre en un
ambiente de desarrollo o de producción, necesitamos información acerca del estado de la aplicación
para diagnosticar el problema. Algunas veces una pequeña cantidad de información es suficiente. Por
ejemplo, desde el URL que el usuario proporciona, podemos ser capaces de ver que el enlace fue
escrito incorrectamente. Sin embargo, frecuentemente los problemas surgen en los lugares menos
esperados y nosotros necesitamos la mayor cantidad de información posible para poder hacer un
diagnóstico. Intellitrace es una característica de Visual Studio que nos ayuda en la depuración
presentándonos la mayor cantidad de información posible. Intellitrace fue introducido con Microsoft
Visual Studio 2010 Ultimate.
Flujo tradicional de depuración

Cuando los desarrolladores depuran código con mal funcionamiento, ejecutan la aplicación en el
modo de depuración de Visual Studio. Si una excepción no manejada ocurre, Visual Studio detiene la
ejecución y muestra detalles tal como la clase excepción y el mensaje de la excepción. Podemos
utilizar las ventanas Locals, Call Stack y Error List para determinar los valores de variables y
propiedades que podrían haber causado la excepción. Todas estas piezas de información son
presentadas tal y como se encontraban cuando el error ocurrió.
Si un problema se originó antes de que ocurriera el error, debemos detener la depuración, establecer
un punto de ruptura y luego reiniciar la depuración. Nuevamente, Visual Studio detiene la ejecución,
pero esta vez, en el punto de ruptura. Podemos utilizar las mismas ventanas para obtener
información y desplazarnos por el código, línea por línea, para ver cómo cambian los valores y
diagnosticar el error.
Dos problemas pueden ocurrir en este flujo de depuración:
• Si establecemos el punto de ruptura demasiado lejos, podríamos perder el origen del error.
Debemos establecer otro punto de ruptura y reiniciar la depuración.
• Si estamos desplazándonos a través de muchas líneas de código, podríamos perder el origen
del error seleccionando Debug|StepInto o presionando F11 demasiadas veces. Es fácil que
suceda esto cuando tenemos cientos de líneas de código que recorrer.
Depurando con IntelliTrace

IntelliTrace mejora el flujo de trabajo y aborda los dos problemas que surgen durante el flujo de
trabajo de depuración tradicional mediante la grabación de una línea de tiempo de ejecución de
código. Cuando ejecutamos una aplicación en modo Debug, IntelliTrace registra todos los eventos
que ocurren en segundo plano. Esto incluye excepciones, eventos de depuración tales como puntos
de ruptura y otros eventos que nosotros podemos configurar.
Como antes, cuando el depurador encuentra una excepción no controlada o un punto de ruptura,
Visual Studio detiene la ejecución y muestra los detalles de cualquier excepción. Sin embargo, el
desarrollador ahora puede ver en el panel de IntelliTrace todos los eventos grabados. El evento
actual aparece al final de la lista y es nombrado Evento vivo (Live Event). Podemos ver todos los
eventos anteriores en la lista y hacer clic en ellos para ver más detalles. De esta manera, podemos
investigar lo que ocurrió antes de la excepción o el punto de ruptura.
Al hacer clic en un evento anterior en el panel de IntelliTrace, las ventanas Locals, Call Stack y Error
List, muestran el estado de la aplicación en el momento del evento anterior. La línea de código que
corresponde al evento seleccionado es resaltada en color naranja. Gracias a este resaltado, los dos
problemas que surgen durante el flujo de depuración tradicional se solucionan, es decir, la pérdida
del origen del error y el alejarnos demasiado del origen del error cuando presionamos F11
repetidamente. Dado que el código relevante es resaltado, si perdemos el origen del error o nos
alejamos demasiado al recorrer el código, podemos regresar a los eventos anteriores e investigar los
valores.
Para ayudarnos a localizar el evento correcto en la ventana IntelliTrace, podemos filtrar por categoría
de evento o de hilo de ejecución, o utilizar la opción de búsqueda.
Opciones de configuración de IntelliTrace

Para configurar IntelliTrace, damos clic en DEBUG, clic en IntelliTrace y luego clic en Open
IntelliTrace Settings. Podemos habilitar o deshabilitar la grabación de eventos y especificar la
ubicación y el tamaño máximo de los archivos IntelliTrace.
La mayoría de las opciones de configuración se refieren a la cantidad de datos a registrar en los

archivos IntelliTrace. Los valores predeterminados tienen un efecto mínimo en el rendimiento, pero
si esos valores son insuficientes para diagnosticar un problema, podemos optar por registrar más
información para diagnosticar el problema. Esto puede afectar al rendimiento, pero recordemos que
la información IntelliTrace sólo se registra durante la depuración. Los valores configurados no
reducirán el rendimiento después de que la aplicación sea implementada en el servidor Web. En la
opción General, podemos configurar IntelliTrace para registrar sólo los eventos de IntelliTrace, o
ambos eventos IntelliTrace e información de llamadas, que incluye todas las llamadas a métodos y
clases. Podemos configurar lo que deseamos que sea incluido en los eventos de IntelliTrace
utilizando la lista de la opción IntelliTrace Events. Por ejemplo, de manera predeterminada, los
eventos ASP.NET, tales como páginas de error, post backs de página y redireccionamientos son
incluidos para aplicaciones MVC.
Guardando y Abriendo archivos IntelliTrace
IntelliTrace guarda automáticamente los eventos en un archivo IntelliTrace cuando entramos en

modo Debug. El archivo es temporal y es eliminado automáticamente al cerrar Visual Studio para
asegurar que los archivos IntelliTrace no ocupen demasiado espacio en disco.
Podemos evitar la pérdida de un archivo IntelliTrace al cerrar Visual Studio guardándolo para su
posterior análisis. Para ello, hacemos clic en DEBUG, clic en IntelliTrace, y luego clic en Save
IntelliTrace Session. El archivo se guarda con una extensión .iTrace. Si hacemos doble clic en un
archivo .iTrace, Visual Studio muestra los hilos, excepciones, módulos, y otra información que
contenga el archivo.
Para más información acerca de IntelliTrace y cómo utilizarlo, se recomienda visitar

el siguiente enlace:
Debugging Applications with IntelliTrace

Registro de Excepciones
Las excepciones que enfrentamos durante el desarrollo pueden ser investigadas y depuradas
mediante el uso de las herramientas de depuración de Visual Studio, incluyendo IntelliTrace. En una
situación ideal, no surgiría ninguna excepción cuando la aplicación Web esté terminada y desplegada
para los usuarios a través de Internet. Sin embargo, en el mundo real, se presentan circunstancias
imprevistas que dan como resultado a las excepciones. Por ejemplo, fallas de base de datos,
problemas de red, y los errores de configuración en cualquier parte del sistema pueden causar
excepciones.
En este momento, ya hemos aprendido a mostrar páginas de error personalizadas a los usuarios
cuando ocurren excepciones, sin embargo, también es conveniente registrar y guardar las
excepciones que ocurren en una aplicación Web en producción para que los administradores y
desarrolladores puedan evaluar el alcance del problema, eliminar la causa, y mejorar la robustez del
código.
Escribiendo código para registro de errores

Antes de escribir código para registrar excepciones en nuestra aplicación Web, debemos considerar
el lugar donde deben ser registradas. Generalmente, las aplicaciones Web registran excepciones a un
archivo XML. Este enfoque puede ser eficiente, sobre todo si el archivo de texto se guarda en una
unidad separada de la base de datos de la aplicación Web y de otros archivos críticos accedidos
comúnmente. Sin embargo, el tamaño de los archivos XML puede aumentar de tamaño, haciéndolos
difícil de analizar.
Un enfoque común es registrar los errores en tablas de una base de datos. Estas tablas pueden ser
parte de la base de datos de la aplicación Web o podemos colocarlas en una base de datos
independiente. Al registrar las excepciones en una base de datos, creamos una lista de excepciones
que pueden ser fácilmente buscadas y analizadas. También podemos crear una página Web para
presentar esas excepciones registradas a los administradores para que puedan acceder a los detalles
desde un navegador Web.
También debemos considerar el envío de mensajes de correo electrónico u otro tipo de mensajes a
los administradores y desarrolladores cuando se produzcan excepciones. Este enfoque garantiza que
los administradores y desarrolladores se enteren de un error de manera rápida. Esto no requiere que
revisen las excepciones registradas en la base de datos. Con frecuencia, el código de manejo de
errores en aplicaciones registra el detalle completo de las excepciones a una base de datos y envía
mensajes de correo electrónico a los administradores y desarrolladores.
¿Dónde escribir código para registro de errores?
Cuando decidamos dónde escribir el código que registra los errores, debemos considerar que los
errores pueden surgir en cualquier parte de la aplicación. Debemos elegir un enfoque que nos
permita escribir código de registro de errores para poder registrar cualquier error que surja en
cualquier parte de la aplicación.
Por ejemplo, no es apropiado escribir código de registro de errores en bloques try/catch individuales.
Si hacemos esto, tendremos que crear un bloque try/catch para cada procedimiento en nuestra
aplicación, y escribir código de registro duplicado en el bloque catch.
Un enfoque más efectivo es el siguiente:
• Crear una clase Controller base personalizada para la aplicación Web. Esta clase debe
heredar de la clase base System.Web.Mvc.Controller.
• En la clase base Controller personalizada, remplazamos el método OnException. Colocamos
el código de registro de errores en este método.
• Al crear Controladores, debemos heredar de la clase base Controller personalizada en lugar
de System.Web.Mvc.Controller.
De esta manera, podemos escribir código de registro de errores sólo una vez en el método
OnException reemplazado. Esto atrapará excepciones de cualquiera de los Controladores que
hereden esta clase.
Utilizando herramientas de registro de errores de terceros

Dado que el registro de excepciones es un requisito funcional muy común para aplicaciones Web,
existen muchas soluciones de terceros que podemos elegir si nosotros no deseamos escribir nuestro
propio código de registro. Muchos de estos están disponibles dentro de Visual Studio desde el gestor
de paquetes NuGet.
Probablemente, el paquete de registro de errores más utilizado y ampliamente soportado es el

paquete Error Logging Modules and Handlers (ELMAH). ELMAH puede ser utilizado con cualquier
aplicación Web ASP.NET y puede registrar excepciones a archivos XML o una amplia variedad de
bases de datos, incluyendo Microsoft SQL Server, Oracle, Microsoft SQL Server Compact, MySQL y
otras. Además, ELMAH incluye páginas Web que podemos utilizar para ver remotamente listas de
excepciones y detalles. ELMAH también puede enviar mensajes de correo electrónico de alerta a las
direcciones que configuremos.
Monitoreo de salud en ASP.NET (ASP.NET Health Monitoring)

ASP.NET Health Monitoring es una característica que permite a los administradores de sistemas
monitorear el estado de las aplicaciones Web desplegadas.
Desde la versión 2.0 de ASP.NET, podemos utilizar las características de monitoreo de salud para
registrar lo que sucede en una aplicación Web. Las características de monitoreo de salud pueden
registrar excepciones a través de técnicas de registro de errores. Sin embargo, el monitoreo de la
salud también puede registrar una amplia variedad de otros eventos tales como el inicio y fin de
ejecución de la aplicación, los intentos fallidos de inicio de sesión, eventos de membresía, y los
errores de validación de entrada del usuario. Algunas piezas de esta información son difíciles de
acceder desde alguna otra fuente.
Categorías de Eventos de Monitoreo de Salud

Podemos personalizar la categoría de eventos que la característica de Monitoreo de Salud registra.
Cada evento se encuentra dentro de una de las 5 categorías siguientes:
Categoría de evento Descripción

Application Lifetime Events Los eventos del ciclo de vida de la aplicación incluyen el inicio y
fin de ejecución de la aplicación.
Audit Events Los eventos de auditoria incluyen Inicio y Fin de sesión así
como los fallos de inicio de sesión.
Error Events Los eventos de error incluyen excepciones del .NET Framework
y errores HTTP tales como los errores 404 de recursos no
encontrados.
Request Processing Events Los eventos de procesamiento de peticiones incluyen eventos
que ocurren cuando los Controladores, Modelos y Vistas
ASP.NET reciben y responden a peticiones de páginas Web.
Heartbeats Los Heartbeats son eventos periódicos que el Monitoreo de
Salud puede lanzar y registrar para confirmar que la aplicación
sigue ejecutándose.
También podemos personalizar la ubicación donde el Monitoreo de Salud debe almacenar el detalle
de los eventos mediante la configuración de los proveedores de Monitoreo de Salud. Podemos elegir
entre los siguientes proveedores.
Proveedor de Monitoreo de Descripción

Salud
EventLogWebEventProvider Este proveedor envía los eventos hacia el Log de eventos
de Aplicaciones de Windows. Estos eventos aparecen en el
Windows Application Event Log.
SqlWebEventProvider Este proveedor envía los eventos hacia una base de datos
SQL Server.
WmiWebEventProvider Este proveedor envía los eventos hacia un cliente Windows
Management Infrastructure (WMI).
SimpleMailWebEventProvider Este proveedor envía los eventos en un mensaje de correo
electrónico hacia la dirección que nosotros especifiquemos.
TemplatedMailWebEventProvider Este proveedor también envía los eventos en un mensaje
de correo electrónico, pero en este caso, podemos utilizar
una plantilla de correo para dar formato a la información.
TraceWebEventProvider Este proveedor envía los eventos al sistema de seguimiento
(Tracing) de ASP.NET.
Configurando el Monitoreo de Salud

Configuramos el Monitoreo de Salud mediante el uso del elemento <healthMonitoring> dentro del
elemento <system.web> en el archivo Web.config. Podemos utilizar elementos dentro de
<healthMonitoring> para agregar y configurar los proveedores y definir las reglas que rigen la forma
en que son registrados los eventos de diferentes tipos.
El ejemplo de código siguiente muestra cómo configurar el Monitoreo de Salud para registrar los
eventos del ciclo de vida de la aplicación hacia una base de datos SQL Server.
<system.web>
<healthMonitoring enabled="true">
<providers>
<add name="SQLProvider"
type="System.Web.Management.SqlWebEventProvider"
connectionStringName="HealtDB"
buffer="false"
bufferMode="Notification"/>
</providers>
<rules>
<add name="LifeCycle"
provider="SQLProvider"
eventName="Application Lifetime Events"/>
</rules>
</healthMonitoring>
</system.web>
Para conocer más acerca de las distintas opciones de Monitoreo de Salud que
podemos configurar en el archivo Web.config, se recomienda visitar el siguiente
enlace:
FAQ - Health Monitoring in ASP.NET 2.0

Si configuramos el Monitoreo de Salud para utilizar el proveedor SqlWebEventProvider, ASP.NET de

forma predeterminada creará un archivo de base de datos llamado ASPNETDB.MDF en la carpeta
App_Data de la aplicación Web. Podemos modificar esta ubicación mediante el uso de una cadena
de conexión en el archivo Web.config. Sin embargo, el Monitoreo de Salud sólo funcionará si ciertas
tablas de datos existen en la base de datos a la que nos conectamos. Podemos preparar la base de
datos con las tablas correctas mediante el uso de la herramienta aspnet_regsql.exe. Esta
herramienta se encuentra en la carpeta % WINDOWS%\Microsoft.NET\Framework\<versión>.
El siguiente comando prepara una base de datos SQL Server para Monitoreo de Salud autenticándose
con la cuenta del usuario actual.
aspnet_regsql.exe –E –S HealthDatabaseServer –d HealthDatabase –A w
Laboratorio:
Implementando una estrategia para el manejo de
Excepciones
Una vez que has configurado las Pruebas Unitarias para la aplicación Northwind, el siguiente paso
será configurar una estrategia para manejo de excepciones. La estrategia para manejo de
excepciones en la aplicación ASP.NET Web MVC te permitirá atrapar las excepciones que se generen
durante la ejecución de la aplicación y mostrar los mensajes en una vista MVC personalizada.
Objetivos
Al finalizar este laboratorio, serás capaz de:
• Configurar una estrategia para manejo de excepciones en una aplicación Web ASP.NET MVC.
• Configurar el manejo de excepciones utilizando el archivo Web.config.
Requisitos
Para la realización de este laboratorio es necesario contar con un equipo de desarrollo con:
• Visual Studio 2013 o posteriores.
• Microsoft SQL Server 2012 o posteriores.
• Base de datos Northwind.
• Solución de la aplicación Northwind.
Puedes utilizar una máquina virtual como equipo de desarrollo.
Tiempo estimado para completar este laboratorio: 60 minutos.
Ejercicio 1:
Disparando y atrapando Excepciones
Un error es un evento inesperado en tiempo de ejecución que evita que una aplicación pueda
finalizar una operación. Cuando una línea de código causa un error, ASP.NET o el CLR crean una
excepción. Esta excepción es un objeto de una clase que hereda de la clase base System.Exception.
Cuando una excepción no es manejada explícitamente por una aplicación, la aplicación se detiene y
el usuario ve un mensaje de error. En las aplicaciones ASP.NET MVC, este mensaje de error se
muestra en una página web. Podemos remplazar las páginas de error predeterminadas de ASP.NET
MVC para mostrar nuestra propia información de error a los usuarios.
En este ejercicio, modificarás el método INorthwindContext.FindCategoryByID del repositorio

NorthwindContext del proyecto Northwind para que cuando una categoría de producto no sea
encontrada, dispare una excepción de tipo CategoryNotFoundException para notificar al
controlador Category que el ID de la categoría no ha sido encontrada. Una vez que hayas escrito el
código para disparar la excepción, analizarás las distintas opciones para atrapar las excepciones.
Tarea 1: Disparar una excepción personalizada
Antes de agregar el código para disparar la excepción, crearás una clase excepción personalizada que
servirá para notificar al usuario que una categoría de producto no ha sido encontrada. Una vez
creada la excepción personalizada, agregarás el código necesario para disparar la excepción cuando
una categoría de producto buscada no pueda ser encontrada.
6. Abre la aplicación Northwind desde Visual Studio.

7. En la raíz del proyecto Northwind, agrega una nueva carpeta llamada Exceptions. En esta
carpeta agregarás la clase Exception personalizada.
8. Dentro de la carpeta Exceptions, agrega una nueva clase llamada
CategoryNotFoundException.
9. Modifica la declaración de la clase CategoryNotFoundException para que herede de la clase

System.Exception.
10. Agrega un constructor a la clase CategoryNotFoundException para que reciba el ID de la

categoría no encontrada e invoque al constructor de la clase base proporcionándole el
mensaje de error a mostrar.
11. Abre la clase NorthwindContext del proyecto Northwind.

12. Modifica el código del método INorthwindContext.FindCategoryByID para disparar una
excepción CategoryNotFoundException cuando la categoría buscada no pueda ser
encontrada.
13. Ejecuta la aplicación y verifica que la página muestre correctamente la lista de categorías.
14. Modifica el URL para mostrar la categoría de producto 3:

http://<host>/category/display/3
15. Modifica el URL para mostrar la categoría de producto 30:

http://<host>/category/display/30
La categoría con el ID 30 no existe por lo que la ejecución se interrumpe en la línea que
generó la excepción. Cuando la aplicación es interrumpida de esta forma, podemos utilizar
las herramientas de depuración que incluyen las ventanas IntelliTrace de Visual Studio para
investigar qué fue lo que falló, aislar el problema y depurar el código.
Observa la excepción que se ha generado y el mensaje de la misma.
16. Presiona F5 para continuar la ejecución de la aplicación.

Cuando una excepción no es manejada explícitamente por una aplicación, la aplicación se
detiene y el usuario ve un mensaje de error. En las aplicaciones ASP.NET MVC, este mensaje
de error se muestra en una página web predefinida. Podemos remplazar las páginas de error
predeterminadas de ASP.NET MVC para mostrar nuestra propia información de error a los
usuarios.
17. Detén la ejecución y regresa a Visual Studio.
Tarea 2: Atrapar excepciones con bloques Try/Catch
La forma más familiar de atrapar una excepción y que funciona en cualquier código .NET es utilizando
el bloque try/catch. El código en el bloque try es ejecutado. Si alguna parte de ese código genera una
excepción, el tipo de excepción es comparado contra el tipo declarado en el bloque catch. Si el tipo
es el mismo o si es de un tipo derivado del tipo declarado en el bloque catch, el código en el bloque
catch es ejecutado. Podemos utilizar el código del bloque catch para obtener información acerca de
lo que falló y resolver la condición de error.
1. Modifica el método Display del controlador Category en el proyecto Northwind para agregar
un bloque try/catch que permita atrapar la excepción en el caso de que la categoría buscada
no pueda ser encontrada.
2. En el cuerpo del bloque catch agrega el siguiente código para crear una instancia de la clase
HandleErrorInfo. La clase HandleErrorInfo encapsula información para manejar un error que
haya sido disparado por un método de acción. El constructor de la clase HandleErrorInfo
recibe la excepción, el nombre del controlador y el método de acción que disparó la
excepción.
3. Debajo del código anterior, agrega el siguiente código para que el método de acción Display
devuelva la Vista Error que utilizará como Modelo una instancia de la clase HandleErrorInfo.
4. Agrega la vista Error en el folder View/Shared del proyecto Northwind utilizando la siguiente
información:
5. Agrega el siguiente código a la vista para definir su Modelo como una instancia del tipo
System.Web.Mvc.HandleErrorInfo.
6. Modifica el cuerpo de la vista para mostrar al usuario el detalle de la excepción.
7. Ejecuta la aplicación y escribe el URL para mostrar los datos de la categoría 30.
Ahora que has atrapado la excepción, se mostrará la vista de error personalizada.
El código que agregaste únicamente atrapa excepciones CategoryNotFoundException. ¿Qué

pasa si ocurre otra excepción distinta a CategoryNotFoundException?
8. Agrega el siguiente código arriba del bloque try/catch del método Display para disparar una
excepción en caso del que el ID recibido sea menor o igual a cero.
9. Ejecuta nuevamente la aplicación e intenta mostrar los datos de la categoría cuyo ID sea
igual a cero.
10. La ejecución se detendrá mostrando los datos de la excepción e indicando que la excepción
no fue manejada.
11. Presiona F5 para continuar la ejecución de la aplicación.

Cuando una excepción no es manejada explícitamente por una aplicación, la aplicación se
detiene y el usuario ve un mensaje de error.
En controladores MVC, hay 2 métodos para atrapar excepciones no manejadas: el método

OnException y la anotación [HandleError].
12. Detén la ejecución y regresa a Visual Studio
Tarea 3: Atrapar excepciones de Controladores con el método OnException
El método OnException está definido en la clase base Controller por lo que podemos sobrescribirlo
en cualquier controlador MVC. Cuando sobrescribimos el método OnException en un controlador
personalizado, MVC ejecuta el método cuando una excepción es generada y no es manejada en un
bloque try/catch. Utilizando este enfoque, podemos manejar los errores en cualquier parte del
Controlador sin agregar muchos bloques try/catch por todas partes del código.
1. En el Controlador Category, agrega el siguiente código para sobrescribir el método

OnException.
En el método OnException, podemos atrapar todas las excepciones no manejadas por

bloques try/catch o bien, podemos atrapar tipos específicos de excepciones examinando la
propiedad Exception del objeto ExceptionContext que recibe como parámetro.
2. Para ejemplificar el uso de la propiedad Exception del objeto ExceptionContext, agrega el

siguiente código al método OnException para atrapar únicamente excepciones del tipo
ArgumentException.
El código del método OnException debe asignar un valor a la propiedad Result del objeto
ExceptionContext para mostrar una vista al usuario. Si no establecemos esta propiedad, el
explorador web mostrará una página en blanco al usuario.
3. Dentro del bloque if del método OnException, agrega el siguiente código para crear una
instancia de la clase HandleErrorInfo. Esta instancia será utilizada como el Modelo de la vista
Error que creaste en una tarea anterior de este ejercicio.
4. Agrega a continuación del código anterior, el siguiente código que te permitirá crear una
instancia de la vista Error que será utilizada para mostrar la información de la excepción.
5. Agrega ahora el siguiente código para indicar la vista que le será mostrada al usuario. Si no
estableces el valor de esta propiedad, se mostrará al usuario una página en blanco.
6. Un punto importante ahora es agregar el siguiente código para indicar que ya se ha evaluado
la excepción estableciendo el valor true a la propiedad ExceptionHandled del objeto
ExceptionContext. De esta forma se mostrará la Vista especificada en filterContext.Result y
no la página de error predeterminada.
Si la propiedad filterContext.ExceptionHandled se establece en true y no se establece el

valor para la propiedad filterContext.Result, al usuario se le muestra una página en blanco.
Por otro lado, si la propiedad filterContext.ExceptionHandled se establece en false o no se le
asigna valor (false es el valor predeterminado de esta propiedad), se mostrará al usuario la
página de error predeterminada ya que esto indicará que no se ha manejado la excepción.
7. Ejecuta la aplicación e intenta desplegar la información de la categoría cuyo ID es 0.
Debido a que estás ejecutando en modo Debug, la aplicación se detendrá mostrando la

excepción.
8. Presiona F5 para continuar la ejecución de la aplicación. Se mostrará la vista personalizada

con el detalle de la excepción.

10. Presiona Ctrl+F5 para ejecutar la aplicación sin depuración.
11. Intenta desplegar la información de la categoría cuyo ID es 0. Automáticamente se mostrará

la página con el detalle de la excepción sin interrumpirse la ejecución.
12. Intenta ahora desplegar la información de la categoría cuyo ID es 20. Automáticamente se

mostrará la página con el detalle de la excepción sin interrumpirse la ejecución.
13. Intenta ahora desplegar la información de la categoría cuyo ID es 2. Se mostrarán los datos
de la categoría correspondiente.
14. Detén la aplicación y regresa a Visual Studio
Tarea 4: Atrapar excepciones de Controladores con la anotación HandleError
Otra forma de atrapar excepciones no manejadas en controladores MVC es a través de la anotación

[HandleError].
Utilizando la anotación [HandleError], podemos utilizar un atributo sobre métodos de acción

individuales o sobre la clase Controller misma, en cuyo caso, la anotación [HandleError] atrapa los
errores de cualquier acción.
1. Abre el archivo CategoryController.cs y agrega la anotación [HandleError] a la clase

CategoryController. Esta anotación colocada sobre la clase CategoryController hará que los
errores no manejados de cualquier método de acción de la clase sean atrapados.
2. Elimina o comenta todo el código del método OnException. Al hacer esto, las excepciones
ArgumentException dejarán de ser manejadas. La idea de esto es que ahora todas las
excepciones serán atrapadas debido a que has colocado la anotación [HandleError] a la
clase.
3. Presiona Ctrl-F5 para ejecutar la aplicación sin depuración.
4. Intenta mostrar los datos de la categoría 0.
¿Por qué no se muestra la página de error personalizada y en lugar de ella se muestra la

página de error predeterminada?
La respuesta es que para activar la funcionalidad del atributo HandleError debemos habilitar
el manejo de errores personalizado en el archivo de configuración Web.config.

6. Abre el archivo Web.config ubicado en la raíz del proyecto Northwind.
7. Agrega el elemento <customErrors> dentro del elemento <system.web>. El código se

muestra a continuación.

9. Intenta mostrar los datos de la categoría 0. Se debe mostrar la página personalizada de error.
Cuando utilizamos la anotación [HandleError] sin propiedades, todas las excepciones son
capturadas y enviadas a una vista MVC llamada Error.cshtml. Esta vista predeterminada de
error debe ser creada en el folder /Views/Shared tal y como tú lo has hecho.
10. Modifica el URL y proporciona un ID mal formado, por ejemplo, un texto en lugar de un
número como lo espera el método de acción.
La excepción es atrapada y mostrada en la página de error personalizada.
11. Detén la aplicación y regresa a Visual Studio
12. Modifica la anotación [HandleError] de la clase CategoryController para desviar los errores
CategoryNotFoundException que no hayan sido manejados en un bloque try/catch hacia la
vista “CategoryNotFound”.
13. Modifica el código del método Display para que no maneje las excepciones
CategoryNotFoundException eliminando el bloque try/catch.
14. Agrega una nueva vista sin modelo llamada CategoryNotFound en la carpeta Views/Shared.
Esta vista será mostrada cuando se genere una excepción CategoryNotFoundException.
15. Modifica el cuerpo de la vista para mostrar un mensaje de error indicando que la categoría
buscada no fue encontrada.

17. Intenta mostrar los datos de la categoría 20 que no existe. Se mostrará la vista
CategoryNotFound.
18. Intenta mostrar los datos de la categoría 0. Se mostrará la página de error debido a que
únicamente estamos atrapando excepciones CategoryNotFoundException no manejadas.
20. Agrega a la clase CategoryController una segunda anotación [HandleError] para desviar los
otros tipos de excepciones hacia la vista Error.cshtml.

CategoryNotFound.
número como lo espera el método de acción. Se debe mostrar la página personalizada de
error.
25. Modifica el URL para solicitar un recurso que no exista, por ejemplo, el controlador NoExiste.
Se mostrará una página de error con el código HTTP 404 que indica que un recurso fue
solicitado y no pudo ser encontrado.
Algunos errores HTTP, tal como el error 404, no pueden ser atrapados por Vistas de error
MVC personalizadas especificadas en el archivo Web.config o en la anotación [HandleError].
Para tales errores, podemos utilizar el elemento <error> en el archivo Web.config como un
elemento hijo del elemento <customErrors>.
26. Modifica el elemento <customErrors> para especificar que el archivo Error404.html

responderá a los errores HTTP 404.
27. Agrega una nueva página HTML llamada Error404.html en la raíz del proyecto Northwind.
28. Escribe el siguiente código en el cuerpo de la página Error404.html.

30. Modifica el URL para solicitar un recurso que no exista, por ejemplo, el controlador NoExiste.
La página Error404.html será mostrada.
CategoryNotFound.
número como lo espera el método de acción. Se debe mostrar la página personalizada de
error.
34. Detén la ejecución y cierra Visual Studio.
Tarea 5: Atrapar excepciones adicionales
En este momento hemos configurado una estrategia para atrapar excepciones no manejadas que se
generen en el controlador Category. ¿Qué sucederá si una excepción no manejada se genera en un
controlador que no atrapa dichas excepciones?
1. Utiliza la plantilla MVC 5 Controller – Empty para agregar un Controlador llamado Product
en el proyecto Northwind.
2. Remplaza el código del método Index del Controlador Product para generar una excepción
del tipo NotImplementedException.

4. Modifica el URL para invocar al método Index del controlador Product. Debido a que la
excepción NotImplementedException del nuevo controlador no fue manejada, la página de
error predeterminada es mostrada.
5. Modifica el elemento <customErrors> para especificar que el archivo Error.html en la raíz de

la aplicación, responderá a todos los errores que no sean manejados en la aplicación.
6. Agrega en la raíz de la aplicación Web una nueva página HTML llamada Error.html.
7. Modifica el cuerpo de la página creada para mostrar un mensaje de error personalizado.

9. Modifica el URL para invocar al método Index del controlador Product. La página Error.html
es mostrada.

En este momento la aplicación está configurada para atrapar las excepciones que se generen
en el código de la aplicación además de los errores HTTP 404.
Resumen
Las excepciones surgen incluso en aplicaciones muy bien probadas debido a circunstancias
imprevistas. En este laboratorio, conociste algunas de las estrategias para el manejo de excepciones
en una aplicación Web ASP.NET MVC. Aprendiste también la forma de configurar el manejo de
excepciones utilizando el archivo Web.config.

02 Programador JR de Aplicaciones ASP - Net MVC

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

02 Programador JR de Aplicaciones ASP - Net MVC

Încărcat de

Drepturi de autor:

Formate disponibile

Microsoft .NET Programador Jr. de aplicaciones ASP.

Lección 1 Planeación en la fase de diseño del proyecto .................................................................. 50

LINQ to Entities ........................................................................................................................... 103

Generando código HTML accesible ............................................................................................. 143

Tarea 2: Configurar el proyecto de pruebas ........................................................................... 179

Acerca del curso

• Sistema Operativo Windows 8 o posteriores. Puede descargarse la versión de evaluación en

Contenido del curso

Módulo 1. Explorando ASP.NET MVC

Al finalizar este módulo, los participantes podrán:

Los temas que forman parte de este módulo son:

• Lección 1: Visión general de las tecnologías Web de Microsoft.

Módulo 2: Diseñando aplicaciones Web ASP.NET MVC

Al finalizar este módulo, los participantes podrán:

Los temas que forman parte de este módulo son:

• Lección 1: Planeación en la fase de diseño del proyecto.

Módulo 3. Desarrollando Modelos ASP.NET MVC

Al finalizar este módulo, los participantes podrán:

Los temas que forman parte de este módulo son:

• Lección 1: Creando modelos MVC.

Módulo 4. Desarrollando Controladores ASP.NET MVC

Al finalizar este módulo, los participantes podrán:

Los temas que forman parte de este módulo son:

• Lección 1: Creando Controladores y Acciones.

Módulo 5. Desarrollando Vistas ASP.NET MVC

Al finalizar este módulo, los participantes podrán:

Los temas que forman parte de este módulo son:

• Lección 1: Creando Vistas con sintaxis Razor.

Módulo 6. Probando, Depurando y Solucionando problemas en aplicaciones Web ASP.NET MVC

Se describe también la forma de mejorar la calidad de una aplicación localizando y corrigiendo

Al finalizar este módulo, los participantes podrán:

Los temas que forman parte de este módulo son:

• Lección 1: Realizando pruebas unitarias de los componentes MVC.

Acerca del módulo

• Describir el papel de ASP.NET en la pila de tecnologías web de Microsoft y cómo utilizar

Los temas que se cubren en este módulo son:

• Lección 1: Visión general de las tecnologías Web Microsoft

• Lección 3: Introducción a ASP.NET MVC

• Proporcionar una visión general de las tecnologías Web de Microsoft.

Introducción a las tecnologías Web de Microsoft

• Microsoft Visual Studio. Podemos utilizar Visual Studio, un ambiente de desarrollo

Es necesario probar la funcionalidad de las acciones de los usuarios en un servidor Web.

De las tecnologías de hospedaje del Stack Web de Microsoft tenemos:

Tecnologías de ejecución de código

Es necesario utilizar diferentes tecnologías para ejecutar código en el servidor y el código en el

Ejecución del lado del Servidor

Ejecución del lado del Cliente

Visión general de ASP.NET

• Web Pages. El modelo de programación ASP.NET Web Pages es un modelo de programación

o Controladores: Un controlador MVC es una clase que se encarga de la interacción del

¿Cuál de los tres modelos de programación proporciona el máximo control

MVC y Web Pages proporcionan un alto nivel de control sobre el código

• Configuración. Utilizando archivos web.config, podemos configurar la aplicación Web

Compilación del código ASP.NET

• La primera etapa es la compilación a código MSIL. Cuando se construye un sitio Web en

Cuando utilizamos el modelo de compilación predeterminado, los retardos pueden aparecer la

Para obtener más información sobre el proceso de compilación de ASP.NET, puedes

ASP.NET Compilation Overview

ASP.NET Web Site Precompilation

Tecnologías Web del lado del Cliente

Diferentes navegadores interpretan JavaScript de manera diferente. Cuando desarrollamos un sitio

AJAX es implementado completamente en JavaScript. ASP.NET, de forma predeterminada, se basa en