02 Programador Jr de Aplicaciones ASP.net MVC

Microsoft .NET

Programador Jr. de aplicaciones ASP.NET MVC Manual de estudiante

ASP.NET MVC

Programador Jr. de aplicaciones ASP.NET MVC Manual de estudiante Primera edición Febrero de 2018 Soporte técnico: [email protected] https://ticapacitacion.com/curso/mvcjr

Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela [email protected]

1

https://ticapacitacion.com/curso/mvcjr

Microsoft .NET

Programador Jr. de aplicaciones ASP.NET MVC

ASP.NET MVC

Manual de estudiante

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 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 Objetivos de la lección .................................................................................................................. 31 Aplicaciones Web Pages ................................................................................................................ 32 Aplicaciones Web Forms ............................................................................................................... 34 Aplicaciones MVC .......................................................................................................................... 36 Características compartidas .......................................................................................................... 39 Lección 3 Introducción Introducció n a ASP.NET MVC ................................. ............... ................................... ................................... .................................... ....................... ..... 42 Objetivos de la lección .................................................................................................................. 42 Modelos, Vistas y Controladores .................................................................................................. 43 Explorando Explor ando una aplicación aplicació n MVC Demostración Demostr ación ................................. ................ ................................... ................................... ....................... ...... 45 Características importantes de ASP.NET MVC .............................................................................. 46 Módulo 2: Diseñando aplicaciones Web ASP.NET MVC .................................................... ............ 48 Acerca del módulo ........................................................................................................................ 49 Objetivos ....................................................................................................................................... 49

2 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela ([email protected])


Microsoft .NET


ASP.NET MVC


Lección 1 Planeación Planeació n en la fase de diseño del proyecto .................................. ................ .................................... ................................ .............. 50 Objetivos de la lección .................................................................................................................. 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 Objetivos de la lección .................................................................................................................. 70 Diseñando Modelos ...................................................................................................................... 71 Diseñando Controladores.............................................................................................................. 75 Diseñando Vistas ........................................................................................................................... 77 Módulo 3: Desarrollando Modelos ASP.NET MVC ................................................................... ..... 79 Acerca del módulo ........................................................................................................................ 80 Objetivos ....................................................................................................................................... 80 Lección 1 Creando Modelos MVC ................................. ................ ................................... ................................... ................................... ................................ .............. 81 Objetivos de la lección .................................................................................................................. 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 Objetivos de la lección .................................................................................................................. 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 3 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela ([email protected])


Microsoft .NET


ASP.NET MVC


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 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..................... Acción.... ................................... ................................... ................................... .................................... ..................... ... 127 Objetivos de la lección ................................................................................................................ 127 ¿Qué son los Filtros? ................................................................................................................... 128 Creando y Utilizando Filtros de Acción ....................................................................................... 130 Módulo 5: Desarrollando Vistas ASP.NET MVC .......................................................................... 132 Acerca del módulo ...................................................................................................................... 133 Objetivos ..................................................................................................................................... 133 Lección 1 Creando Vistas con sintaxis sintaxi s 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 4 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela ([email protected])


Microsoft .NET


ASP.NET MVC


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 Objetivos de la lección ................................................................................................................ 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 Objetivos de la lección ................................................................................................................ 161 Creando Vistas Parciales ............................................................................................................. 162 Utilizando Vistas Parciales ........................................................................................................... 164 Módulo 6: Probando, Depurando y Solucionando problemas en aplicaciones Web ASP.NET MVC ................................................................................................................................................ 165 Acerca del módulo ...................................................................................................................... 166 Objetivos ..................................................................................................................................... 166 Lección 1 Realizando pruebas unitarias de los componentes MVC ............................................... 167 Objetivos de la lección ................................................................................................................ 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 5 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela ([email protected])


Microsoft .NET


ASP.NET MVC


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 Objetivos de la lección ................................................................................................................ 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



Microsoft .NET


ASP.NET MVC


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.



Microsoft .NET


ASP.NET MVC

•


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/visualstudio-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.



Microsoft .NET


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. Al finalizar este módulo, los participantes podrán: •

•

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.

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

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. Al finalizar este módulo, los participantes podrán: •

•

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 9 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela ([email protected])


Microsoft .NET


ASP.NET MVC


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. Al finalizar este módulo, los participantes podrán: •

•

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. Al finalizar este módulo, los participantes podrán: • •

•

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.

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

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. 10 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela ([email protected])


Microsoft .NET


ASP.NET MVC


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

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.



Microsoft .NET


ASP.NET MVC


Programador Jr. de aplicaciones ASP.NET MVC Mo dulo 1: Explorando ASP.NET MVC



Microsoft .NET


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 t ecnologí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



Microsoft .NET


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.



Microsoft .NET


ASP.NET MVC


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 .NET


ASP.NET MVC

•


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.



Microsoft .NET


ASP.NET MVC


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 m enudo 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.



Microsoft .NET


ASP.NET MVC

•


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.



Microsoft .NET


ASP.NET MVC


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:



Microsoft .NET


ASP.NET MVC

o

o

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. 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. 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 nombr e dentro del espacio de nombre System.Web y pueden ser utilizadas para implementar rápidamente funcionalidades Web comunes, tales como:



Microsoft .NET


ASP.NET MVC


•

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.



Microsoft .NET


ASP.NET MVC

•


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 t iempo 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, so n 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



Microsoft .NET


ASP.NET MVC


Tecnologías Web del lado del Cliente Originalmente, en ASP.NET y tecnologías similares como PHP, todo el códi go 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



Microsoft .NET


ASP.NET MVC


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
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



Microsoft .NET


ASP.NET MVC


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.



Microsoft .NET


ASP.NET MVC


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 t odas 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.



Microsoft .NET


ASP.NET MVC


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 par a 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). 27 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela ([email protected])


Microsoft .NET


ASP.NET MVC


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 .NET


ASP.NET MVC


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 lo s 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



Microsoft .NET


ASP.NET MVC


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/



Microsoft .NET


ASP.NET MVC


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.

Objetivos de la lección Al finalizar esta lección, seremos capaces de: • • • •

•

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.



Microsoft .NET


ASP.NET MVC

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.
Categorías de productos disponibles
@foreach(var c in Categorias) { @c
}



Microsoft .NET


ASP.NET MVC


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



Microsoft .NET


ASP.NET MVC


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 codebehind. Por ejemplo, una página con nombre Default.aspx por lo general tiene un archivo codebehind 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.



Microsoft .NET


ASP.NET MVC


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 tr avé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.



Microsoft .NET


ASP.NET MVC


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 36 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela ([email protected])


Microsoft .NET


ASP.NET MVC


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 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



Microsoft .NET


ASP.NET MVC

•

•


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



Microsoft .NET


ASP.NET MVC


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



Microsoft .NET


ASP.NET MVC


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 40 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela ([email protected])


Microsoft .NET


ASP.NET MVC


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.



Microsoft .NET


ASP.NET MVC


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.

Objetivos de la lección Al finalizar esta lección, seremos capaces de: • •

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



Microsoft .NET


ASP.NET MVC


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



Microsoft .NET


ASP.NET MVC


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.



Microsoft .NET


ASP.NET MVC


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/. 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.



Microsoft .NET


ASP.NET MVC

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.



Microsoft .NET


ASP.NET MVC

•


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.



Microsoft .NET


ASP.NET MVC


Programador Jr. de aplicaciones ASP.NET MVC Mo dulo 2: Disen ando aplicaciones Web ASP.NET MVC



Microsoft .NET


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.


•

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



Microsoft .NET


ASP.NET MVC


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 tr atando 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.

Objetivos de la lección Al finalizar esta lección, seremos capaces de: • •

•

•

• • • •

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.



Microsoft .NET


ASP.NET MVC


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 otr os 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. 51 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela ([email protected])


Microsoft .NET


ASP.NET MVC


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 52 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela ([email protected])


Microsoft .NET


ASP.NET MVC


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/



Microsoft .NET


ASP.NET MVC


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.



Microsoft .NET


ASP.NET MVC


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. Requerimientos de Negocio. Estos requerimientos describen la forma en que la o 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 55 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela ([email protected])


Microsoft .NET


ASP.NET MVC


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 g eneralizado. 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:



Microsoft .NET


ASP.NET MVC

•

•

•


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.



Microsoft .NET


ASP.NET MVC


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:



Microsoft .NET


ASP.NET MVC

•

•

•

•


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 59 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela ([email protected])


Microsoft .NET


ASP.NET MVC


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.



Microsoft .NET


ASP.NET MVC


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 V istas 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 t iene 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.



Microsoft .NET


ASP.NET MVC

•


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: Servicios Web. Si se implementan los objetos de negocio y las clases de acceso a o 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. Servicios Windows Communication Foundation (WCF). Si se implementan los o 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 ▪

▪



Microsoft .NET


ASP.NET MVC


mediante el uso de las credenciales requeridas que a menudo se incluyen en la cadena de conexión.



Microsoft .NET


ASP.NET MVC


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: 64 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela ([email protected])


Microsoft .NET


ASP.NET MVC

•


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 65 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela ([email protected])


Microsoft .NET


ASP.NET MVC

•


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: Propiedades del Perfil. Si el sitio utiliza un proveedor de perfiles ASP.NET, se pueden o 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.



Microsoft .NET


ASP.NET MVC


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.



Microsoft .NET


ASP.NET MVC


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.



Microsoft .NET


ASP.NET MVC


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.



Microsoft .NET


ASP.NET MVC


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.

Objetivos de la lección Al finalizar esta lección, seremos capaces de: • Describir como diseñar Modelos. • Describir como diseñar Controladores. • Describir como diseñar Vistas.



Microsoft .NET


ASP.NET MVC


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. 71 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela ([email protected])


Microsoft .NET


ASP.NET MVC


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-amuchos. 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.



Microsoft .NET


ASP.NET MVC


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



Microsoft .NET


ASP.NET MVC


realizar estas actualizaciones en cualquier modo o enfoque en que se esté utilizando ya sea Database-First, Model-First o Code-First.



Microsoft .NET


ASP.NET MVC

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 r eciben 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) AgregarFoto (GET). La acción AgregarFoto para la solicitud GET, crea una nueva o 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. MostrarGaleria (GET). La acción MostrarGaleria para la solicitud GET, muestra todas o 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.



Microsoft .NET


ASP.NET MVC

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.

Diseño en Proyectos Ágiles y Programación extrema 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.



Microsoft .NET


ASP.NET MVC

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 m ostrar 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 q ue 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.



Microsoft .NET


ASP.NET MVC


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.

Diseño en Proyectos Ágiles y Programación extrema 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.



Microsoft .NET


ASP.NET MVC


Programador Jr. de aplicaciones ASP.NET MVC Mo dulo 3: Desarrollando Modelos ASP.NET MVC



Microsoft .NET


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.


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.



Microsoft .NET


ASP.NET MVC


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 MV C 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.

Objetivos de la lección 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 .



Microsoft .NET


ASP.NET 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.



Microsoft .NET


ASP.NET MVC


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 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 ID { get; set; } public int IDCategoria { get; set; } public string Nombre { get; set; } public decimal Precio { get; set; } public decimal Existencia { get; set; } public DateTime UltimoMovimiento { get; set; } public virtual Categoria Categoria { get; set; } }



Microsoft .NET


ASP.NET MVC


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. public ActionResult Index() { 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.
@Model.Nombre



Microsoft .NET


ASP.NET MVC


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")] public DateTime UltimoMovimiento { get; set; }

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. [DisplayName("Fecha de último movimiento")] [DisplayFormat(DataFormatString = "{0:dd/MM/yy}", ApplyFormatInEditMode = true)] public DateTime UltimoMovimiento { get; set; }

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. [DisplayName("Fecha de último movimiento")] [DisplayFormat(DataFormatString = "{0:dd/MM/yy}", ApplyFormatInEditMode = true)] [DataType( System.ComponentModel.DataAnnotations.DataType.DateTime)] public DateTime UltimoMovimiento { get; set; }



Microsoft .NET


ASP.NET MVC


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 { public int ID { get; set; } // Una propiedad que sea requerida public string Nombre { get; set; } // 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: public class Persona { public int ID { get; set; } [Required] public string Nombre { get; set; } [StringLength(5, MinimumLength=5)] public string CodigoPostal { get; set; } [Range(0,100)] public byte DominioIngles { get; set; } [Required] [RegularExpression(@".+\@.+\..+")] public string Correo { get; set; } }

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.



Microsoft .NET


ASP.NET MVC


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. public class Persona { public int ID { get; set; } [Required(ErrorMessage="Debe proporcionar un nombre")] public string Nombre { get; set; } [StringLength(5, MinimumLength=5, ErrorMessage="El código postal debe ser de 5 caracteres")] public string CodigoPostal { get; set; } [Range(0,100, ErrorMessage="El porcentaje debe ser de 0 a 100%")] public byte DominioIngles { get; set; } [Required(ErrorMessage="El correo es requerido")] [RegularExpression(@".+\@.+\..+", ErrorMessage="La dirección de correo debe ser válida")] public string Correo { get; set; } }



Microsoft .NET


ASP.NET MVC


¿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 88 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela ([email protected])


Microsoft .NET


ASP.NET MVC


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 89 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela ([email protected])


Microsoft .NET


ASP.NET MVC


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.



Microsoft .NET


ASP.NET MVC


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.



Microsoft .NET


ASP.NET 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.



Microsoft .NET


ASP.NET MVC


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")] public string Nombre { get; set; }



Microsoft .NET


ASP.NET MVC


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.

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. P ara 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) { 94 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela ([email protected])


Microsoft .NET


ASP.NET MVC


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()); } }



Microsoft .NET


ASP.NET MVC


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.

Objetivos de la lección 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 .



Microsoft .NET


ASP.NET MVC


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.



Microsoft .NET


ASP.NET MVC

•

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.



Microsoft .NET


ASP.NET MVC


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.

La siguiente cadena de conexión especifica una conexión a Microsoft Azure SQL Database.

Una cadena de conexión para una base de datos SQL Server 2012 Express LocalDB quedaría de la siguiente forma:

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 debe aparecer dentro de la etiqueta , después de la etiqueta . 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.



Microsoft .NET


ASP.NET MVC


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.



Microsoft .NET


ASP.NET MVC

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 Categories { get; set; } public DbSet 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. public ActionResult Index() { 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. 101 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela ([email protected])


Microsoft .NET


ASP.NET MVC


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 { // 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 { 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.

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(new NorthWindInitializer());



Microsoft .NET


ASP.NET MVC


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.



Microsoft .NET


ASP.NET MVC


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 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



Microsoft .NET


ASP.NET MVC


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.



Microsoft .NET


ASP.NET MVC


¿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 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 GetProducts(int categoryID) { ICollection Products; using(var Context = new NorthWindDB()) { Products = Context.Products.Where(p=>p.CategoryID== categoryID).ToList(); } return Products; } }



Microsoft .NET


ASP.NET MVC


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.



Microsoft .NET


ASP.NET MVC


Programador Jr. de aplicaciones ASP.NET MVC Mo dulo 4: Desarrollando Controladores ASP.NET MVC



Microsoft .NET


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.


•

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



Microsoft .NET


ASP.NET MVC


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.

Objetivos de la lección 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.



Microsoft .NET


ASP.NET MVC


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.



Microsoft .NET


ASP.NET MVC


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.



Microsoft .NET


ASP.NET MVC


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 ag regar 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) 113 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela ([email protected])


Microsoft .NET


ASP.NET MVC


{ 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; }




Microsoft .NET

ASP.NET MVC


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) { ActionResult Result; if(ModelState.IsValid) { var Context = new NorthwindEntities(); 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 115 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela ([email protected])


Microsoft .NET


ASP.NET MVC


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.



Microsoft .NET


ASP.NET MVC


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 . 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. 117 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela ([email protected])


Microsoft .NET


ASP.NET MVC

•


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/enus/library/system.web.mvc.actionresult(v=vs.118).aspx



Microsoft .NET


ASP.NET MVC


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.



Microsoft .NET


ASP.NET MVC


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) { ActionResult Result; var Context = new NorthwindEntities(); 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. 120 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela ([email protected])


Microsoft .NET


ASP.NET MVC


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.
@ViewBag.Message

La hora actual del servidor es: @ViewBag.ServerTime

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. 121 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela ([email protected])


Microsoft .NET


ASP.NET MVC


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.
@ViewData["Message"]

La hora actual del servidor es: @ViewData["ServerTime"]




Microsoft .NET

ASP.NET MVC


¿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. 123 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela ([email protected])


Microsoft .NET


ASP.NET MVC


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.



Microsoft .NET


ASP.NET MVC


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; }



Microsoft .NET


ASP.NET MVC


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()); }



Microsoft .NET


ASP.NET MVC


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.

Objetivos de la lección Al finalizar esta lección, los participantes contarán con las habilidades y conocimientos para: • • •

Describir los filtros de Acción. Crear filtros de Acción. Determinar cuándo utilizar filtros de Acción.




Microsoft .NET


ASP.NET MVC

¿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. P or 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 predeterminada

Authentication IAuthenticationFilter

Authorization

IAuthorizationFilter

AuthorizeAttribute


Descripción 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. 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


Microsoft .NET


ASP.NET MVC

Action

IActionFilter

Result

IResultFilter

Exception

IExceptionFilter

derechos de acceso de usuario para la Acción. 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. 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. 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.



Microsoft .NET


ASP.NET MVC


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); }



Microsoft .NET


ASP.NET MVC

// 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] public ActionResult Index() { return View(); }



Microsoft .NET


ASP.NET MVC


Programador Jr. de aplicaciones ASP.NET MVC Mo dulo 5: Desarrollando Vistas ASP.NET MVC



Microsoft .NET


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 Al finalizar este módulo, los participantes contarán con las habilidades y conocimientos para: • • •

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



Microsoft .NET


ASP.NET MVC


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.

Objetivos de la lección Al finalizar esta lección, los participantes contarán con las habilidades y conocimientos para: • • • • • •

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.



Microsoft .NET


ASP.NET MVC


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 V istas 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. 135 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela ([email protected])


Microsoft .NET


ASP.NET MVC

Propiedad Nombre de la Vista (View name)

Plantilla (Template)

Clase Modelo (Model class)

Clase del contexto de datos (Data context class) Crear como una vista parcial (Create as a partial view) Referencia a Bibliotecas de scripts (Reference scripts libraries) Usar una página de diseño (Use a layout or master page)

Descripción Este es el nombre de la vista. A la vez, este es el nombre del 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. Una plantilla es una Vista básica que Visual Studio puede utilizar 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. Si creamos una vista fuertemente tipada, es necesario especificar 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. Si estamos utilizando Entity Framework, podemos seleccionar la clase que representa el contexto de datos asociado a la clase Modelo. Una vista parcial es una sección de código Razor que se puede reutilizar en múltiples Vistas de la aplicación. Cuando se selecciona esta casilla de verificación, los enlaces a archivos de scripts comunes del lado del cliente son incluidos en la Vista. Estos enlaces incluyen la biblioteca JavaScript jQuery. Una página de diseño o maestra puede ser utilizada para imponer un diseño estándar personalizado a muchas páginas dentro de la aplicación Web.



Microsoft .NET


ASP.NET MVC


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.
Razor no interpretará este texto como código ya que no se encuentra el símbolo Arroba "at"

La hora actual del servidor es:
@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 en lugar del delimitador @:. Razor elimina las etiquetas y antes de devolver el contenido al navegador.



Microsoft .NET


ASP.NET MVC


En el siguiente ejemplo de código, Razor interpreta el delimitador @: @: para para mostrar el texto plano. @{ @: Este texto se encuentra en un bloque de código, pero el delimitador lo declara como contenido. string Mensaje string Mensaje = "Hola, Mundo!!!!"; Mundo!!!!" ; @:
> @Mensaje @:> }



Microsoft .NET


ASP.NET MVC


Características de la Sintaxis Razor Razor incluye muchas características útiles que podemos utilizar para controlar la fo rma 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 @* 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 Product.UnitPrice contiene contiene el valor 2.00, el siguiente código genera "Precio Incluyendo impuestos: 2.00 * 1.16". 1.16". >Precio Incluyendo impuestos: @Model.UnitPrice * 1.16 >

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 Product.UniPrice contiene contiene el valor 2.00, el siguiente código genera "Precio Incluyendo impuestos: 2.32". 2.32 ". >Precio Incluyendo impuestos: @(Model.UnitPrice * 1.16) >

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. 139 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela ([email protected])


Microsoft .NET


ASP.NET MVC


@{ // 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 Model.Discontinued devuelve true true.. @if if(Model.Discontinued) (Model.Discontinued) {
El producto se encuentra discontinuado discontinuado }

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 enumerable utilizando el bloque de código foreach foreach.. @foreach foreach( (var var item item in in Model) Model) {
>@item.ProductName > }



Microsoft .NET


ASP.NET MVC

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 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 Display para para la acción Display Display en en el controlador Product Product,, sabemos por el código del método de la acción, que la acción siempre pasará un objeto Product Product a 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 ay uda 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 IntelliSe IntelliSense nse y verificación de errores. Si seguimos esto como una buena práctica, cometeremos menos errores de codificación 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, View, cualquiera de las plantillas disponibles distintas a Empty (without model) y, model) y, después, elegimos la clase Modelo que deseamos enlazar a la Vista. Por ejemplo, podemos elegir la clase Modelo Product Product de de modo que Visual Studio pueda enlazar la Vista a la clase Product Product agregando agregando la siguiente línea de código en la parte superior del archivo de Vista. @model M05.Models.Product M05.Models.Product

Posteriormente en el archivo Vista, podemos acceder a las propiedades del objeto Modelo utilizando el Helper Model Model.. Por ejemplo, podríamos acceder al nombre del producto de la siguiente forma: @Model.ProductName.. @Model.ProductName

Enlazando a una lista Enumerable 141 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela ([email protected])


Microsoft .NET


ASP.NET MVC


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 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 foreach Razor. Razor. El siguiente ejemplo, muestra una Vista de múltiples m últiples elementos con la declaración del Modelo y el ciclo que enumera todos los objetos Product Product pasados pasados por la acción. @model IEnumerable IEnumerable > @foreach foreach ( (var var item item in in Model) Model) { > > @Html.DisplayFor(modelItem => item.ProductName) > > }

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 V istas sin clase Modelo es la página principal del sitio. En este caso, podemos crear una Vista que no incluya la declaración @model @model en 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 Product y y ExternProduct ExternProduct.. Algunas propiedades podrían ser similares, mientras que otr as podrían ser diferentes. Por ejemplo, la clase ExternProduct ExternProduct podría 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 dynamic en la parte superior de la página. Si lo deseamos, posteriormente podríamos modificar la declaración @model @model para 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 ExternProduct.Supplier del ejemplo anterior, debemos comprobar si la propiedad existe antes de utilizarla.



Microsoft .NET


ASP.NET MVC


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:



Microsoft .NET


ASP.NET MVC

o

o

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. 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. 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.



Microsoft .NET


ASP.NET MVC


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 V ista 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

o

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. 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. Concisión. Algunos motores de Vista trabajan con archivos de V ista 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

Razor

Este es el motor de Vistas predeterminado en MVC. Es fácil de aprender para cualquier persona que tenga experiencia en HTML y C# o Visual Basic. Visual Studio


Ejemplo de código @model IEnumerable
@foreach (var p in Model) { https://ticapacitacion.com/curso/mvcjr

Microsoft .NET


ASP.NET MVC

ASPX

NHaml (pronuciado como enamel)

Spark

proporciona buena retroalimentación IntelliSense para el código Razor y es compatible con las Pruebas Unitarias. Este era el motor de Vistas predeterminado para MVC 1 y 2. Es fácil de aprender para los desarrolladores con experiencia en ASP.NET Web Forms y también es conocido como el motor de Vistas Web Forms. Incluye buena retroalimentación IntelliSense. NHaml es una versión .NET del motor de Vistas Haml utilizado con Ruby on Rails, un competidor de ASP.NET MVC. Los desarrolladores que han desarrollado sitios 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. Este motor de Vistas utiliza archivos de Vista que son de fácil lectura y similar a los archivos estáticos HTML. Este diseño da como resultado archivos de Vista que pueden ser leídos por cualquier persona que conozca HTML. Podemos obtener soporte IntelliSense para Spark en Visual Studio.


Nombre: @p.Name } <%@Control Inherits = "System.Web.Mvc.ViewPage >" %>
<%Foreach (var p in model) {%>
<%= p.Name%> <%}%> @type = IEnumerable % ul - foreach (var p in model) % li = p.Name

$ {p.Name}

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 http://go.microsoft.com/fwlink/?LinkID=288957&clcid=0x409



Microsoft .NET


ASP.NET MVC

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 ar chivos 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 http://go.microsoft.com/fwlink/?LinkID=288958&clcid=0x409



Microsoft .NET


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.

Objetivos de la lección Al finalizar esta lección, los participantes contarán con las habilidades y conocimientos para: • •

•

•

• •

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.



Microsoft .NET


ASP.NET MVC


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 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 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. Display Product

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 149 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela ([email protected])


Microsoft .NET


ASP.NET MVC


El Helper Url.Action genera un URL utilizando el motor de enrutamiento sin generar el elemento . Por ejemplo, podemos utilizar el Helper Url.Action para proporcionar el valor del atributo src de un elemento 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.

Para obtener más información acerca de los Helpers Html.ActionLink y Url.Action, se recomienda visitar los siguientes enlaces: LinkExtensions.ActionLink Method http://go.microsoft.com/fwlink/?LinkID=288959&clcid=0x409 UrlHelper.Action Method http://go.microsoft.com/fwlink/?LinkID=288960&clcid=0x409




Microsoft .NET


ASP.NET MVC

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)



Microsoft .NET


ASP.NET MVC


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
en la página Web HTML. Todas las etiquetas y controles de entrada deben ser ubicados dentro del elemento . 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 debe estar cerrado con una etiqueta
. En las Vistas Razor, podemos asegurar que el elemento
este cerrado mediante el uso de un bloque de código @using. Razor genera el tag
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)) { }



Microsoft .NET


ASP.NET MVC


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
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 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" })) { /* Poner controles de entrada aquí */ }




Microsoft .NET


ASP.NET MVC

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 Caja de texto (TextBox)

Caja de texto de múltiples líneas (Multiline TextBox) Casilla de verificación (CheckBox)

Ejemplo

Discontinuado

Descripción Un cuadro de texto de una sola línea en la cual el 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. Una caja de texto de múltiples líneas en la cual el usuario puede proporcionar cadenas de caracteres largas. Una Casilla de verificación que envía un valor booleano

Para obtener más información sobre todos los elementos de formulario HTML, se recomienda visitar el siguiente enlace: The INPUT element http://go.microsoft.com/fwlink/?LinkID=288961&clcid=0x409

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 . El siguiente ejemplo genera un elemento para la propiedad ProductName. @Html.LabelFor(model=>model.ProductName) 154 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela ([email protected])



Microsoft .NET

ASP.NET MVC


El Helper Html.EditorFor El Helper Html.EditorFor genera elementos HTML 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 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 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 texto (TextBox) Caja de texto de múltiples líneas (Multiline TextBox) Casilla de verificación (CheckBox) public string ProductName{get;set;} <input class="text-box single-line" id="ProductName" name="ProductName" type="text" value="" /> [DataType(DataType.MultilineText)] Public string ProductName{get;set;} <textarea class="text-box multiline" id="ProductName" name="ProductName">

[Display(Name="Producto discontinuado" )] public bool Discontinued{get;set;}

Texto oculto Hidden

[HiddenInput (DisplayValue= false)] public int ProductID { get; set; }

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)



Microsoft .NET


ASP.NET MVC


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. 156 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela ([email protected])


Microsoft .NET


ASP.NET MVC


El siguiente ejemplo genera un mensaje de validación para la propiedad ProductName de la clase Modelo. @Html.ValidationMessageFor(model=>model.ProductName)



Microsoft .NET


ASP.NET MVC


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 para poner una palabra en cursiva.

Si utilizamos la sintaxis normal @Model.ComentarioHtml para devolver el texto formateado del comentario, Razor codifica "<" como "<" y ">" como ">" en el código fuente HTML. Esto resulta en que el usuario ve "" 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 t ienen é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.



Microsoft .NET


ASP.NET MVC


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(""); string[] PropertyNames = null; 159 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela ([email protected])


Microsoft .NET


ASP.NET MVC


// 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(""); foreach (var e in PropertyNames) { string DisplayName = ModelMetadataProviders.Current .GetMetadataForProperty(null, item.GetType(), e) .DisplayName; // Obtenemos la metadata del M odelo DisplayName = DisplayName ?? // Si no hay metadata DisplayName e; // mostrar el nombre del campo sb.AppendFormat("", DisplayName); } sb.Append(""); } // Agregar los valores del registro actual // Agregamos class="Alt" para renglones Alternos sb.AppendFormat("", Alt ? "class=\"Alt\"" : ""); foreach (var p in PropertyNames) { sb.AppendFormat("", item.GetType().GetProperty(p).GetValue(item)); } sb.Append(""); Alt = !Alt; // Para alternar renglones y poder colorear con CSS } sb.Append("

{0}
{0}
"); } return new MvcHtmlString(sb.ToString()); }

En una Vista podemos utilizar el Helper de la siguiente manera: @Html.DataGridFor(Model)



Microsoft .NET


ASP.NET MVC


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.



Microsoft .NET


ASP.NET 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 y . 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 162 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela ([email protected])


Microsoft .NET


ASP.NET MVC


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
@foreach(var item in Model) {
Asunto: @item.Subject
}



Microsoft .NET


ASP.NET MVC


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}) 164 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela ([email protected])


Microsoft .NET


ASP.NET MVC


Programador Jr. de aplicaciones ASP.NET MVC Mo dulo 6: Probando, Depurando y Solucionando problemas en aplicaciones Web ASP.NET MVC



Microsoft .NET


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 e n 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.


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.



Microsoft .NET


ASP.NET MVC


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.



Microsoft .NET


ASP.NET MVC

¿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.



Microsoft .NET


ASP.NET MVC


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 Pr uebas 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 erro r 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 169 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela ([email protected])


Microsoft .NET


ASP.NET MVC


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.



Microsoft .NET


ASP.NET MVC

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 171 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela ([email protected])


Microsoft .NET


ASP.NET MVC

•

•


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 o tros 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.



Microsoft .NET


ASP.NET MVC


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.



Microsoft .NET


ASP.NET MVC


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.



Microsoft .NET


ASP.NET MVC


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:



Microsoft .NET


ASP.NET MVC

• • •

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.



Microsoft .NET


ASP.NET MVC


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.



Microsoft .NET


ASP.NET MVC


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.



Microsoft .NET


ASP.NET MVC


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.



Microsoft .NET


ASP.NET MVC


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.



Microsoft .NET


ASP.NET MVC


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.



Microsoft .NET


ASP.NET MVC


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.



Microsoft .NET


ASP.NET MVC


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 TestMethod1 por Test_Index_Return_View Test_Index_Return_View.. Esta prueba comprobará que el método de acción Index devuelva Index devuelva una vista llamada Index. Index.



Microsoft .NET


ASP.NET MVC


5. Una sola prueba unitaria generalmente consiste de código que se ejecuta en tres fases. En la primera fase llamada Preparar ( Preparar (Arrange Arrange en 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 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 ( Actuar (Act Act en en inglés), 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.



Microsoft .NET


ASP.NET MVC


7. En la tercera fase llamada Asegurar ( Asegurar (Assert Assert en 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 Microsoft.VisualStudio.TestTools.UnitTesting.Assert tal tal como Assert.AreEqual() para 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 Index devuelva una vista llamada Index 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 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 Test_CategoryList_Model_Type que que comprobará que el método m étodo de acción _CategoryList acción _CategoryList proporcione proporcione una lista enumerable de objetos Category a Category a la vista parcial _CategoryList parcial _CategoryList..



Microsoft .NET


ASP.NET MVC


9. La fase Arrange de Arrange de la prueba creará una instancia del controlador Category, Category, por lo tanto, agrega el siguiente código a la prueba unitaria.

10. La fase Act de Act de la prueba invocará al método de acción _CategoryList acción _CategoryList del del controlador, por lo tanto, agrega el siguiente código a la prueba unitaria.

En este momento, el método de acción _CategoryList acción _CategoryList no 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 / Generate / Method Stub del Stub del menú contextual del código que hace la llamada al método _CategoryList método _CategoryList..

Esto creará la definición del método (method Stub) _CategoryList Stub) _CategoryList en en el controlador Category similar al siguiente.

12. La fase Assert de Assert de la prueba comprobará que el tipo de datos del Modelo de la vista parcial devuelta sea del tipo List, List, por lo tanto, agrega el siguiente código a la prueba unitaria.



Microsoft .NET


ASP.NET MVC


La prueba unitaria completa quedará de la siguiente forma.

13. Otra funcionalidad requerida es la de mostrar la imagen de una categoría especificada, 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 Test_GetImage_Return_Type que que comprobará que el método de acción GetImage devuelva GetImage devuelva un archivo y no una vista.

14. La fase Arrange de Arrange de la prueba creará una instancia del controlador Category, Category, por lo tanto, agrega el siguiente código a la prueba unitaria.

15. La fase Act de Act de la prueba invocará al método de acción GetImage del 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.



Microsoft .NET


ASP.NET MVC


En este momento, el método de acción GetImage no 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 / Generate / Method Stub del Stub del menú contextual del código que hace la llamada al método GetImage. GetImage.

Esto creará la definición del método GetImage en GetImage en el controlador Category similar Category similar al siguiente.

17. La fase Assert de Assert de la prueba comprobará que el tipo del resultado devuelto por el método de acción sea el tipo FileContentResult, FileContentResult, por lo tanto, agrega el siguiente código a la prueba unitaria.

La prueba unitaria completa quedará de la siguiente forma.



Microsoft .NET


ASP.NET MVC


18. Agrega la prueba unitaria Test_Display_Model_Type para verificar que el método Display proporcione un tipo Category a Category a la vista que devuelve. Sigue los mismos pasos que realizaste para implementar la prueba unitaria Test_CategoryList_Model_Type 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 / TEST / Run / Run / All Test para Test para ejecutar las pruebas.



Microsoft .NET


ASP.NET MVC


La ventana Test Explorer se 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 Explorer da clic en la prueba Test_CategoryList_Model_Type Test_CategoryList_Model_Type para para ver la descripción del resultado de la prueba. Puedes notar que el problema fue que se lanzó una excepción System.NotImplementedException System.NotImplementedException..



Microsoft .NET


ASP.NET MVC


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 y se recibió <>.



Microsoft .NET


ASP.NET MVC

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.



Microsoft .NET


ASP.NET MVC


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.



Microsoft .NET


ASP.NET MVC


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. 194 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela ([email protected])


Microsoft .NET


ASP.NET MVC


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. 195 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela ([email protected])


Microsoft .NET


ASP.NET MVC


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.



Microsoft .NET


ASP.NET MVC


3. Renombra el archivo y clase creada como CategoryModelTests.

4.

Cambia el nombre de la prueba unitaria TestMethod1 por Test_Category_Products.



Microsoft .NET


ASP.NET MVC


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.



Microsoft .NET


ASP.NET MVC


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.



Microsoft .NET


ASP.NET MVC


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.



Microsoft .NET


ASP.NET MVC


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.



Microsoft .NET


ASP.NET MVC


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).



Microsoft .NET


ASP.NET MVC


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



Microsoft .NET


ASP.NET MVC


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.



Microsoft .NET


ASP.NET MVC


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.

5. Compila la solución.



Microsoft .NET


ASP.NET MVC


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. 206 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela ([email protected])


Microsoft .NET


ASP.NET MVC


| 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.



Microsoft .NET


ASP.NET MVC


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.



Microsoft .NET


ASP.NET MVC

16. Compila la solución.

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.




Microsoft .NET


ASP.NET MVC

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




Microsoft .NET

ASP.NET MVC


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



Microsoft .NET


ASP.NET MVC


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:



Microsoft .NET


ASP.NET MVC


8. En la vista Display, modifica el elemento 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. 213 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela (genius192002@hotmail.com) https://ticapacitacion.com/curso/mvcjr Microsoft .NET Programador Jr. de aplicaciones ASP.NET MVC ASP.NET MVC Manual de estudiante 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. 214 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela (genius192002@hotmail.com) https://ticapacitacion.com/curso/mvcjr Microsoft .NET Programador Jr. de aplicaciones ASP.NET MVC ASP.NET MVC Manual de estudiante 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. 215 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela (genius192002@hotmail.com) https://ticapacitacion.com/curso/mvcjr Microsoft .NET Programador Jr. de aplicaciones ASP.NET MVC ASP.NET MVC Manual de estudiante 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. 216 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela (genius192002@hotmail.com) https://ticapacitacion.com/curso/mvcjr Microsoft .NET Programador Jr. de aplicaciones ASP.NET MVC ASP.NET MVC Manual de estudiante 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. 217 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela (genius192002@hotmail.com) https://ticapacitacion.com/curso/mvcjr Microsoft .NET Programador Jr. de aplicaciones ASP.NET MVC ASP.NET MVC Manual de estudiante 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. 218 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela (genius192002@hotmail.com) https://ticapacitacion.com/curso/mvcjr Microsoft .NET Programador Jr. de aplicaciones ASP.NET MVC ASP.NET MVC Manual de estudiante 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. 219 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela (genius192002@hotmail.com) https://ticapacitacion.com/curso/mvcjr Microsoft .NET Programador Jr. de aplicaciones ASP.NET MVC ASP.NET MVC Manual de estudiante 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. 220 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela (genius192002@hotmail.com) https://ticapacitacion.com/curso/mvcjr Microsoft .NET Programador Jr. de aplicaciones ASP.NET MVC ASP.NET MVC Manual de estudiante 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. 221 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela (genius192002@hotmail.com) https://ticapacitacion.com/curso/mvcjr Microsoft .NET Programador Jr. de aplicaciones ASP.NET MVC ASP.NET MVC Manual de estudiante 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. 222 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela (genius192002@hotmail.com) https://ticapacitacion.com/curso/mvcjr Microsoft .NET Programador Jr. de aplicaciones ASP.NET MVC ASP.NET MVC Manual de estudiante 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. 223 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela (genius192002@hotmail.com) https://ticapacitacion.com/curso/mvcjr Microsoft .NET Programador Jr. de aplicaciones ASP.NET MVC ASP.NET MVC Manual de estudiante 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. 224 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela (genius192002@hotmail.com) https://ticapacitacion.com/curso/mvcjr Microsoft .NET Programador Jr. de aplicaciones ASP.NET MVC ASP.NET MVC Manual de estudiante 13. Agrega el siguiente código en la clase FakeNorthwindContext para implementar el método FindCategoryByID de la interface INorthwindContext. 14. Agrega el siguiente código en la clase FakeNorthwindContext para implementar el método FindProductByID de la interface INorthwindContext. 15. Agrega el siguiente código en la clase FakeNorthwindContext para implementar el método Add de la interface INorthwindContext. 16. Agrega el siguiente código en la clase FakeNorthwindContext para implementar el método Delete de la interface INorthwindContext. 225 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela (genius192002@hotmail.com) https://ticapacitacion.com/curso/mvcjr Microsoft .NET Programador Jr. de aplicaciones ASP.NET MVC ASP.NET MVC Manual de estudiante 17. Agrega el siguiente código en la clase FakeNorthwindContext para implementar el método 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. 226 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela (genius192002@hotmail.com) https://ticapacitacion.com/curso/mvcjr Microsoft .NET Programador Jr. de aplicaciones ASP.NET MVC ASP.NET MVC Manual de estudiante 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 227 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela (genius192002@hotmail.com) https://ticapacitacion.com/curso/mvcjr Microsoft .NET Programador Jr. de aplicaciones ASP.NET MVC ASP.NET MVC Manual de estudiante 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: 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 utilizando la siguiente información: i. CategoryID: Un valor único entero ii. Picture: Un nuevo arreglo de bytes de longitud 0. c. Pasar el objeto FakeNorthwindContext al constructor del Controlador CategoryController. 228 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela (genius192002@hotmail.com) https://ticapacitacion.com/curso/mvcjr Microsoft .NET Programador Jr. de aplicaciones ASP.NET MVC ASP.NET MVC 6. Manual de estudiante Modifica el código de la Prueba Unitaria Test_Display_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 utilizando la siguiente información: i. CategoryID: Un valor único entero c. Pasar el objeto FakeNorthwindContext al constructor del Controlador CategoryController. 229 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela (genius192002@hotmail.com) https://ticapacitacion.com/curso/mvcjr Microsoft .NET Programador Jr. de aplicaciones ASP.NET MVC ASP.NET MVC Manual de estudiante 7. Compila el proyecto Northwind.Tests y verifica que compile con éxito. Verifica también que las pruebas unitarias se ejecuten exitosamente. 230 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela (genius192002@hotmail.com) https://ticapacitacion.com/curso/mvcjr Programador Jr. de aplicaciones ASP.NET MVC Microsoft .NET ASP.NET MVC Manual de estudiante 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. 231 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela (genius192002@hotmail.com) https://ticapacitacion.com/curso/mvcjr Microsoft .NET Programador Jr. de aplicaciones ASP.NET MVC Manual de estudiante ASP.NET MVC 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. 232 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela (genius192002@hotmail.com) https://ticapacitacion.com/curso/mvcjr Microsoft .NET Programador Jr. de aplicaciones ASP.NET MVC ASP.NET MVC Manual de estudiante 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 mo strar 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: 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. 233 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela (genius192002@hotmail.com) https://ticapacitacion.com/curso/mvcjr Microsoft .NET Programador Jr. de aplicaciones ASP.NET MVC ASP.NET MVC Manual de estudiante 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. 234 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela (genius192002@hotmail.com) https://ticapacitacion.com/curso/mvcjr Microsoft .NET Programador Jr. de aplicaciones ASP.NET MVC ASP.NET MVC Manual de estudiante 7. Modifica el código de la Prueba Unitaria Test_CategoyList_Int_Parameter para que en la fase Preparar (Arrange) la prueba pueda: 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. 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. 235 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela (genius192002@hotmail.com) https://ticapacitacion.com/curso/mvcjr Microsoft .NET Programador Jr. de aplicaciones ASP.NET MVC ASP.NET MVC Manual de estudiante 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. 236 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela (genius192002@hotmail.com) https://ticapacitacion.com/curso/mvcjr Microsoft .NET Programador Jr. de aplicaciones ASP.NET MVC ASP.NET MVC Manual de estudiante 13. Ejecuta las pruebas unitarias y verifica que sean ejecutadas exitosamente. 237 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela (genius192002@hotmail.com) https://ticapacitacion.com/curso/mvcjr Microsoft .NET Programador Jr. de aplicaciones ASP.NET MVC ASP.NET MVC Manual de estudiante 14. Modifica el código de la vista Index del Index del controlador Category para 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 pr imeras categorías. 238 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela (genius192002@hotmail.com) https://ticapacitacion.com/curso/mvcjr Microsoft .NET Programador Jr. de aplicaciones ASP.NET MVC ASP.NET MVC 239 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela (genius192002@hotmail.com) Manual de estudiante https://ticapacitacion.com/curso/mvcjr Microsoft .NET Programador Jr. de aplicaciones ASP.NET MVC ASP.NET MVC Manual de estudiante 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 Pr ogramación Extrema, debemos definir cada prueba antes de escribir el código que implementa un requerimiento. Utilicemos la prueba como una especificación 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 Pr ueba 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. 240 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela (genius192002@hotmail.com) https://ticapacitacion.com/curso/mvcjr Microsoft .NET Programador Jr. de aplicaciones ASP.NET MVC ASP.NET MVC Manual de estudiante Lección 2 Implementando una estrategia para el manejo de 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. Objetivos de la lección Al finalizar esta lección, los participantes contarán con las habilidades y conocimientos para: • • • • • Explicar cómo disparar y atrapar excepciones. Explicar cómo configurar el manejo de excepciones utilizando el Web.config. Web.config. Explicar cómo dar seguimiento a excepciones utilizando la herramienta IntelliTrace. IntelliTrace. Describir como registrar excepciones. Describir las opciones de monitoreo de salud para las aplicaciones Web MVC. MVC. 241 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela (genius192002@hotmail.com) https://ticapacitacion.com/curso/mvcjr Microsoft .NET Programador Jr. de aplicaciones ASP.NET MVC ASP.NET MVC Manual de estudiante 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 242 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela (genius192002@hotmail.com) https://ticapacitacion.com/curso/mvcjr Microsoft .NET Programador Jr. de aplicaciones ASP.NET MVC Manual de estudiante ASP.NET MVC { 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 243 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela (genius192002@hotmail.com) https://ticapacitacion.com/curso/mvcjr Microsoft .NET Programador Jr. de aplicaciones ASP.NET MVC ASP.NET MVC Manual de estudiante 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 @if (Model != null) { 244 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela ([email protected])


Microsoft .NET


ASP.NET MVC


Controlador: @Model.ControllerName
Acción: @Model.ActionName
Mensaje: @Model.Exception.Message
}

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")] public ActionResult Index() { 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.



Microsoft .NET


ASP.NET MVC


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 al archivo Web.config. Este elemento debe ser un hijo del elemento . 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. RemoteOnly: En este modo, los errores no manejados son mostrados de forma o 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. 246 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela ([email protected])


Microsoft .NET


ASP.NET MVC

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 en el archivo Web.config como un elemento hijo del elemento . En el siguiente ejemplo de código, el elemento es utilizado para especificar el archivo HTML con la respuesta a errores HTTP 500.



Microsoft .NET


ASP.NET MVC

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. 248 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela ([email protected])


Microsoft .NET


ASP.NET MVC

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



Microsoft .NET


ASP.NET MVC


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 http://go.microsoft.com/fwlink/?LinkID=288962&clcid=0x409



Microsoft .NET


ASP.NET MVC

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? 251 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela ([email protected])


Microsoft .NET


ASP.NET MVC


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.



Microsoft .NET


ASP.NET MVC

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 Application Lifetime Events Audit Events Error Events

Request Processing Events

Heartbeats

Descripción Los eventos del ciclo de vida de la aplicación incluyen el inicio y fin de ejecución de la aplicación. Los eventos de auditoria incluyen Inicio y Fin de sesión así como los fallos de inicio de sesión. Los eventos de error incluyen excepciones del .NET Framework y errores HTTP tales como los errores 404 de recursos no encontrados. 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. 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 Salud EventLogWebEventProvider

Descripción Este proveedor envía los eventos hacia el Log de eventos de Aplicaciones de Windows. Estos eventos aparecen en el Windows Application Event Log.



Microsoft .NET


ASP.NET MVC


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 dentro del elemento en el archivo Web.config. Podemos utilizar elementos dentro de 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.

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 http://go.microsoft.com/fwlink/?LinkID=293685&clcid=0x409



Microsoft .NET


ASP.NET MVC


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\. 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



Microsoft .NET


ASP.NET MVC

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.



Microsoft .NET


ASP.NET MVC


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.



Microsoft .NET


ASP.NET MVC


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.



Microsoft .NET


ASP.NET MVC

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:///category/display/3



Microsoft .NET


ASP.NET MVC


15. Modifica el URL para mostrar la categoría de producto 30: http:///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 260 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela ([email protected])


Microsoft .NET


ASP.NET MVC


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.



Microsoft .NET


ASP.NET MVC


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:



Microsoft .NET


ASP.NET MVC


5. Agrega el siguiente código a la vista para definir su Modelo como una instancia del tipo System.Web.Mvc.HandleErrorInfo.



Microsoft .NET


ASP.NET MVC


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.



Microsoft .NET


ASP.NET MVC


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.



Microsoft .NET


ASP.NET MVC


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.



Microsoft .NET


ASP.NET MVC


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. 267 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela ([email protected])


Microsoft .NET


ASP.NET MVC


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.

9. Detén la aplicación y regresa a Visual Studio. 10. Presiona Ctrl+F5 para ejecutar la aplicación sin depuración.



Microsoft .NET


ASP.NET MVC


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.



Microsoft .NET


ASP.NET MVC


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. 270 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela ([email protected])


Microsoft .NET


ASP.NET MVC


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. 5. Detén la aplicación y regresa a Visual Studio. 6. Abre el archivo Web.config ubicado en la raíz del proyecto Northwind.



Microsoft .NET


ASP.NET MVC


7. Agrega el elemento dentro del elemento . El código se muestra a continuación.

8. Presiona Ctrl-F5 para ejecutar la aplicación sin depuració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



Microsoft .NET


ASP.NET MVC


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.



Microsoft .NET


ASP.NET MVC


15. Modifica el cuerpo de la vista para mostrar un mensaje de error indicando que la categoría buscada no fue encontrada.

16. Presiona Ctrl-F5 para ejecutar la aplicación sin depuración. 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. 19. Detén la ejecución y regresa a Visual Studio. 20. Agrega a la clase CategoryController una segunda anotación [HandleError] para desviar los otros tipos de excepciones hacia la vista Error.cshtml.



Microsoft .NET


ASP.NET MVC


21. Presiona Ctrl-F5 para ejecutar la aplicación sin depuración. 22. Intenta mostrar los datos de la categoría 20 que no existe. Se mostrará la vista CategoryNotFound.

23. Intenta mostrar los datos de la categoría 0. Se debe mostrar la página personalizada de error.

24. 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. Se debe mostrar la página personalizada de error.



Microsoft .NET


ASP.NET MVC


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 en el archivo Web.config como un elemento hijo del elemento . 26. Modifica el elemento para especificar que el archivo Error404.html responderá a los errores HTTP 404.



Microsoft .NET


ASP.NET MVC


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.

29. Presiona Ctrl-F5 para ejecutar la aplicación sin depuración. 30. Modifica el URL para solicitar un recurso que no exista, por ejemplo, el controlador NoExiste. La página Error404.html será mostrada.

31. Intenta mostrar los datos de la categoría 20 que no existe. Se mostrará la vista CategoryNotFound.

32. Intenta mostrar los datos de la categoría 0. Se debe mostrar la página personalizada de error. 277 Este manual fue creado por TI Capacitación para uso personal de: Carlos Valenzuela ([email protected])


Microsoft .NET


ASP.NET MVC


33. 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. 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.



Microsoft .NET


ASP.NET MVC


3. Presiona Ctrl-F5 para ejecutar la aplicación sin depuración. 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.



Microsoft .NET


ASP.NET MVC


5. Modifica el elemento 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.

8. Presiona Ctrl-F5 para ejecutar la aplicación sin depuración. 9. Modifica el URL para invocar al método Index del controlador Product. La página Error.html es mostrada.

10. Detén la ejecución y regresa a Visual Studio. 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.

02 Programador Jr de Aplicaciones ASP.net MVC

Recommend Documents

Categorías de productos disponibles

@ViewBag.Message

La hora actual del servidor es: @ViewBag.ServerTime

@ViewData["Message"]

La hora actual del servidor es: @ViewData["ServerTime"]