TUT: Aprender ASP .NET MVC Paso a Paso en 7 días(Día 5)

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

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

Cual es la agenda

En el dia 5, veremos la manera de empaquetar y minificar para maximizar el rendimiento de las aplicaciones MVC. También veremos el concepto y ventajas del modelo de vista que no es sino un puente entre el modelo y la vista.

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

Lab 18: Empaquetado y Minificación en MVC

Ambos conceptos empaquetado y minificación ayudan a incrementar el rendimiento

Entendiendo el Empaquetado

Siempre los proyectos Web necesitan archivos CSS y JavaScript. Normalmente se realiza una petición al servidor por cada archivo CSS y JavaScript, y si se tienen varios de estos archivos hace que la carga de las páginas sean lentas. Empaquetarlos nos ayuda a combinar múltiples archivos JavaScript y CSS en un solo objeto en tiempo de ejecución, combinando así múltiples solicitudes en una sola solicitud que a su vez ayuda a mejorar el rendimiento.

Por ejemplo considere la solicitud de una página en la siguiente imagen. Las solicitudes son capturados usando la Herramienta de desarrollo de Chrome. Esta página consume 2 archivos “Javascript1.js” y “Javascript2.js”. Cuando esta página es solicitada esta hace tres peticiones al servidor.

• Primera para la página “Index”
• Segunda solicitud para el archivo JavaScript “Javascript1.js”
• Tercera solicitud para el archivo JavaScript  “Javascript2.js”

Ahora si piensas  un poco en el escenario de arriba  puede llegar a ser peor si tenemos muchos archivos javascript(especialmente archivos JQuery) resultado múltiples solicitudes que reducirían el rendimiento.

Si somos capaces de combinar de alguna manera todos los archivos JS en un solo paquete y se soliciten como una única unidad, esto se traduciría en un mayor rendimiento(ver la siguiente imagen que tiene una sola petición).

Entendiendo la Minificación

La minificación reduce el tamaño de los archivos script y CSS, eliminando espacios en blanco, comentarios, etc. Para el  ejemplo de abajo tenemos un simple código javascript con comentarios.

Después de aplicar la minificación los codigo javascript se veran como en la imagen de abajo. puedes ver como son eliminado los espacios en blanco y comentarios para minimizar el tamaño del archivo e incrementar el rendimiento debido a que el tamaño del archivo ha sido reducido y comprimido.

Vamos a demostrar un simple ejemplo de empaquetado y minificación con MVC paso a paso.

Paso 1: Crear un proyecto con la plantilla en blanco

Para entender el empaquetado y minificación, vamos a seguir adelante y crearemos un proyecto MVC en blanco. En este vamos a agregar una carpeta “Script” y dentro  de este, vamos a agregar dos archivos javascript como se muestra en la siguiente figura.

El siguiente código es para el archivo “JavaScript1.js”

El siguiente código es para el archivo “JavaScript2.js”

Paso 2: Crear un controlador que llame a una vista

Ahora vamos a seguir y crear a un controlador el cual llame a una vista llamada “MiVista” es cual consume ambos archivos javascript.

Agregamos la vista MiVista y consumimos los archivos javascript.

Paso 3: Ejecutar y ver como se hacen multiples llamadas

Ahora ejecutamos la aplicación MVC en Google Chrome, Presione la combinación de teclas Ctrl+Shift+I para ver la siguiente salida. Puedes observar que hay tres solicitudes.

Paso 4: Referenciando a “System.Web.Optimization”

El empaquetado y minificación es hecho por el namespace “System.Web.Optimization”. Ahora este DLL no es parte del framework  .NET o ASP.NET. Necesitamos usar NUGET para descargar esta DLL. Vamos a NUGET y buscar ASPNET.Web.Optimization.

NUGET es  una herramienta cliente, que se agrega al Visual Studio y nos permite administrar y consumir paquetes. La galería de NUGET es un repositorio central usado por todos los autores de paquetes.

Paso 4: El archivo de configuración de paquete

Ahora este paso depende de que tipo de plantilla MVC hemos seleccionado a la hora de crear nuestro proyecto. Si hubiéramos seleccionado la plantilla “Basic” entonces el archivo “BundleConfig” ya se crearia y como nosotros hemos seleccionado la plantilla “Blanco” entonces tenemos mucho trabajo que realizar.

Entonces sigamos y agreguemos la clase “BundleConfig” y creemos un método “RegisterBundles” como se muestra en el siguiente código.En el código de abajo “bundles.add” dice que agregue todos los archivos javascript que están dentro de la carpeta “Scripts” a un paquete llamado “Bundles”.

Nota importante: No olvidar importar el namespaces “System.Web.Optimization” o de lo contrario se genera un error.

Paso 6:Llamar el archivo de configuracion del empaquetado desde el archivo global.asax.cs

En este paso no es necesario  si se ha creado el proyecto utilizando la plantilla MVC “Básico””. Pero como nosotros hemos creado el proyecto utilizando la plantilla MVC “Blanco”, entonces tenemos que abrir el archivo global.asax.cs y en el inicio de la aplicación llamar el método “RegisterBudles” como se muestra en el siguiente código.

Paso 7: Enlazar el empaquetado en la vista

una vez que el empaquetado es hecho necesitamos eliminar el tag “script” y llamar la dll “Optimization” para enlazar el empaquetado.

Debajo esta el codigo en la cual empaquetaremos ambos archivo javascript en un único objeto, evitando así llamada de solicitud múltiple por cada archivo javascript. En el empaquetado completo se agrega la vista MVC.

Paso 8: Mirar el empaquetado y minificación en tiempo real.

Para mostrar  el empaquetado y minificación en tiempo real. Ejecutamos nuestro proyecto en  Google Chrome y presiona la combinación de teclas CTRL+SHIFT+I(Herramienta del Desarrollador) y puedes ver la magia ahí en donde se muestra una sola llamada para ambos archivos javascript.

I hacemos click en la pestaña Preview podemos ver que ambos archivos JavaScript han sido unificados. si la minificacion también se ha realizado Recordemos nuestro archivo java script original.

Como puedes ver en la salida de abajo, los comentarios han sido eliminado, los espacios en blanco son removidos y el tamaño del archivo se reduce y es más eficiente.

Lab 19: Modelo Vista MVC

Teoría

Una vista modelo es una simple clase que representa datos a ser mostrados en la vista.

por ejemplo abajo esta un simple objeto CustomerModel con  propiedades “CustomerName” y “Amount”.

Pero cuando el modelo de objeto “Customer” es mostrado en la vista MVC este muestra algo como se puede observar en la siguiente figura. Este tiene “CustomerName”, “Amount” y un campo plus  “Customer Buyin Level”.

“Customer Buying Level”(Nivel de compra de clientes) es un indicador de color el mismo que indica que tan agresivo es la compra de los clientes.

El color de “Customer buying Level”  depende del valor de la propiedad “Amount”. Si la cantidad es mayor que 2000 entonces el color es rojo, si la cantidad es mayor que 1500 entonces el color es anaranjado y el caso contrario es color es amarillo.

En otras palabras “Customer Buying Level” es una propiedad extra el cual es calculado en base de la la cantidad(cantidad).

Por lo que la clase  viewmodel “Customer” tiene tres propiedades

• El textbox “TxtCustomerName”  toma datos de la propiedad “CustomerName”
• El textbox “TxtAmount” toma datos de la propiedad “Amount” del modelo como este es
• “CustomerBuyingLevelColor” muestra el valor del color dependiendo del valor “Amount”.

¿Que tipo de lógica contendrá la clase view model?

La clase view model puede tener los siguientes tipos de lógica:

• Lógica de transformación de color: Por ejemplo tu tienes una propiedad “Grado” en el modelo y te gustaria mostrar en la UI el color rojo para el nivel de grado alto, color amarillo para el nivel de grado bajo y verde para el grado OK.
• Lógica de transformación de formato de datos: Si tu modelo tiene una propiedad “Estado” con el valor  “Casado” y “Soltero”. En la UI te gustaria  mostrarle como un checkbox  el cual es marcado si “casado” y desmarcado si es ”soltero”.
• Lógica de agregación: Tienes dos clase modelo diferentes “Cliente” y “Direccion” y tienes una vista el cual muestra ambos datos “Cliente y “Dirección” en una sola vez.
• Estructura Downsinzing: Tienes un modelo “Cliente” con propiedades “NombreCliente” y “CodigoCliente” y quieres mostrar solo ”NombreCliente”.  puedes crear un modelo contenedor alrededor y exponer las propiedades necesarias.

Vamos hacer un pequeño laboratorio para entender el concepto modelo de vista MVC usando la siguiente muestra el cual hemos discutido previamente.

Usare el enfoque de arriba hacia abajo para crear la pantalla de arriba:

• Paso 1: Crear el modelo “Customer”
• Paso 2: Crear el ViewModel
• Paso 3: Consumir la ViewModel en la vista.

Paso 1: Creando el modelo Customer

Asi vamos a seguir adelante y crear un modelo “Customer”, en nuestro proyecto “MVCQuintoDia”, con las propiedades de abajo.

Paso 2: Creando la vista modelo

Lo siguiente es crear una clase ViewModel el cual contendrá al modelo “Customer” y agregara  propiedades de UI. Asi que vamos a crear una carpeta “ViewModels” y en esta agregar una clase “CustomerViewModel”.

Abajo va el codigo para la clase “CustomerViewModel”. Ahora  algunos puntos importantes acerca de la clase view model:

• Puedes ver en la clase de abajo  como la clase “CustomerviewModel” contiene la clase “CustomerModel”.
• También un punto iimportante que hemos de crear propiedades el cual va con la convención de nombres de UI(txtName, txtAmount, lblCustomerLevelColor,etc).
• Ahora para lo mas importante mirar el codigo para a propiedad “CustomerlevelColor”, este muestra el color dependiendo de la cantidad(Amount) de ventas del cliente(Customer). Una “ViewModel” existe para este tipo de código puente,  el cual conecta el modelo y la vista.

Paso 3: Consumiendo el ViewModel en la vista

El siguiente paso es crear un controlador, el mismo que pasa algunos datos  como se muestra en el siguiente código.

El siguiente paso es crear vista fuertemente tipada, donde podamos consumir la clase ViewModel. En caso no estes enterado de vistas fuertemente tipadas en MVC por favor revisar Aprender ASP.NET MVC Dia 1, Laboratorio 04.

Como puedes ver la vista no esta decorada o se puede decir enlazada con la clase modelo. Lo más importante es mirar que la vista está limpia. Esto no tiene código para la toma de decisiones para la codificación de colores. Estos código se han incluido dentro de la clase ViewModel. Esto hace que View Model sea un componente esencial de MVC.

Paso 4: Probando la Aplicación

Una vez terminado  es momento de probar la aplicación para lo que presionamos Ctrl+F5.

ViewModel sería Composición o Herencia

Muchos arquitectos cometen errores creando una clase ViewModel como herencia. Si tu ves arriba la clase ViewModel es creado por composición y no por herencia.

¿Porque composición tiene más sentido? si visualizas nosotros nunca decimos “esta pantalla es hijo de los objetos de negocio”, eso sería una declaración extraña.

Nosotros decimos “esa pantalla usa esos modelos”. Asi que es muy claro que sea una relacion usando y no una relacion es un(padres e hijos).

Algunos escenarios donde la herencia fallara:

• Cuando tu no quieres algunas propiedades del modelo en tu vista.
• Cuando tu tienes una vista el cual usa múltiples modelos.

Asi que no sean atraidos por la idea de la cracion de un ViewModel mediante herencia de un modelo que puede terminar en un problema Liskov.

Esto se parece a un pato, patito como un pato, pero no es un pato. Parece que un modelo tiene propiedades como un modelo, pero no es exactamente un modelo.

Imagen de http://tomdalling.com

Ventajas de ViewModel

Reusabilidad. Ahora que el código ha sido objeto de una clase. Se puede crear el objeto de esta clase en cualquier otra tecnologia(WPF, Windows, etc) facilmente.

Testeo: No necesitamos testear manualmente para probar la apariencia de la  UI. Porque nuestro código  de UI ha sido movido a la librería de clase, podemos crear un objeto de esta clase y realizar testeo unitario. Debajo un simple código de testeo unitario, el cual demuestra el testeo unitario de la apariencia de UI y la lógica. Puedes ver como las pruebas de  color  es realizado automáticamente en lugar  de algunos testeos manuales.

Lab 20: Manejo de Excepciones

Introduccion

Cuando se trata de manejo de excepciones, el bloque try...catch es la opción favorita de los desarrolladores .NET. Por ejemplo en el siguiente código hemos envuelto el código dentro de try..catch y si hay excepciones  invocamos a una  vista “Error” en el bloque catch.

El gran problema con el código de arriba  es la reusabilidad del manejo del código excepciones. MVC proporciona a reutilizar el código de manejo de excepciones en tres niveles:

A través de acciones dentro del mismo controlador: Puedes usar el evento “OnException” donde escribes la lógica  el mismo que puede ser reutilizado a través de “Acciones” dentro del mismo controlador.

A través de  cualquier controlador: En MVC podemos usar  “FilterConfig” para crear un atributo el cual será aplicado a cualquier controlador y cualquier accion.

A nivel de proyecto: manejando UsingApplication_Error en Global.asax.  Así que cuando la excepción se genera desde cualquier parte del proyecto MVC, este será ruteado a un manejador de error central.

Vamos paso a paso a demostrar  las 3 maneras de arriba del manejo de errores en MVC.

Paso 1: Agregar un controlador y la acción que lanza el error

Así que lo primero es agregar un simple controlador y la acción que lance algunos tipos de excepciones. En el siguiente código puedes ver que hemos agregado un controlador  “TesteandoControlador” con una acción “TestearMetodo”, donde hemos lanzado una excepción de división por cero.

Por lo que si ejecutar  la acción anterior terminará con un error como se muestra en la siguiente figura.

Paso 2: Crear una vista Error

Ahora una vez que el error es capturado  por cualquiera de los tres métodos descritos anteriormente nos gustaría lanzar una página de error para mostrar el propósito. Por lo que vamos a crear una simple vista por nombre “Error” como se muestra en la siguiente imagen.

Ahora que tenemos una error y también una vista “Error”  es tiempo de hacer la demostración usando las tres maneras. Por lo que primero vamos a empezar con “OnException” es decir código reutilizable  en acciones pero dentro del mismo controlador.

Paso 3: Reutilizar a través de  acciones dentro del mismo controlador(OnException)

Para implementar la excepción vamos al controlador “TesteandoController”  y sobreescribimos  el método “OnException”  como se muestra en el siguiente código. Este método se ejecuta cuando ocurre  cualquier error en cualquier acción del controlador “TesteandoController”.

La nombre de vista es decir “Error” es asignado a la propiedad result del objeto “FilterContext” como se muestra en el siguiente código.

Ahora si  ejecutas la aplicación(CTRL+F5),  llamando a “TestearMetodo” del controlador “TesteandoController”, se verá la vista “Error” como la siguiente imagen(Ojo en entorno de desarrollo se lanzará el error en Visual Studio, pero en entorno de ejecución se lanzará la vista “Error”, pasar por alto en Visual Studio para ver el error).

El método “OnException”  ayuda a proporcionar manejador de excepciones para un controlador específico pero que si queremos reutilizar la lógica de excepción a cualquier otro controlador y cualquier acción esto no se podría. Es donde tenemos que utilizar “FilterConfig” una manera en la cual hablaremos en el siguiente paso.

Paso 4: Reutilizar a cualquier acción y cualquier controlador(FilterConfig)

Dentro de Web.Config simplemente habilitamos “CustomErrors” como sigue.

Dentro de la carpeta App_Start abrimos FilterConfig.cs y nos aseguramos que HandleErrorAttribute es agregado a GlobalFilterCollection.

HandleErrorAttribute  en el nivel global confirma que la excepciones lanzadas por cada acción en todos los controladores serán manejados.

En el archivo Global.asax dentro de Application_Start el método RegisterGlobalFilters es invocado.

Esto hace que todas las excepciones lanzadas por cualquier método dentro de todos los controladores retornen la vista “Error” presente dentro la carpeta Shared.

Manejo de error a nivel de controlador, en donde todos los errores presentes en las acciones del controlador “TesteandoController” serán administrados.

Para hacer que nuestra vista “Error” una vista fuertemente tipada del Modelo System.Web.Mvc.HandleErrorInfo y entonces usar la palabra clave @Model para acceder a sus miembros. Uno de sus miembros es el objeto Exception.

El resultado sería el detalle de la vista Error.

Paso 5: Manejo de error a través de proyecto(Application_Error).

Para administrar errores a través de proyecto MVC, podemos usar numerar a el evento “Application_Error” dentro del archivo Global.asax y escribir la lógica de manejo de error dentro el mismo.

Application_Error es un evento a nivel de aplicación, podemos definir dentro del archivo Global.asax. El mismo será ejecutado cada vez que hay una excepción no controlada en la aplicación.

Si este  es el punto, ¿Porque no usar Application_Error siempre?

Aqui estan la ventajas de HandleError sobre Application_Error:

• Con HandleErrorAttribute obtenemos más control sobre el manejo de excepciones. HandleError nos permite administrar errores diferentes para diferentes controladores y acciones facilmente  donde en Application_Error para obtener esta característica se toma la ayuda del bucle interruptor.
• Una vez que este en Application_Error estas fuera de MVC y perderás ControllerContext y entonces no puedes hacer cosas fácilmente posibles con HandleError.

Lab 21: Área MVC

¿Que es un área y porque área?

En ASP.NET MVC tenemos un concepto de areas el cual nosotros podemos partir nuestro sistema en modulos y organizar  nuestro proyecto  de una mejor manera.

Asumo que tenemos un sistema el cual consiste de dos módulos Customer y Order Processing. Normalmente cuando creamos un proyecto ASP.NEt MVC nuestra estructura consite de 3 carpetas(Controller, Model y Views).  Entonces la estructura sería como esto.

Como puedes ver no esta organizado. Cuando se trata de administrar código será muy difícil.

La imagen presenta una estructura de proyecto con e módulos. Imagina una situación donde tengamos cientos de módulos en nuestro sistema.

Ejemplo de áreas en el mundo real

Los paises estan divididos por estados  para que el desarrollo y la administración sea fácil.

Justo como el mundo real usaremos el concepto de area en ASP.NET MVC para dividir nuestro sistema en modulos. Un área representa un modulo pero significa agrupación lógica de controladores, modelos y vistas.

¿Como Usar Áreas?

Paso 1: Agregar Áreas usando una Plantilla MVC

Para agregar área hacer click derecho en el proyecto y seleccionar Add>>Área como se muestra en la imagen siguiente:

Paso 2: Comience ubicando archivos pertinentes a áreas pertinentes.

Ubicar todos los archivos relacionado a áreas respectivas como se muestra en la siguiente figura. Dentro de la figura de abajo se puede ver que hemos creado dos áreas “Customer ” y “Order”, Y cada uno de estas áreas tiene sus propias Vistas, Controladores y Modelos.

Nota: El Área es una agrupación lógica no física, por lo que no  se crean dlls separadas por cada área.

¿Cual es la diferencia entre áreas y carpetas?

Uno se puede hacer la pregunta porque debemos usar para nuestro sistema areas para separar en modulos cuando podemos simplemente utilizar las carpetas. En pocas palabras, la respuesta para esta pregunta es “Para evitar el enorme trabajo manual”.

Para lograr la misma funcionalidad utilizando carpetas se tiene que hacer las siguiente cosas.

• Crear la estructura del módulo manualmente( Una carpeta por cada módulo, Tres carpetas adicionales por cada módulo llamado COntroller, Views y Model, un archivo Web.Config por cada módulo)
• Crear una ruta personalizada por cada módulo Controller.
• Crear un motor de vista personalizada para cada módulo  para  buscar  la vista en lugares personalizados en lugar de ubicaciones predefinidas(Views/{Controller} ó Views/Shared).

Buscar Vista por defecto

Buscar vista Personalizada

¿Que hay para el sexto día?