Arquitectura de software en ASP.NET WebForms y MVC

nHibernate y MVC.

2015-02-05T15:03:00.001-08:00

En este momento no recuerdo cuanto tiempo ha pasado desde que deje de usar los Stored Procedures con el ADO como mecanismo de persistencia, solo sé que al descubrir el EF mi mundo cambio. Con el EF podía usar los SP pero ya no era la única forma de acceder a los datos.

Desde que empecé a trabajar con MVC descubrí el nHibernate, pero me resistía a cambiar nuevamente. Recientemente al incursionar en la versión 5 del MVC decidí darle la oportunidad y ver que podía ofrecerme…

Que es nHibernate?

Es un ORM o mapeador relacional de objetos, (con sus siglas en ingles). Nos ofrece un mecanismo sencillo de mapear entidades de dominio (objetos) con tablas en una base de datos, donde cada registro representa una entidad. El objetivo principal de esta biblioteca es liberarnos de la carga de codificar una y otra vez líneas para lograr la persistencia de los datos que contienen los objetos de nuestra aplicación.

Desde luego además del mapeo, obtenemos mecanismos de consulta que en combinación con los mecanismos de persistencia, hacen que nHibernate sea una muy versátil y robusta solución para trabajar con datos, disminuyendo el margen de errores de codificación.

Arquitectura.

Lo primero que llamo mi atención fue su arquitectura, ya que promueve la separación de partes (SOC) favorece el uso de patrones como el de la unidad de trabajo y el de Factory. Además emplea las mejores prácticas para aspectos como la configuración, el mapeo, la carga de datos y el cache de los mismos.

Si lo comparamos con el EF podemos decir que el objeto principal contiene el modelo, la configuración y además es la unidad de trabajo; por lo tanto no resulta tan liviano a la hora de usarlo como su contra parte nHibernate.

La solución a nuestros problemas.

Una vez que empecé a usar este Framework, pude confirmar que es la solución para la terrible carga de escribir el código de persistencia de datos en cada proyecto, que además podría incluso llegar a representar un cuarto o un tercio del tiempo de programación de todo el proyecto, pero sobre todo este código requiere depuración y testeo cada vez que hacemos algún cambio; con nHibernate esta parte ha sido superada casi en su totalidad.

Lo más impresionante es la rapidez con la que podemos hacer modificaciones en la base de datos que con algunas líneas queda completamente adaptado, con un mínimo o nada de testeo.

Como trabaja?

Se trata de un motor de persistencia y consultas; o sea se encarga de crear, actualizar y eliminar registros, así como de hacer consultas y mantener en cache los más recientes datos leídos de la base de datos.

Esto significa que al escribir nuestro código, usaremos propiedades sin tener que preocuparnos de hacer las traducciones en ambos sentidos, nHibernate envía o recupera la información, logrando que resulte muy sencillo y seguro para nosotros.

El modelo.

nHibernate nos ofrece dos enfoques para trabajar con él:

Centrado en datos: empieza con el modelo desde la base de datos y crea los objetos.
Centrado en objetos: empieza con el modelo desde las clases y crea las tablas.

Como ya debemos saber, el modelo de datos, no siempre coincide con el modelo de clases y viceversa. Cada enfoque presentara ciertos detalles que requerirán de nuestra intervención para lograra que se acoplen uno sobre el otro.

Yo prefiero el modelo centrado en los datos, o sea empiezo por diseñar la base de datos y a partir de esta creo los objetos y la descripción del mapeo que se requerirá.

Integración con MVC.

nHibernate encuentra una arquitectura ideal cuando se trata de MVC; su presencia se limitara al ámbito del Model. La configuración se realiza una sola vez en el proceso de carga de la aplicación; la conexión se abrirá al momento de recibir una solicitud y se cierra cuando el controller responde y la solicitud termina.

En la arquitectura de mis aplicaciones empleo las siguientes clases dentro del Model:

Servicios: Estas clases se encargan de recibir las instrucciones del Controller y a su vez se comunican con los repositorios.
Repositorios: Estas clases son las que interactúan con nHibernate y se encargan de la persistencia y las consultas.

La unidad de trabajo (la transacción) se crea a nivel de los servicios, esto me permite propagar una transacción entre varios repositorios, con una sola instrucción final. La comunicación entre las clases de las diferentes capas es limpia y muy fácil de implementar. Tal vez la única parte que podría parecernos complicada sea la configuración inicial, ya que el mecanismo original se realiza con XML.

XML o Fluent?.

El mapeo más estable y robusto del nHibernate es el que se hace usando XML, pero resulta muy complicado y no es validado por el compilador; en cambio si usamos el mecanismo Fluent podemos realizar declaraciones fuertemente tipificadas que son muy fáciles de entender y que además el compilador puede verificar; sin embargo este mecanismo aun no cubre todos los aspectos de asociación y de mapeo que podemos realizar usando el XML.

Sin embargo la buena noticia es que se encuentra en vías de desarrollo, por lo que pronto resultara ser el complemento perfecto para esta tecnología.

La biblioteca Fluent-nHibernate nos ofrece una alternativa a la manera standard usando XML. Nuestro código resultara más fácil al momento de refactorizar, mas fácil de leer y mucho mas conciso que si usamos el XML.

Como la podemos obtener?

Para usar este método, será necesario instalar además del nHibernate la biblioteca fluent-nHibernate, esto resulta muy fácil a través de NuGet..

Después será necesario realizar dos pasos:

Debemos hacer es añadir la palabra virtual a las propiedades que definen nuestras entidades, con esto permitimos que estas propiedades puedan ser sobre escritas en una clase derivada.
Debemos crear una clase que reciba el mismo nombre que nuestra entidad, pero que termine con la palabra MAP, esta clase debe heredar de la clase ClassMap<T> donde T es el tipo de nuestra entidad.

En futuros artículos les explicare con ejemplos como codificarlo, en este momento lo importante es que comprendan los conceptos relacionados.

Comentario final.

He cambiado el EF por el nHibernate y siento que mi programación es más rápida, mi código es más estable, los cambios al nivel de la base de datos, no son problema y suelen hacerse con tres líneas de código por cada campo que añadamos.

Con nHibernate (y un generador de código que cree para esta arquitectura) solo debo enfocarme en el código de negocios que es el más importante, ya que la persistencia es muy tediosa.

Suerte.

Que es NuGet?

2015-02-04T10:35:00.001-08:00

Es una plataforma que surgió como un mecanismo para que los usuarios de Visual Studio pudieran actualizarse y obtener paquetes de código de rápida y fácil integración.

La primera versión surgió para el VS 2010, para la versión 2012 de VS se ofrecía como una extensión pre instalada, en la versión 2013 se incluyo como parte del producto con soporte. Hoy vamos a descubrir que nos puede ofrecer…

Entonces que es NuGet?

De tras de esta plataforma podemos encontrar toda una comunidad de programadores que comparten sus bibliotecas para enriquecer nuestra experiencia de desarrollo con .NET y Visual Studio. Nos ofrece una interface de administración y una ventana de consola de comandos.

Cuando creamos un proyecto por ejemplo en MVC podemos acceder a la herramienta y actualizar todos los scripts y bibliotecas que hayan sido actualizados después de que se libero el software; con lo cual tendremos una aplicación menos propensa a presentar errores. En escancia podemos obtener nuevas bibliotecas en línea y/o podemos actualizar las que ya tenemos instaladas para tener la versión más reciente. Interesante verdad?

Cuidado.

Pero no todo es bueno con respecto a la posibilidad de tener siempre la versión más actual. Por ejemplo: supongan que han desarrollado una biblioteca para uno de sus proyectos y que esta biblioteca tiene referencias a bibliotecas que descargaron de NuGet.

Esto quiere decir que tu código tiene referencia a una versión determinada de dicha biblioteca programada por un tercero y que cualquier proyecto donde desees emplear tu biblioteca, debe tener las misma versión de esa biblioteca o de lo contrario se presentaran problemas a la hora de compilar/ejecutar tu programa.

Además las nuevas versión pueden tener modificaciones que eliminen un método o mecanismo que la versión que referenciamos para uso de nuestra biblioteca emplea, lo que ocasionaría que nuestra biblioteca ya no funcionaria con esta nueva versión y tendríamos que volver a la etapa de codificación, para asegurarnos que todo funcione adecuadamente.

Código descontinuado.

Con esta plataforma sucede lo mismo que sucede con el Visual Studio. Conforme se actualizan las versiones del Framework, todos estos paquetes y bibliotecas se van actualizando para que puedan ser empleadas en las nuevas versiones del VS.

Esto inevitablemente mueve a todos hacia las nuevas versiones, lo que ocasiona que la plataforma en algún momento considere obsoleto nuestro código, si no nos hemos actualizado con cada nueva versión del VS. En este momento la versión 3 del Nuget, ya no soporta el código de la versión 2010 del VS.

A pesar que por el momento podemos usar la versión 2.8 de la plataforma, lo cierto es que algunas nuevas funcionalidades que ofrece la versión 3.0 no serán accesibles para quienes usen la versión anterior.

Configuración de NuGet en VS 2013.

Para la versión 2013 de VS, Microsoft ha incluido una sección dentro de las opciones de configuración en Herramientas/Opciones y de ahí a Administrador de paquetes.

Para acceder a la herramienta deben ir al menú Herramientas/ Administrador de paquetes NuGet y ahí se abrirá un sub menú con varias opciones.

Package Manager Console: Abre una ventana con una interface tipo consola, por medio de la cual podemos interactuar usando comandos.
Manage NuGet Package for Solution: Abre una ventana para instalar o desinstalar paquetes a nivel de la solución.
Package Visualizer: Abre una ventana donde podemos ver las relaciones de las bibliotecas de manera visual.
Package manager Setting: Abre la misma ventana que abre Herramientas/Opciones.

Como Administrar los paquetes en un proyecto.

Actualizar.

Inmediatamente después de crear el proyecto usando una plantilla de VS, deben hacer clic con el botón derecho sobre el nodo de Referencias y acceder a la opción Manage NuGet Packages…

Cuando se abra la ventana localicen el nodo Updates y se presentaran todas las actualizaciones que podan descargar.

Instalar.

Clic con el botón derecho sobre el nodo de Referencias y acceder a la opción Manage NuGet Packages…

Cuando se abra la ventana localicen el nodo OnLine y se presentaran todas las bibliotecas que podan descargar.

Desinstalar.

Clic con el botón derecho sobre el nodo de Referencias y acceder a la opción Manage NuGet Packages…

Cuando se abra la ventana localicen el nodo Installed Packages y se presentaran todas las bibliotecas que podan desinstalar.

Como tener éxito.

No se si sea posible de otra forma, aquí les voy a comentar sobre mi experiencia usando esta plataforma y como logro aprovechar sus beneficios sin resultar afectado con las actualizaciones.

Cuando crea un nuevo proyecto, actualizo las versiones que trae la plantilla de Visual Studio antes de empezar a codificar y no las vuelvo a actualizar para este proyecto, a menos que sea necesario.
Si creó una biblioteca para mis proyectos y decido incluir algún paquete descargado de NuGet, creó una carpeta donde conservo las versiones que he usado y me aseguro que los proyectos que usen mi biblioteca, referencien estas bibliotecas en vez de descargar la versión más reciente.

Comentario Final.

Espero que este artículo les sea de utilidad, es el primero de esta nueva etapa, ya que en futuros artículos usaremos bibliotecas descargadas de esta plataforma.

Suerte.

Por qué MVC?

2013-02-01T09:39:00.001-08:00

Tal vez aun sigan cuestionandose por que motivo vale la pena aprender MVC, asi que voy a tratar de darles algunos buenos motivos que les respondan a estas dudas.

Aun tal vez la razón mas importante sea que ante lo que ocurrió en el mundo exterior en todas las plataformas web que surgieron, las aplicaciones ASP.NET tradicionales lucen anticuadas y limitadas.

MVC surgió como respuesta a todas las críticas que recibió la plataforma ASP.NET y para poder ofrecernos a los antiguos clientes, forma de participar en las nuevas corrientes.

Diferenciar MVC tradicional del Framework de Microsoft.

El patrón MVC no es nuevo, fue creado en los laboratorios de Xerox en 1978, con un lenguaje denominado SmallTalk.

El patrón es muy simple: Se trata de un ciclo natural, el usuario solicita una acción y como respuesta la aplicación cambia su modelo de datos y actualiza una vista para el usuario. Desde luego si partimos de esta idea es muy fácil entender por qué se amolda perfectamente a un entorno web sobre HTTP.

Si lo vemos desde el punto de vista de una aplicación, esta necesitara la combinación de tecnologías como bases de datos, HTML, código ejecutable, recursos gráficos, etc.

El diseño del framework de MVC se llevo a cabo mediante la creación de componentes independientes, clases base abstractas, factorys.

Esto nos permite crear aplicaciones desde tres diferentes opciones:

La implementación Default.
Derivación de las clases mediante sub clases para tomar el control de algún comportamiento.
Reemplazar por completo un componente, mediante una interface o clase abstracta.

Control sobre HTML y HTTP.

ASP.NET MVC refuerza la creación de código limpio, que cumpla standards, por ese motivo los HTML Helpers nos ofrecen todo el control que se requiere.

Aquellos acostumbrados a los controles de ASP, extrañaran la presencia de objetos listos para ser usados, pero después de un breve lapso de adaptación podrán implementar y reutilizar bibliotecas como Jquery y si son mas aventurados podrán crear sus propias implementaciones usando JavaScript con una muy fácil integración con el modelo.

Al trabajar sobre HTTP MVC nos ofrece un completo control sobre las solicitudes, las respuestas y el paso de datos; AJAX se integra de forma natural a las aplicaciones MVC.

Ok, entonces quien debería usar ASP.NET MVC?

Desde luego mi opinión podría parecer comprometida, sin embargo tratare de ser objetivo:

Si lo comparamos con ASP.NET web Froms, podemos repetir todo lo que previamente se ha dicho y de qué forma MVC los supera, pero creo que la mejor forma es dándole crédito a las palabras de los voceros de Microsoft que afirman que ASP.NET Web Forms no está muerto y que aun cumple con su objetivo en entornos más controlados y menos demandantes, como podrían ser aplicaciones de intranet.

Mientras que MVC nos ofrece un entorno moderno para desarrollar aplicaciones en Internet, con la suficiente fortaleza para responder a los requerimientos actuales de las diferentes plataformas. Puesto que su baja demanda del ancho de banda, su eficiente respuesta, su compatibilidad con más navegadores y dispositivos lo hacen ideal para proyectos en ese entorno.

Comentario Final.

Después de tanto tiempo sin publicar creo que es importante retomar desde sus bases todo lo que hemos publicado, para hacer una especie de repaso, aun que en esta ocasión estoy profundizando un poco mas que al principio, para que valga la pena volver a leerlo si antes ya lo habían hecho.

Suerte.

Recapitulemos.

2013-01-31T07:26:00.001-08:00

Versiones van y versiones vienen, sin embargo el framework de MVC se ha superado en cada entrega, aun que actualmente se encuentra en la versión 4; (y ya estos jugando con ella) debo confesarles que aun estoy trabajando con la versión 3.

Recientemente le impartí un curso a unos cliente, que han sido acérrimos seguidores del ASP y que como es natural se habían resistido a voltear la mirada. Por fin lo han hecho, este articulo es el tema de introducción que les presente el primer día…

1.- Que es MVC de Microsoft?

Es un framework que combina la efectividad de la arquitectura MVC y las mejores técnicas del desarrollo ágil. Es la mejor alternativa para las aplicaciones web de ASP.

2.- Evolución de la plataforma web de Microsoft.

CGI: Un código simple pero que consumía grandes cantidades de recursos del sistema operativo.

IDG: Corría dentro del servidor web cuyo único beneficio consistía en simplificar las consultas SQL y las respuestas.

ASP: Surgen en 1996, fueron creadas para escribir código de propósito general, aun que su principal debilidad consistía en ser código interpretado al tiempo de ejecución, su peor cara consistía en la forma de escribir el código, ya que favorecía el código spaguetti.

ASP.NET Web Forms 1.0: Fue entre 2002 y 2003 que Microsoft presento una mejora a las paginas activas, mediante aplicaciones de código compilado, con interfaces con control de estado, con una infraestructura más amplia y que reforzaba la POO. Sin embargo en la operación diaria, resultaba en aplicaciones muy pesadas para anchos de banda pequeños, con código HTML poco elegante y que no podían ser testables.

Las mejoras se dieron a nivel del framework en 2005 con la versión 2.0 y en 2007 con la inclusión del AJAX, por último la versión 3.5 del framework en 2008.

Fue en 2009 que Microsoft publico la versión 1.0 de MVC, con una propuesta muy interesante pero que rompía todos los paradigmas de programación ASP conocidos hasta el momento; en 2010 se publico una segunda versión mucho mas solida para un avido grupo de entusuastas programadores que encontraron en MVC una forma fresca de escribir aplicaciones Web. En 2011 se publico la versión 3.0 del MVC con un completo conjunto de características, funcionalidades y técnicas para solucionar todas las carencias de las versiones anteriores.

En este momento ya se ha publicado la nueva versión 4.0 del MVC, sin embargo la versión 3.0 sigue siendo la más estable.

El paradigma ASP

La idea detrás de la plataforma ASP consistía en ocultarle a los programadores el código HTML, asi como evitarle tener que aprender a lidiar con un protocolo (HTTP) que no permitía conservar un estado entre envíos de datos, mediante un sofisticado entramado que simulaba el ambiente de escritorio en aplicaciones web.

Que está mal en ASP?

El peso del View State: Una cadena de bytes que se transfiere entre el cliente y el servidor, haciendo muy lenta la experiencia de los usuarios.

Extremadamente complicado ciclo de vida de una página: Para poder soportar la ilusión de estar conectado al servidor, el ciclo de creación y vida de una página web es muy complicado, lo que ocasiona misteriosos fallos en algunos eventos.

Modelo cohesivo: El archivo denominado code behind, crea una falsa sensación de separación de partes, con la única idea de poder tener en un archivo la parte HTML y en el otro el código que manipula los controles y la conexión de datos, lo que ocasiona un código monstruoso, frágil y en ocasiones ilegible.

Control limitado sobre el código HTML: Los controles de servidor se convierten a sí mismos en código HTML, aun que no es siempre el código que nosotros necesitamos, este código presenta problemas con los CSS, y todo tipo de estándares web. Incluso resulta muy complejo acceder a el código HTML generado usando Javascript.

Desarrollo web moderno.

Para aquellos que no son seguidores de Microsoft el desarrollo web creció rápida y progresivamente y tomo múltiples y muy divergentes direcciones.

El reto más recurrente es la necesidad de escribir aplicaciones que puedan ser capaces de corren en diferentes navegadores e incluso diferentes dispositivos; con múltiples estándares que se deben cumplir para HTML, CSS, JavaScript, etc.

La arquitectura más frecuente que se emplea para soportar la interacción sobre HTTP, se denomina REST (Representational State Transfer), la cual dejo en las sombras la propuesta de Microsoft denominada SOAP, que se emplea para los servicios web.

Para REST la aplicación se describe en términos de recursos disponibles, como por ejemplo podemos PUT un nuevo producto o DELETE un cliente.

Los requerimientos de plataformas cruzadas, navegadores y dispositivos, obligan a las aplicaciones a servir los datos en diversos formatos como Json y XML, que pueden ser aprovechados por las tecnologías existentes, como AJAX, Silverlight, iOS, Android, etc.

Estos nuevos escenarios no pueden ser atendidos de forma exitosa por las ASP.NET Web Forms.

Comentario Final.

Debo disculparme con todos los lectores de este Blog, puesto que los he tenido muy abandonados; el trabajo y mi pasatiempo (la fotografía) me han absorbido mucho desde el año pasado, sin embargo siempre veo que los seguidores aumentan en facebook y por ese motivo voy a hacer un esfuerzo por actualizarlo mas seguido.

Espero que les haya parecido interesante.

Suerte.

Análisis del Plan de capacitación para un equipo de desarrollo

2012-10-05T14:13:00.001-07:00

Introducción.

Cuando se habla de capacitación para un equipo de desarrollo, siempre surge la preocupación sobre si tendrá el impacto que queremos sobre las habilidades de nuestra gente. No es un secreto que los cursos de capacitación tienen el contenido necesario para poder sentar las bases y que a partir de ese nuevo conocimiento se pueda desarrollar un conjunto de habilidades necesarias para actualizarnos.

Sin embargo esto no es lo que necesitan la mayoría de las empresas, ya que el personal debe ausentarse de la oficina y atrasarse en sus proyectos, para poder participar en los cursos.

Los equipos de desarrollo necesitan actualizarse, esa es una realidad; pero necesitan una alternativa que les permita aprender al mismo tiempo que son productivos, desarrollando nuevas habilidades tecnológicas, que les permitan ser competitivos.

Por que aprender C#?.

Para poder atender las necesidades actuales del área de sistemas, se recomienda llevar a cabo un proceso de preparación en lenguaje C#. Al aprender a codificar en este lenguaje, podremos abrir la posibilidad de incursionar en nuevas tecnologías que les permitirán cubrir aspectos como:

1. Páginas Web con el patrón MVC.

2. SilverLight.

3. Desarrollo de aplicaciones para dispositivos como:

a. WP7

b. Android

c. iOS

Aun que es posible codificar las dos primeras tecnologías empleando VB, no sucede lo mismo para poder incursionar en los dispositivos móviles multi plataforma.

El debate que aun existe sobre si C# es mejor lenguaje que VB, fue uno de los motivos por los cuales tarde mucho tiempo en aprenderlo; sin embargo hoy en día, una vez que me he familiarizado con su sintaxis y forma de hacer las cosas, puedo decirles que me resulta más sencillo de codificar, además que he encontrado algunas características que no son tan sencillas de lograr usando el VB.

Pero el argumento más importante es que si aprenden C#, podrán desarrollar aplicaciones que puedan correr en diferentes plataformas, con muy pocos detalles particulares de cada una de estas.

Porque aprender MVC?

Desde su aparición entre las plataformas de Microsoft hace algunos años, ha existido la duda entre quienes programan con el paradigma ASP, si deberían migrar al paradigma MVC.

El modelo de WebForms de ASP.NET es una gran mentira. Nada de lo que se hace usando este modelo tiene algo que ver con el entorno Web.

Surgió en una idea equivocada, que pretendía que los programadores de computadora familiarizados con el estilo de programación de Microsoft en aplicaciones Windows, pudieran trasladar sus habilidades y conocimientos a la web, con muy poco esfuerzo de su parte.

El internet trabaja mediante un protocolo denominado HTTP, y trabaja enviando paginas en HTML, es algo que debemos saber y aceptar, para poder incursionar en el verdadero desarrollo de aplicaciones web.

MVC nos ofrece un completo control sobre la generación del HTML que será enviado a los clientes; nos permite extender las funcionalidades y establece los lineamientos para que hagamos nuestro trabajo dentro de estándares y patrones bien definidos y probados; MVC nos ofrece una arquitectura solida, que harán nuestro código más eficiente y fácil de mantener.

Por que aprender Silverlight?

Aun que no existe un orden de precedencia con respecto a aprender MVC y después Silverlight, creo que si partimos del grado de complejidad y de innovaciones a las que se debe enfrentar un programador que incursiona por primera vez en estas tecnologías, entonces el segundo paso –después de aprender C#- seria aprender MVC y una vez que se sientan seguros avanzar hacia el Expression Studio.

Si dentro de nuestras metas se encuentra llegar a desarrollar aplicaciones para dispositivos móviles, que puedan ser desarrollas con la visión de reutilización desde el principio, entonces no podemos pasar por alto aprender este paradigma de desarrollo.

Y después que sigue?

Una vez que hayan avanzado en estas tecnologías y se sientan a gusto con los nuevos conceptos que se deberán asimilar, estarán listos para dar el último paso: Desarrollo de aplicaciones Multi plataforma.

A pesar que hasta el final aprenderemos a programar para diferentes plataformas, la idea del curso consiste en avanzar desde la capacitación en C#, para llevar al equipo de desarrollo al siguiente nivel, que consiste en consolidar los conocimientos que adquirieron.

Repasaremos y consolidaremos conceptos, patrones y modelos de desarrollo como:

Entidades.
Extensiones.
ViewModels
Repositorios.
Servicios y APIs.
Esquemas de seguridad.
Reutilización de código.
Helpers.
Http web response.
Entre muchos otros.

Proyecto de capacitación.

Creo que si empezamos el plan de capacitación como parte del desarrollo de un proyecto real, que pueda irse construyendo poco a poco, sin la urgencia de tener una fecha límite, los participantes, podrán asimilar las tecnologías sin sentir la presión de un proyecto critico.

Independientemente del esquema que decidan aplicar para este proceso de capacitación, yo les recomiendo aprovechar el proceso para realizar el repaso de todas las etapas del desarrollo de un sistema, ya que de esta forma tendrían la oportunidad de opinar sobre aquello que sería mejor para el proyecto con una visión como la que hemos platicado en este articulo.

Cometario final.

El área de sistemas de una empresa siempre se encuentra en el dilema de atender a sus clientes o sacrificar los resultados para poder mantenerse actualizado. Un sistema de capacitación que les permita crear algo útil para la empresa mientras se capacitan es la solución más apropiada.

MVP en ASP.NET usando Entity Framework (3 de 3)

2011-11-14T09:23:00.001-08:00

Puede parecer muy ingrato de parte de nuestros usuarios, pero a ellos solo les interesa que nuestra aplicación sea fácil de manejar, rápida y que no tenga errores. Todo lo que hagamos en las capas que ellos no ven, no tiene importancia, mientras no falle…

Crear una interface que sea fácil de usar y que sea intuitiva (termino de moda) resulta en muchas horas de programación, para dejarla a punto…

Introducción

En esta ocasión no voy a hacer ningún ejemplo donde les ofrezca técnicas de programación para esta capa, usando JQuery, AJAX, HTML5 o alguna otra de moda, simplemente voy a simplificar esta relación con las capas inferiores, para que su trabajo sea más fácil y puedan aprovechar esas horas sobrantes a esta capa tan demandante.

Tutorial

Vamos a continuar en el proyecto web que creamos en la primera parte de este ejemplo. Recuerden que nuestro objetivo desde que empezamos esta serie de ejemplos, es que nuestras WebForms no tengan en control de la aplicación, trasladar ese control hacia las capas inferiores, más estables, de forma no cohesiva.

Hasta el momento tenemos nuestra API lista en el otro proyecto y ahora debemos conectar los cables para que las cosas fluyan.

Para este patrón empezaremos por crear una interface, que debemos colocar dentro de la carpeta interfaces que se encuentra dentro de la carpeta Presentación, como se muestra a continuación:

Esta interface tiene como objetivo establecer un estándar en todas las formas que creemos, de tal forma que el método Display siempre este ahí:

Creen una carpeta llamada Administración y dentro agreguen un formulario llamado frmHomeEmpresas:

En el fuente del diseñador agregaremos este código:

En el codebehind agregaremos nuestra interface para que nuestro formulario web la deba implementar:

Nuestro código necesita una clase que se encargue de la interacción con nuestra biblioteca de clases, la cual crearemos en una carpeta llamada Presentadores, dentro de Presentación:

El código debe ofrecer un método Display y un constructor que reciba la interface que creamos previamente:

Observen como se crea la instancia de nuestro Servicio, no es necesario crear una instancia de la clase ServiceLocator, solo se requiere tener una referencia a la biblioteca. Otro aspecto interesante a notar en este presentador, es la forma en que se formatean los datos que se enviaran a la UI.

De regreso a nuestro CodeBehind, este sería el código que debemos agregar:

Observen como se envía como parámetro a nuestro constructor la misma forma que lo está creando, esto es posible por la implementación de nuestra interface. Presten atención a la forma en que se controla la presentación en el Load. Y por último la implementación del método Display de la interface y la propiedad MensajeError. El método display recibe una lista de empresas, que el presentador le envía, nuevamente esto es posible porque en el constructor se envió el formulario, y el método Display es parte de esta.

Ahora ejecútenlo y podrán ver las empresas que hayan agregado a su tabla de la base de datos.

Comentario Final

Los patrones pueden ser un poco irracionales al principio, sobre todo si estamos implementando algo que nos cambia el paradigma; sin embargo una vez que logramos entender lo que se persigue, se convierte en un proceso repetitivo, el cual nos garantiza que si seguimos por ese medio, no será necesario reinventar nuestro código cada vez.

Y recuerden: El poder del código solo es completo, si tenemos el conocimiento de cómo usarlo.

MVP en ASP.NET usando Entity Framework (2 de 3)

2011-11-11T08:59:00.000-08:00

En un artículo que publique en Marzo de este año, hable del patrón Service Locator, en ese entonces les presente un ejemplo cuyo contexto podía parecer un poco forzado o abstracto, en esta ocasión usaremos el mismo patrón para nuestro ejemplo de MVP.

Y veremos de qué forma interactuar con el proyecto de presentación…

Casamiento por Separación de bienes.

Cada quien lo suyo. Cuando se crea una aplicación que debe interactuar con el usuario, para ser alimentada por este, es normal pensar que la estructura de las tablas, representa los datos que el usuario ve en las UI; esto nos lleva a usar mecanismos que hacen cohesiva nuestra UI con los datos que representan.

Aquellos datos que no debe ver el usuario los omitimos, como podrían ser los campos lave o las relaciones, pero todo lo demás si se convierte en algún control para que el usuario pueda interactuar con esta información.

La experiencia me dará la razón, cuando tenemos que modificar algo a nivel de datos, es un terremoto de 8 en la escala de Ritchter, que afecta todo nuestro desarrollo, debemos mover rápidamente lo que hemos programado, por de lo contrario la aplicación corre peligro.

Como podemos hacer para que la UI y las entidades no se hagan cohesivas?

Es un patrón que nos permite separar el modelo de la interface de usuario.
Desde mi muy particular punto de vista un ViewModel es una forma de organizar los datos que pertenecen a un modelo para que puedan ser presentados sin tener que exponer la entidad, incluso aun que dicha entidad no exista en la base de datos.

Analicemos porque existe?

Según el patrón las entidades pertenecen al MODEL y contienen propiedades que pueden estar relacionadas a campos en la base de datos o simplemente ser propiedades que no existen en la base de datos y que sirven para la lógica de la aplicación. Entonces cuando debemos enviar los datos al View, puede resultar pesado enviar una entidad del MODEL donde hay información de más.

Eso no es todo, para que resulte más complejo, cuando estamos creando un View resulta que se deben enviar algunos datos que ni son de la base de datos, ni son propiedades de ninguna entidad, por lo tanto no se emplean para uso de la lógica de negocios; son propiedades que deben existir para poder representar los datos apropiadamente en la View y no tienen sentido para nadie más.

Doble trabajo?

Podría parecernos doble trabajo, sobre todo si estamos acostumbrados a la forma que comentamos al principio, pero a la larga si usamos ViewModels en vez de las entidades, lograremos separar adecuadamente las responsabilidades de cada parte.

Continuación

Así que dicho lo anterior, vamos a empezar por crear nuestro primer ViewModel, para la empresa, por lo que deben crear una carpeta llamada ViewModels dentro de la carpeta model y agregar la siguiente clase dentro:

Si comparan la estructura de datos con la tabla que creamos en el articulo previo, podrán ver que no hemos incluido todos los campos, simplemente usaremos los que se necesitan para llevar la información a nivel de la capa del UI.

Como movemos los datos de las entidades hacia el ViewModel?

Si han comprendido lo que estamos haciendo, entonces la pregunta que use como sub titulo de este párrafo, es la más obvia para hacer en este momento.

Si han llegado hasta aquí, entonces sus entidades residen dentro de un archivo de código que acompaña al Model:

Este código que se genera por la herramienta, no debe ser modificado, por que la próxima vez que se compile la aplicación, podría volver a generarse y se perdería nuestro trabajo.

Para solucionar este problema contamos con los métodos de Extensión, los cuales nos permiten extender lo que ofrece una clase, sin tener que tener el código fuente; así que ahora deben crear una carpeta que llamaremos Extensions dentro del Model:

Según la lógica que hemos comentado vamos a necesitar de dos métodos de extensión, uno para convertir una entidad empresa a un ViewModel y otro que nos permita convertir una lista de Empresas en una lista de ViewModels.

Es muy importante para que funcione que se encuentren en el mismo espacio de nombres que las entidades, o sea Model.

Servicios

El software basado en servicios, no es algo nuevo, ha sido la forma en que se desarrollan aplicaciones por mucho tiempo, en este concepto donde los datos se centralizan, y las aplicaciones solicitan al software que atienda tareas específicas.

A gran escala hay muchos ejemplos, sin embargo en esta ocasión estamos hablando de un componente dentro de nuestra aplicación que se encargara de recibir las solicitudes para la creación controlada de los servicios, cada vez que se requiera una instancia se la solicitamos a este único servicio y este atenderá nuestras necesidades.

De esta forma la creación de las instancias se encuentra controlada, y agregar nuevos servicios solo afecta al código de un lado de la relación.

Continuemos

Agreguen una carpeta llamada Servicios al mismo nivel que la carpeta del Model y agreguen dentro dos capetas más denominadas, Interfaces y Services:

Dentro de Interfaces vamos a crear las siguientes Interfaces:

Ahora vamos a crear nuestro servicio para las empresas, el cual debe quedar dentro de la carpeta services:

Debe implementar nuestra interface, como lo indica el recuadro rojo.

Ahora veamos el código que se encontraba oculto:

Propiedades.

Inyección de dependencia:

Método que obtiene los datos:

Observen como se emplea el método de extensión después del método GetAll el cual nos regresa una lista de empresas.

Nuestro Service Locator

Para esta parte solo nos falta implementar nuestro Servicio centralizado usando el patrón de Serice Locator:

Presten especial atención a la implementación del patrón Singleton en la parte encerrada en el recuadro rojo. El método encerrado en amarillo, se encuentra en l código auxiliar, que veremos a continuación:

En este método se registran los servicios que puede entregar nuestra clase, que no es otra cosa, que agregar definición de instancias (ojo: no se crean en ese momento) para que sean creadas, cuando se solicite. Como lo demuestra el siguiente código:

Para poder llevar a cabo la tarea, de crear instancias a partir de las definiciones que hemos registrado, es necesario hacer uso de la técnica de Reflection, como se puede observar en el recuadro rojo.

En este código deben prestar especial atención a lo que se hace en el recuadro amarillo, se verifica si ha sido creada la instancia, para que le devolvamos una referencia a la misma, en vez de crear otra nueva.

Continuara….

Aclaración: Quiero comentarles que al empezar el artículo anterior, creí que con dos podría cubrir la explicación del ejemplo, pero mientras me encontraba escribiendo este, me di cuenta, que era así, por lo que cambie el titulo del anterior y extendí un articulo mas para este ejemplo, por lo cual serán 3.

En el próximo veremos cómo se lleva a cabo la presentación de la información en la UI.

Y recuerden: El poder del código solo es completo, si tenemos el conocimiento de cómo usarlo.

MVP en ASP.NET usando Entity Framework (1 de 3)

2011-11-10T10:24:00.001-08:00

Ya hemos visto la arquitectura de capas basada en el patrón MVP con dos ejemplos previamente, en el primero use LINQ to SQL para el acceso a datos, en el segundo use ADO.NET y en esta ocasión vamos a usar el Entity Framework...

Como siempre tratando de aplicar algún patrón dentro del ejemplo…

Introducción

En esta ocasión vamos a hacer un cambio sobre el modelo arquitectónico que hemos estado usando, todo con la finalidad de que avancemos en la idea de crear una API reutilizable de nuestro código.

La idea es tener una solución con dos proyectos, en el primero tendremos nuestra UI, que en este caso será Web y en el segundo la biblioteca donde tendremos nuestros servicios y el model.

O sea el UI será la parte presentadora de nuestro patrón y la biblioteca tendrá lo demás.

Creación de los proyectos

Creen dos proyectos dentro de una solución, uno debe ser ASP.NET Web y el otro una Biblioteca de clases, como se muestra a continuación, no creen las carpetas que ahí se ven, yo les diré cuando crearlas, por el momento solo agreguen la del Model en la biblioteca de clases.

Model

Usando el Entity Framework podemos seguir dos caminos, el primero es crear el Model a partir de tablas en una base de datos y el segundo es crear las tablas a partir de clases existentes en nuestro proyecto, en esta ocasión vamos a usar el primero.

Tabla

Vamos a crear una tabla para almacenar empresas, con los siguientes campos:

Después agreguen manualmente algunas empresas, para que podamos testear la consulta.

Entity Framework

Al usar el Entity Framework para el proyecto simplificamos la codificación de nuestro Model, ya que la herramienta lo creara por nosotros, para poder concentrarnos en la parte complicada, aquí les dejo el link hacia un articulo previo donde explico cómo agregar un Model usando el Entity Framework, solo deben seguir esos pasos.

Coloquen el Model que creara el Entity Framework en la carpeta Model; esto lo pueden obtener, haciendo clic con el botón derecho del mouse sobre la carpeta Model, como se ve en esta grafica:

Contexto

Estamos usando el patrón Singleton y el patrón Service Locator para darle fortaleza a esta parte del código.

Como todo buen patrón necesitamos una Interface, la cual debe crearse dentro de la carpeta Interfaces:

Dentro del Model creen una carpeta que llamaremos Contexto, y dentro de esta agreguen esta clase que implementa la interface que acabamos de crear:

Es una forma muy simple del Service Locator, solo la parte que le corresponde al Singleton, simplemente verifica si no existe y lo crea, lo interesante es el uso genérico.

Acceso a datos

Usaremos el patrón de Repository que hemos ejemplificado en los otros ejemplos, para lo cual debemos crear una carpeta dentro de Model, denominada Interfaces y otra denominada Repositories.

En la carpeta de Interfaces colocaremos esta interface:

Fíjense que en el Namespace, he eliminado la parte que le añade VS y que corresponde a la carpeta donde colocamos la interface, esto me permite simplificar el acceso a lo vayamos creando dentro del Model; aun que se encuentren en diferentes carpetas, para organizar mejor los archivos, en código todo aparecerá dentro del mismo espacio de nombres.

Dentro de la carpeta Repositories colocaremos la clase que se encargara de la entidad empresa, la cual debe implementar nuestra interface Repository y la interface del sistema IDisposable, para que tengamos algo como esto:

Nuevamente observen el Espacio de nombres, subrayado en rojo; pero observen lo que está encerrado en azul, en esta línea se define una instancia de tipo IDataContext (que creamos previamente), la cual emplearemos para controlar la creación de las instancias de nuestro Model durante la ejecución de nuestra aplicación; el motivo es simple, queremos que la creación sea controlada y desde un solo punto.

A continuación les voy a presentar el código que está oculto en las regiones Grises.

Inyección de dependencia

Para asegurarnos que nuestro repositorio no sea cohesivo vamos a usar la inyección de dependencia, la cual tiene una participación muy interesante en la parte del constructor.

Si observan podrán ver que hay un constructor que no recibe parámetros y hay otro que recibe una instancia de nuestra clase HttpDataContext, de esta forma podemos garantizar que si el programador que usa nuestro repositorio desea cambiar esa parte, solo deberá implementar nuestra interface y codificarla según sus necesidades, sin que esto afecte a nuestro código; si por el contrario se limita crear la instancia sin enviarle una instancia, entonces mostros nos encargamos de enviarle una nueva instancia para que sea el nuestro el que emplee.

Implementación del Repositorio

Para esta parte usaremos LINQ ya que es una forma muy sencilla de realizar esta acción, nuestro ejemplo se limita por el momento a obtener todas las empresas que no estén de baja:

Por último la implementación del IDisposable

Este código contiene una llamada al destructor de la instancia, es la que empieza con un circunflejo:

Esta implementación es la recomendada por Microsoft, ya que nos permite realizar cualquier validación antes de llamar al método donde se solicita la participación del Garbage Collector.

Final de la Primera parte

En este punto hemos creado todo lo que necesitamos para el acceso a los datos, en nuestro articulo de mañana vamos a crear los servicios y en el siguiente la capa de presentación, ya falta poco.

Y recuerden: El poder del código solo es completo, si tenemos el conocimiento de cómo usarlo.

Capas con Entidades relacionadas (3 de 3 )

2011-11-07T08:01:00.001-08:00

Según Wikipedia, una API, es una interface programable de una aplicación, es un conjunto de reglas y especificaciones que facilitan la interacción con estas. Este tipo de interfaces nos permiten ofrecer la solución que lleva a cabo nuestra aplicación, para que pueda ser usada por otras aplicaciones, de una manera sencilla.

Lo que estamos haciendo al codificar nuestra aplicación usando capas para colocarlas en ASP, nos coloca en una interesante posición con respecto a las APIs; al lograr que nuestras capas no sean cohesivas, podemos prepararnos para tener nuestra propia API.

8.- El éxito de esta arquitectura reside en el paso que vamos a codificar a continuación; para poder crear una API que pueda migrar a otras plataformas, en este punto es necesario crear una Clase que coordine las operaciones a nivel de la aplicación, se trata de un servicio que recibirá las solicitudes de la UI y realizara las acciones y conversiones necesarias para que la comunicación con el Model no sea cohesiva hacia afuera de estas.

Este servicio contendrá todo el código de control que en las aplicaciones tradicionales escritas usando la arquitectura ASP colocan en el Code Behind; se debe tener cuidado para evitar que a nivel de este servicio se añadan reglas de negocio, estas deben estar en el Model.

Presentador o API.

9.- En el ejemplo anterior lo llamamos Presentador, puesto que se limitaba a presentar la información, sin embargo en esta ocasión la responsabilidad es mayor; para organizar mejor nuestro código la carpeta debe llamarse API:

Por obvias razones de tiempo y espacio, no voy a codificar toda la aplicación, me limitare a mostrarles una de las acciones que se definieron en el artículo anterior, el método CrearCuenta:

Observación: Para simplificar nuestro ejemplo he omitido validaciones básicas, por ejemplo verificar que el cliente no exista para darle de alta. Otro detalle a considerar es, en vez de que sea void el método grabar, debería regresar el identificador que le acaba de asignar la base de datos, para no tener que realizar la consulta, etc.

Este código es con fines demostrativos y no es recomendable que se emplee tal cual en alguna aplicación final.

Ahora vamos a escribir el código para la UI.

Diseñador de Default.

Code Behind de Default.

Observación: Este código puede ser escrito en una aplicación de Windows y de esta forma estaríamos reutilizando todo el código que se creo en las capas inferiores.

Pantalla de creación, después de enviar la solicitud.

Nota: Se ha usado el GUID, para simplificar el código, lo correcto sería tener un código para la creación estos números de cuenta.

Comentario Final

Como ha podido validar a través de estos 3 artículos, el empleo de capas en ASP, es una forma ordenada y muy sencilla de organizar nuestro código y aplicar patrones de arquitectura, así como principios de desarrollo.

Espero que este siendo de utilidad para alguien, seguiré publicando ejemplos.

Y recuerden: El poder del código solo es completo, si tenemos el conocimiento de cómo usarlo.

Capas con Entidades relacionadas (2 de 3)

2011-11-04T15:01:00.001-07:00

Esta es la segunda parte del artículo donde se ejemplifica como usar la arquitectura de capas con entidades relacionadas.

Ya hemos presentado en el articulo previo la capa del doman Model, aun que aun debe ser modificada para incluir todos los controles que se requerirán por los cambios que introduciremos; además en esta segunda parte vamos a terminar con las capas superiores de este modelo.

Nuevos requerimientos.

Para garantizar la integridad de la información que estaremos manejando, debemos incluir en nuestro ejemplo el uso del objeto de transacciones de ADO.

Este mecanismo se implementara en la capa de servicios, pero es necesario modificar lo que ya habíamos creado, la interface de IRepository:

Sera necesario agregar dos parámetros para nuestro método Grabar de la interface de Repository. Mismos que se deben agregar al método grabar de las clases que la implementan:

Nota: Esto debe hacerse en los dos repositorios.

Continuación Tutorial

1.- Para continuar con la capa de servicios, necesitamos una carpeta llamada Servicios, y dentro de esta creamos un folder para ViewModels:

2.- Los ViewModels son una simple representación de las entidades, para mantener la independencia de cada capa:

3.- Dentro de la carpeta de servicios crearemos la clase que se encarga de llevar a cabo las transacciones a nivel del Model:

Este es el código del método RealizaTransaccion que aparecía cerrado en la imagen anterior:

Observación: El objetivo de este código es mantener en un solo punto el control de la conexión, así como de la transacción, para garantizar la atomicidad de la operación. A pesar que se creó publica, lo ideal es que se mantenga interna al igual que las clases de repositorio, puesto que solo las clases a nivel de la API deben ser visibles y de esta forma se evitan accesos indebidos violando la integridad de nuestra aplicación.

4.- Al igual que en el ejemplo anterior, debemos crear las clases para poder convertir una entidad en una ViewModel, mismas que crearemos como extensiones de las entidades, en la carpeta de entidades:

Extensión de cuentas

Extensión de Movimientos

5.- Según nuestra misma arquitectura ahora debemos crear la solicitud y la respuesta, en esta ocasión vamos a preparar nuestro código para poder implementar más de una clase de respuesta, esto es posible creando una clase base que puede ser implementada por cada clase que deba contener esas propiedades:

6.- Si fuera necesario crear otra clase respuesta, por ejemplo para enviar todas las cuentas, podemos crear una clase usando la misma estructura.

7.- Para llevar a cabo las acciones inherentes al manejo de la cuenta vamos a implementar un mecanismo de mensajes, este patrón establece que por cada solicitud debe haber una respuesta, aun que una clase respuesta puede servirnos para responder a mas de una solicitud; las acciones a realizar serian:

Crear la cuenta: Es la acción de abrir una cuenta.

Solicitud

Respuesta

Consultar cuenta: Es la acción de solicitar el estado de cuenta.

Abonar al saldo: Es la acción de sumar efectivo al saldo de la cuenta.

Retirar efectivo: Es la acción de retirar efectivo de la cuenta.

Transferir a otra cuenta: Es la acción de usar el saldo de la cuenta para realizar una transferencia de efectivo a otra cuenta. (Pudiendo ser un pago)

Al terminar tendremos nuestro proyecto de esta manera:

Hasta aquí hemos creado el código de la capa intermedia, ya nos falta poco para poder ver en ejecución este nuevo ejemplo.

Solo nos queda pendiente una entrega, donde podrán ver como se crea una cuenta.

Capas con entidades relacionadas (1 de 3)

2011-11-01T10:13:00.001-07:00

Para quienes hemos estado por muchos años escribiendo código y hemos vivido la evolución de las plataformas y la aparición de Frameworks, así como la sublimación de los patrones, siempre nos queda un lastre, cuando se debe implementar una solución.

Simplemente creemos que sabemos cómo hacerlo, basándonos en lo que sabíamos hacer…

Patrones

Actualmente podemos encontrar soluciones en forma de patrones, que se emplean en los diferentes Framework que hay en el mercado, algunos de estos patrones pueden ser implementados sin importar la plataforma que estemos empleando.

El reto más serio

Dentro del acceso a datos lo más sencillo de codificar es una transacción, pero si cometemos el error de crearlas a la vieja forma Procedural, será lo más complejo y repetitivo de codificar. Los programadores somos animales de costumbres, y pocos nos preocupamos por investigar y descubrir una mejor o más actualizada forma de hacer las cosas.

Las herramientas modernas como LINQ2SQL, Entity Framework, NHibernate, Castle nos ofrecen formas modernas de simplificar nuestro proceso de desarrollo, para que nuestras aplicaciones no presenten problemas en el futuro.

Tal vez deberíamos prestarles un poco mas de atención…no creen?

El patrón Domain Model

En la serie de artículos previos les ejemplifique una forma de implementar capas usando ASP.NET, con la ayuda del patrón Domain Model.

El ejemplo fue muy simple, con fines didácticos, y estoy seguro que una vez que lo vieron funcionar empezaron las dudas: cómo usar esto con entidades con relaciones complejas?

Ejemplo

Toda aplicación administrativa debe llevar registro de los pagos que realiza, así que vamos a implementar una solución para este requerimiento usando la arquitectura de capas que les presente previamente.

1.- Lo primero es crear una aplicación ASP.NET nueva. Tal y como lo hicimos en nuestro ejemplo de capas, empezaremos con la capa de datos.

2.- Para simplificar nuestro código, solo vamos a usar 4 tipos de movimiento: Registro, Depósito, Retiro y Transferencia, aun que en la vida real es más complejo. Para esto crearemos un Enum:

3.- Necesitaremos una entidad para los movimientos en la Cuenta bancaria:

4.- Nuestra última entidad será la cuenta bancara en sí:

Nota: como pueden observar he agregado la propiedad para la CuentaId, sin embargo esta no se inicializa en el constructor.

5.- Vamos a agregar una sobre carga del constructor:

6.- Nuestra clase debe controlar las acciones inmediatas que pueden llevarse a cabo con ella, como son:

Aumentar el Saldo

Disminuir el Saldo

Para aumentar el saldo no existe ninguna regla, sin embargo para poder disminuirlo (por ejemplo: retirar dinero, hacer algún pago, transferir) debe haber fondos suficientes, por lo tanto debemos implementar esta regla de negocio:

Si observan con cuidado podrán ver que en el método de disminuir el saldo, se uso una variable de clase _ultimoMensaje, la cual debe ser expuesta por medio de una propiedad de solo lectura.

7.- Dentro de esta capa se deben ofrecer los métodos conocidos como CRUD, aun que por simplificar el ejemplo solo implementaremos algunos de ellos, para lo cual vamos a crear una interface genérica para que sea implementada por cada repositorio:

Analicemos lo que debemos hacer.

Las entidades que ya hemos creado son clases que representan la información en memoria, en las bases de datos aplican otras reglas, por ejemplo, los movimientos deben estar relacionados de alguna forma con la cuenta o con el cliente; en nuestras entidades, tenemos los movimientos dentro de una colección que es una propiedad de la clase Cuenta.

En la base de datos necesitaremos dos tablas, una con la cuenta y otra con los movimientos, para relacionar ambas usaremos un campo que podría ser el número de cuenta o el identificador del cliente.

Si usáramos el cliente, podríamos tener problemas ya que, ese cliente podría tener otras cuentas y de esa forma se entre mezclarían los movimientos de ambas, así que la mejor opción es usar el identificador o el numero de la cuenta.

Estas son las tablas:

Y este es el diagrama:

Dilema existencial

Para el acceso a datos podemos usar diferentes tecnologías, como son ADO.NET, LINQ2SQL, Entity Framework; además si escogemos ADO, tenernos al menos dos formas de hacerlo, usando Stored Procedures o Escribiendo cadenas de texto con las instrucciones.

Si se atreven a buscar en internet sobre el tema, van a encontrar un número interminable de sitios donde acaloradamente discuten el tema, cada uno con su propio punto de vista.

Para que nuestro ejemplo sea más sencillo de entender voy a usar las cadenas de texto en vez de los Stored Procedures.

Un repositorio o varios

8.- En el ejemplo anterior donde les presente la arquitectura de capas, emplee LINQ2SQL para el acceso a datos, En este ejemplo vamos a usar ADO, Aun que al usar ADO será necesario usar una cadena de Conexión, y requiere que agreguemos una referencia a System.Configuration.

9.- Para nuestro ejemplo crearemos un repositorio para cada tabla; aun que bien podríamos crear un repositorio para la cuenta y este cargar los movimientos.

Hay quienes creen que estaríamos mezclando responsabilidades y quienes creen que es mejor hacer un repositorio por conjunto de entidades relacionadas.

Este es el Repositorio de Cuentas

10.- La implementación de los 4 métodos es esta:

Grabar

ObtenerTodas

BuscarPor

ConvertiraCuentas

11.- Este es el repositorio de Movimientos:

Grabar

ObtenerTodos

ConvertiraMovimientos

Observación: Los movimientos de la cuenta bancaria, no pueden ser modificados una vez que se han registrado, por reglas de contabilidad, solo podrán hacerse inserciones de registros nuevos.

Fin de la primera parte.

En el siguiente articulo vamos a continuar con este ejemplo, hasta el momento tenemos la parte del doman Model.

Ejemplo ASP.NET en capas (3 de 3)

2011-10-31T08:26:00.000-07:00

Una vez que hemos armado las tuberías de comunicación a la base de datos, podemos movernos un poco más arriba, en esta ocasión vamos a crear una capa que controla la comunicación entre la interface de usuario y la capa de servicios.

Me refiero a la capa de Presentación…

Capa de Presentación.

Para esta capa vamos a implementar el patrón Model-View-Presenter, si les parece conocido es porque se trata de una derivación del MVC. Se trata de una variante del patrón, con la cual se sugieren algunas modificaciones:

La Vista no conoce el Modelo.
El presentador es Independiente de la interface de usuario.

Relación Vista Presentador.

La recomendación es usar el modelo de vista pasiva, o sea la vista se limita a presentar los datos, no tiene lógica ni formateo de datos.

El presentador es quien recibe los datos y es el responsable de realizar las acciones contra el sistema; es quien recibe la respuesta y la prepara para la vista.

Donde he visto esto?...Claro es como el Controlador del modelo MVC.

Como se logra la separación entre Vista y Presentador.

Mediante un Contrato, o sea una estructura de datos bien definida que representa toda la información que el usuario recibe. Este contrato está ligado a la vista, cada vista debe soportar un solo contrato.

La única relación entre ambas es el contrato.

Antes de empezar agregaremos una nueva carpeta que llamaremos Presentacion y dentro crearemos una carpeta para las Interfaces.

Tutorial

1.- Lo primero que hacemos será crear el contrato, este contrato no es otra cosa que una interface:

2.- Ahora debemos crear el Presentador:

Descripción del código

Como pueden observar en el código, es en el presentador donde se unen todas las partes que previamente estuvimos codificando.

La explicación del método Display es bastante simple:

Se recibe la solicitud por medio de la cual se identifica para que tipo de Cliente se creara la lista.
Se obtiene los productos para eta solicitud en particular.
Si la acción tuvo éxito, se despliegan los resultados de lo contrario se envía el mensaje de error que se ha obtenido.
Es tan simple que la primera vez que la vi, tuve mis dudas al respecto.

La capa final

Esta capa es la que el usuario ve, es donde el usuario interactúa con nuestra aplicación. Y como les comente en el primero de estos artículos debemos descargar una biblioteca de esta dirección, para que la Inyección de dependencia no sea dolorosa; ya que tratar de implementarla en una plataforma como ASP, nos llevaría mucho tiempo y esfuerzo.

Después de descargar la biblioteca debemos descomprimirla, una vez que tengamos la DLL, vamos a nuestro proyecto y agregaremos una Carpeta nueva a nivel de la raíz, a la cual llamaremos Lib y acto seguido copiamos la DLL en el.

Al terminar agregaremos una referencia a la biblioteca.

Nos encontramos ante un reto interesante, ya que necesitamos una forma de “meternos” en medio, o sea entre la página web y el presentador; es un punto que servirá para preparar nuestro entorno para la inversión del control, permitiendo la inyección de dependencia.

3.- Agreguen otra carpeta a nivel del Raíz, y denomínenla WebUI.

4.- Vamos a crear una nueva Clase dentro de esta carpeta, que nos servirá para registrar las dependencias y permitirle a la biblioteca inyectar lo que corresponde:

5.- Este código es similar al que se usa en MVC y debe ser cargado al principio de la ejecución, por lo tanto debemos asegurarnos que sea así, para lograrlo debemos escribir código en el Global.asax de nuestra aplicación:

6.- Antes de continuar debemos agregar información a la tabla para poder presentar algo cuando ejecutemos nuestra aplicación por primera vez.

7.- Ahora sí, la interfaz de usuario, para el ejemplo voy a usar la página Default.aspx, primero agregare los controles en modo de código fuente:

8.- Este es el código HTML:

9.- Hasta aquí solo nos falta el Code Behind… (Si creyeron que lo íbamos a omitir, pues no es posible, solo le vamos a dar la vuelta), así queda:

Explicación del código

Lo primero que se debe notar es la presencia de nuestra interface junto a Page, para que podamos implementar nuestro modelo dentro de la página.
En el método Init se crea una instancia de nuestro Presentador, pasándole una instancia de la propia página y por medio de la biblioteca nos aseguramos que se envíe la instancia apropiada.
Justo debajo de esta línea, podemos ver que agregamos un delegado para que atienda el evento del DropDownList.
En el método Load, se llama al método Display del presentador, condicionado con el postback.
Luego encontraremos un Bloque de código que contiene la implementación de nuestra interface, lo que nos permite tomar el control.

Prueba

Compilen su aplicación y ejecútenla.

KISS: Simplemente sencillo.

Comentario Final

Esta serie de artículos nos han permitido experimentar esta forma de crear aplicaciones usando ASP.NET, con un enfoque más moderno, el cual nos permite la escalabilidad y nos ofrece una alternativa viable para que nuestra aplicación pueda crecer posteriormente, sin que este crecimiento represente un problema futuro.

Espero que lo hayan disfrutado tanto como yo.

Y como siempre: El poder del código solo es completo, si tenemos el conocimiento de como usarlo.

Ejemplo ASP.NET en capas (2 de 3)

2011-10-28T07:01:00.000-07:00

Hasta este momento ya hemos creado la capa del Modelo de Dominio, y estamos listos para empezar la codificación de la capa intermedia; esta capa también llamada de Servicios, es la encargada de crear el vínculo de comunicación entre la capa a nivel de usuario y la capa de datos.
Su responsabilidad incluye todo aquello que se requiera para trasladar los datos en ambos sentidos, incluso las conversiones entre una vista y otra…

Importancia

Esta capa cumple con uno de los principales requisitos en este modelo de capas, mantener la independencia entre las partes; aislar las clases, para romper con la dependencia tan estrecha que existe en las aplicaciones codificadas usando ASP.

Continuación

Este tutorial es la continuación del anterior donde se creó la capa del Model.

Tutorial
1.- Para mantener ambas capas separadas físicamente, vamos a crear una nueva carpeta al mismo nivel que la del Model, a la cual llamaremos Servicios y Dentro de esta agregaremos otra llamada ViewModels:

2.- Agregaremos el primer View Model:

Observación: al ver el código podrán notar la pequeña diferencia con la entidad, se trata de la propiedad Precio de la entidad Producto, que en este caso se separo en dos propiedades.
En un artículo posterior les mostrare de qué forma podemos agregar propiedades nuevas para contener el porcentaje de descuento, y validar que la afectación será mínima.

Patrón Solicitud/Respuesta.
Al tratarse de una aplicación Web, es necesario tomar en cuenta que se recibirán solicitudes y se enviaran respuestas; estas solicitudes deben cumplir con un contrato especifico, así mismo las respuestas.
3.- Dentro de la carpeta Servicios, agregaremos dos carpetas más denominadas Solicitudes y Respuestas:

4.- Dentro de la carpeta de solicitudes agregaremos una clase para las solicitudes:

Observación: Las letras VM al final nos indican que se trata de un ViewModel.
5.- Dentro de la carpeta Respuestas agregaremos otra clase, para las respuestas:

Ya estamos listos para hacer la conversión de View Models en Entidades. Esta conversión mantiene separados los datos de la pagina y las entidades del Modelo.

Paso de la muerte
Podemos decir que esta es la parte crucial de esta capa, un paso en falso y todo fallara. Así que deben seguir con mucho cuidado las indicaciones; si tienen dudas, sigan los links que se agregan para completar la teoría.

6.- Nuevamente haremos uso de los métodos de extensión, que son mucho mas versátiles que agregar el código a la entidad; en esta ocasión vamos a necesitar dos:

El primero nos permite convertir una entidad producto a un view model de producto,
El segundo una lista genérica de Productos a una lista genérica de ProductoViewModel.

Se trata de una extensión de la entidad producto, así que agregaremos esta nueva clase en la carpeta Entities del Model:

Nota: Este Método de extensión recibe un Producto y lo convierte en ProductoViewModel.

7.- En el artículo anterior agregamos un método de extensión para aplicar el descuento; en esa misma (ProductoListExtension) vamos a agregar otro método nuevo, para poder agregar elementos:

8.- A continuación vamos a crear una clase Servicio que atenderá las solicitudes y generara las respuestas:

Nota: Todo lo que hemos creado se encuentra en memoria, aun no hemos creado un acceso al almacén de datos; para que el trabajo sea mucho mas rápido vamos a usar Clases de LINQ to SQL.

9.- Agregaremos un nuevo elemento de las plantillas de Data, dentro de la carpeta de Model, al cual llamaremos Entidades;

10.- En la base de datos de SQL crearemos una tabla, a la cual llamaremos Productos; desde la IDE de VS solo debemos abrir el panel de servidores, ubicar la tabla y después arrastrarla y soltarla en el diseñador de LINQ para obtener la clase.

Ojo: deben tener cuidado, el nombre de la tabla debe conservarse, de lo contrario se presentaran errores en las extensiones y las entidades.
.
10.- Abrimos la clase repositorio que habías creado en el artículo anterior y la modificamos como se muestra a continuación, para que emplee LINQ al realizar la consulta:

Ya solo falta un articulo para tener el modelo arquitectónico completo. En el próximo articulo podrán completar el ejemplo y ver como se ejecuta.

Fin de la capa de Servicios.

Ejemplo ASP.NET en capas (1 de 3)

2011-10-27T07:53:00.000-07:00

Para poder entender algo tan abstracto y nuevo, será necesario que llevemos a cabo la creación de un ejemplo donde podamos ver de qué manera los patrones afectaran la estructura de nuestro proyecto.

El ejemplo es simple, pero que nos permite ver como se crean las capas…

Introducción

Este articulo es la continuación del denominado ASP.NET sobre capas, los términos y la teoría que aquí se ejemplifican están en él; en esta ocasión me limitare a explicar cómo se crea la estructura de un proyecto usando esas capas y ampliare lo que no haya mencionado en el articulo antes citado. Los links les llevaran a profundizar en los temas que se mencionan.

Forma parte de una serie de 3 artículos que explicaran la implementación de este modelo de capas en su totalidad.

Tutorial

1.- Crearemos una nueva aplicación ASP.NET WEB, puede ser con VB o con C#.

Nota: En este punto debo hacer una observación, en el artículo anterior dije que en el flujo de codificación de las aplicaciones modernas se debe empezar por las clases, así que en este ejemplo vamos a empezar por crear las clases del Model.

2.- Hagan clic con el botón derecho sobre el proyecto y agreguen una carpeta nueva a la cual denominaran Model.

3.- Dentro de esta nueva carpeta vamos a agregar otra que llamaremos Interfaces.

4.- Ahora agregaremos dos capetas mas, una para almacenar las entidades, que debe llamarse Entities y otra llamada Custom, que contendrá las clases de apoyo.

Nota: Para nuestro proyecto vamos a usar el patrón Strategy, que se ejemplifica en el artículo del patrón Builder. El cual es muy útil para permitirle a l código adaptarse a situaciones desconocidas en el futuro, como podría ser el caso del mecanismo de descuentos que ofrece nuestra aplicación.

5.- Este patrón como casi todos empieza con una interface, la cual debe quedar en la carpeta Interfaces:

6.- Ahora vamos a crear una clase que implementa esta interface, dentro de la carpeta Custom:

7.- Para prevenir errores por valores nulos se recomienda el empleo del patrón de Objetos Nulos, como se muestra a continuación; creada dentro de la carpeta Custom:

8.- Nuestra entidad principal debe contener una propiedad para almacenar el precio de venta, que puede ser modificado usando la estrategia de descuentos; por lo tanto crearemos una clase que se empleará como tipo de esa propiedad, para que podamos tener el control de nuestra estrategia:

Observación: Si prestan atención al método ObtenerDescuento, podrán detectar la regla de negocio que impide la aplicación de un descuento que ocasione que vendamos a menor precio del costo.

9.- En este momento podemos crear la clase Producto:

10.- Para controlar la aplicación del descuento será necesario ligarlo de tal forma que nos permita, que dicha interacción sea automática, por ejemplo el tipo de cliente. Para lo cual agregaremos una nueva carpeta dentro de la carpeta Model, a la cual le pondremos por nombre Enums.

11.- Para terminar con la implementación de este patrón necesitaremos una clase Factory, que tendrá la responsabilidad de crear el objeto descuento que corresponda:

12.- En este punto vamos a preparar nuestra capa para acceder al almacén de datos, para lo cual vamos a emplear el patrón Repository. Empezaremos con una interface, para continuar con la separación de las partes.

Observación: conforme avancemos agregaremos mas métodos a la interface, por el momento solo usaremos uno.

13.- Antes de crear el repositorio de productos, vamos a agregar una nueva carpeta llamada Repositories dentro de Model, después agregaremos esta clase:

Observación: Este código tiene una excepción, si me han seguido con cuidado, se habrán dado cuenta que al momento de obtener los productos estamos omitiendo el mecanismo de descuentos que creamos al principio. Ese mecanismo se aplica a un producto, y en este caso estamos tratando con una lista, por lo que será necesario extender la funcionalidad, con un método de extensión.

14.- Creamos nuestro método de extensión dentro de la carpeta Entities:

15.- Luego modificamos el método GetAllfor de la clase ProductosRepository:

De esta forma al solicitar los productos se aplicara la estrategia de descuento que le corresponde al cliente.

Comentario Final: Esta última clase repositorio se modificara en el siguiente articulo cuando se cree el acceso a datos.

Fin de la primera parte.

ASP.NET sobre capas

2011-10-26T08:33:00.001-07:00

La solución que ofrece Microsoft al problema del código mezclado es el Code Behind. Una forma al parecer simple de separar el código HTML del código VB o C#, en un archivo aparte.

Este archivo aparte contiene código que responde a los eventos que se disparan en la interface, y al final termina siendo una forma disfrazada de SMART UI, debemos romper ese vicio….

Como podemos romper ese círculo vicioso?

Debemos aplicar las buenas practicas como cuando empleamos el principio SoC (Separation of Concerns) o separación de las partes, como se explica en este otro artículo que habla de MVC, pero desde la arquitectura de ASP representa un reto.

Capas

Al principio puede parecer forzado, podría parecerles que quiero cambiar la arquitectura de ASP para que se adapte al modelo MVC, sin embargo no es así; la idea es aplicar un patrón ya probado en una arquitectura que puede ser mejorada, si sabemos que ajustes realizar.

El objetivo es aplicar principios y patrones para que nuestra aplicación pueda soportar los cambios y la evolución a la que se enfrentara durante el proceso de desarrollo e implementación en producción.

Tradicional ASP vs Capas:

Una aplicación típica desarrollada usando ASP.NET contiene paginas, que contienen controles, de tras de esa pagina existen manejadores de eventos que se codifican en el Code behind, los controles o el Code Behind lleva a cabo el acceso a los datos, posiblemente si son exigentes con su trabajo, a lo mejor tengan bibliotecas para esto, sin embargo la relación entre la interface y el Code Behind, es muy difícil de romper.

Para poder lograrlo, lo primero será identificar las responsabilidades que se encuentran entre mezcladas en ese modelo:

Puntos

Web UI
Manejo de eventos
Servicios
Clases que representan entidades en algún almacén de datos.
Código de acceso a ese almacén de datos.

Donde va cada cosa?

En una aplicación de capas se asignan responsabilidades en niveles que van desde el usuario hasta los datos. El Code Behind no es una capa.

Se debe identificar que contendrá cada capa, cuales serán esas capas y cuáles son las reglas de su uso e implementación.

Patrón de Modelo de dominio (Punto 4)

La programación moderna empieza por el modelado de Clases, así que lo primero será definir esta responsabilidad. Este patrón fue presentado por Martin Fowler en 2003 y según su definición

“Es un objeto que contiene comportamiento y datos”.

En este modelo debemos incluir toda la lógica de negocios, tanto datos como funcionalidades relacionadas a esta. Contendrá nuestras clases, si alguna clase requiriera de algún tipo de lógica para determinar un dato, esta lógica debe estar en esta capa.

Como una forma de mantener las partes independientes, se recomienda el uso de interfaces de código, que deberán ser implementadas por las clases.

Capa de servicios (Punto 3)

Esta capa intermedia será nuestro punto de comunicación entre la aplicación y los datos; para sustentar esta capa en patrones les diré que en un extremo se encuentra el patrón Facade y en el otro extremo el patrón ViewModel.

Una Facade (es una fachada) por ejemplo una interface que debe enviar y recibir datos, estos datos deben ser tipificados para conseguir la relación, pero al mismo tiempo la independencia con respecto a la capa superior.

En esta capa se reciben los datos en forma de ViewModels que se traducen en términos del modelo, para mantener la independencia entre las capas; si se presentará un cambio a nivel de los datos solo afectaría hacia un lado de la relación.

Capa de presentación (Punto 2)

Continuando con la aplicación de patrones, en esta capa usaremos el patrón MVP con sus siglas en ingles, Model-View-Presenter; contendrá interfaces para que sean implementadas por las formas web, lo cual refuerza la independencia de las capas.

Capa a nivel del usuario (Punto 1)

El reto más grande con respecto a la arquitectura ASP, es lograr que el control de que reside en la interfaz de usuario se traslade hacia las capas inferiores, para evitar que esta sea la que se encargue de crear los objetos, para ser una receptora de los mismos.

Esta acción es muy compleja de codificar, por lo cual vamos a apoyarnos en una biblioteca gratuita que podemos descargar de aquí.

Comentario Final

Este articulo podría parecer muy abstracto (y hasta cierto punto lo es), sin embargo si han leído los artículos que previamente publique en este mismo blog, deben tener las bases para entender lo que vamos a hacer.

Si no es el caso y les resulta confuso, entonces deben leer los siguientes artículos, ya que en ellos voy a desarrollar un ejemplo; podemos decir que este artículo es la introducción y deben leerlo para poder entender el ejemplo.

Y no se olviden: El poder del código solo es completo, si tenemos el conocimiento de cómo usarlo.

Como determinar que patrón usar.

2011-10-25T06:51:00.001-07:00

Conocerlos y haberlos usado en alguna ocasión o por ejemplos, no es suficiente para poder determinar cuál sería el patrón que mejor se adapta a nuestro problema, incluso podría no ser necesario usar alguno.

Según mi propia experiencia puedo darles algunas ideas…

Lineamientos

Estos consejos no son más que la forma en que llevo a cabo un flujo mental para tratar de determinar cual patrón debo emplear en mis proyectos:

Lo primero es conocerlos. Si no los conoces no podrás aplicarlos.
Antes de tratar de entender un patrón es importante tener bases firmes sustentadas en el conocimiento de los principios de desarrollo.
Antes de decidir emplear un patrón investigar sobre las variantes de implementación conocidas.
Se debe tener cuidado con respecto al tiempo que podría llevarnos realizar la implementación de un patrón, podría ser un factor determinante para evitarlo o descubrir que no es viable.
Es muy importante poder generalizar el problema que vamos a solucionar, descomponerlo en piezas y tratar de verlo lo más genérico posible antes de empezar a codificar.
Un problema debe verse desde diferentes puntos de vista, piensa en él como una pieza de un rompecabezas, a la cual tratas de colocar en un lugar y a veces debes cambiar su posición, para hacerla encajar y muchas veces esta pieza no encaja donde trataste de ponerla, pero mientras la observas descubres donde va.
Los patrones están clasificados dentro de tres grandes grupos: Creacionales, estructurales y de comportamiento así que mientras analizas el problema debes tener en cuanta a que grupo pertenece tu problema en particular.
Una vez que has identificado a qué grupo pertenece es muy importante tratar de ver el código en la evolución de la aplicación como un todo, podría tratarse de un código estático e inmutable a través del tiempo, pero podría ser una regla de negocios que evolucionara con el paso del tiempo.
Evita re inventar lo que ya fue hecho con anterioridad, si analizas el problema con detenimiento podrás descubrir que se trata de algo que ya fue hecho en el proyecto antes de volver a escribir ese código, posiblemente de otra forma, con lo que tendrías la misma solución en dos lugares de dos formas distintas.
Que hacer si el código ya fue liberado y descubres que podría hacerse mejor con un patrón?
No temas refactorizar, la refactorización ocurre a nivel de código y no debe afectar el comportamiento de nuestro método.

Comentario final

La mejor forma de sacar el máximo provecho de una herramienta de desarrollo es aprendiendo a usarla, conociendo sus atajos y formas de mejorar su desempeño; al escribir código debemos descubrir entre las líneas de código, esas situaciones que se repiten y que forman parte de algún patrón al codificar.

Y no se olviden: El poder del código solo es completo, si tenemos el conocimiento de cómo usarlo.

Anti patrón Smart UI.

2011-10-24T14:52:00.001-07:00

Quien no ha escrito una aplicación urgente agregando controles a una página o formulario y por la facilidad que nos ofrecen las herramientas de desarrollo como Visual Studio, agregamos código a los eventos en la misma interface, después de todo es algo rápido y no va a servir más que para esta vez.

Además si lo podemos hacer, es porque la herramienta lo permite, entonces no debe ser mal, no? Pues no es así, es una mala práctica que no debemos repetir…

Código en la interface

Quienes empezamos a escribir código antes del .NET, vivimos en una época donde el código y los controles se entremezclaban para crear una aplicación; pero también sufrimos con todos los problemas que esto acarrea.

Hoy en día es sabido por todos que el código y los controles no deben estar en el mismo lugar, aun que es probable que encontremos algunos viejos lobos solitarios que no han modificado esa ancestral practica, a la cual se le conoce como un anti patrón.

Los anti patrones son patrones que son usados comúnmente, pero que en realidad son inefectivos, incluso es contra producente su aplicación; podríamos simplificarlo diciendo que se trata de un mal habito de programación.

ASP

Si trabajaron con el ASP antes del .NET, en sus inicios saben de que estoy hablando, el código HTML entre mezclado con el código de VB era un caos; el mantenimiento y las modificaciones un dolor de cabeza.

La reutilización era casi imposible, algunos inventamos formas de reutilizar el código pero en vez de ser útil, terminaba siendo una pérdida de tiempo.

Incluso hoy en día es muy fácil caer en la tentación de repetir esta mala práctica, pensando que no le hacemos daño a nadie sobre todo si nosotros somos los que vamos a darle mantenimiento a la “pequeña aplicación” que nos solicitaron, quizás una utilería, o que se yo.

Lo cierto es que si afectamos severamente a alguien…a nosotros mismos.

Codificar primero

El problema radica en sentir que somos expertos y que a nosotros no nos pasara, que nosotros si podemos escribir el código sin tener que hacer uso de diseños, pensar que podremos controlarlo.

El peor error de un programador es escribir el código sin antes haberlo entendido, sin elaborar el más pequeño diagrama o cuando menos conceptualizar lo que vamos a codificar.

Lo más común es que nuestro código resulte en una serie de problemas que difícilmente podemos reparar:

Dependencia entre las clases
Ausencia de capas
Y un sinfín más de problemas.

Que debo saber para poder usar los patrones apropiadamente?

Los patrones no son la solución a todos nuestros problemas, para poder sacar provecho de ellos, es necesario conocerlos, aprender cómo se lleva a cabo su implementación, probar las variantes que existen y conocer las fortalezas y debilidades.

Es necesario saber leer los requerimientos para poder detectar la necesidad de alguno de ellos en nuestro código; al principio resulta complicado, pero conforme los tenemos en cuanta y nos hacemos disciplinados en nuestro proceso de codificación, avanzaremos en le dominio de estas increíbles herramientas al escribir código.

Nueva etapa del Blog

En esta nueva etapa del Blog, me encuentro en preparación de un proyecto para un cliente, pero por requerimientos específicos, debe ser ASP.NET, no MVC; lo cual quiero llevar a cabo de la mejor manera posible, aplicando patrones a todas las etapas del desarrollo.

En este blog estaré comentando el avance y ejemplificando el uso y la implementación de patrones con ASP.NET.

Y no se olviden: El poder del código solo es completo, si tenemos el conocimiento de cómo usarlo.

Andamios?

2011-10-11T09:12:00.001-07:00

En la versión anterior de MVC de Microsoft, la 2.0 encontré en repetidas ocasiones la palabra Scaffolding. La traducción literal es ANDAMIO, a pesar que investigue sobre ella, la tecnología en ese momento era más limitada.

En MVC 2 podemos crear automáticamente los Controllers y las Vistas con un simple clic en el lugar apropiado. En la nueva versión MVC 3 los programadores han ido mas allá, permitiéndonos crear de forma automática el código del cual podemos partir.

Si la versión anterior me pareció un gran avance, esta nueva versión es mucho mejor.

Que necesito?

Para poder usar esta nueva herramienta es necesario instalar la versión del MVC 3, lo cual puede llevarse a cabo sin tener que desinstalar la versión previa.

Una vez instalado podemos acceder a la tecnología NuGet la cual es un código gratuito y su objetivo es ampliar las posibilidades de integración de bibliotecas de terceros a la plataforma de .NET.

Ejemplo

1.- Crear un proyecto nuevo con MVC 3.

2.- Seleccionamos el tipo de motor de vistas. (Próximamente hablare del RAZOR).

3.- En la carpeta de MODEL, creamos una clase:

4.- Lo compilamos y abrimos la ventana de NuGet:

5.- En la parte inferior se abrirá una ventana tipo consola que nos permite escribir comandos en ella:

6.- Escriban: Scaffold Controller Producto

Observación: La palabra producto es el nombre de la clase que queremos usar para crear el código automático.

7.- La ventana de la consola presentara algo como esto:

8.- En nuestro proyecto aparecerán los siguientes elementos:

En la carpeta de Controllers: ProductoController.
En la carpeta de Model: STInventoryContext
En la carpeta de Views aparecerá una carpeta denominada Producto que contendrá las vistas.

9.- En este punto la aplicación es completamente funcional.

Si tienen instalado SQL Express en la maquina, mediante EFCodeFirts se conectara y creara los elementos necesarios para que se convierta en una aplicación.

Comentario final

Después de varios mese de estar desconectado de este Blog, voy a tratar de retomarlo a partir del día de hoy, con MVC 3.

Aun estoy empezando a probarlo y la verdad creo que me espere mucho para hacerlo…nos estamos viendo.

Suerte.

DisposeCurrent

2011-05-19T07:57:00.001-07:00

En las aplicaciones que desarrollamos siempre debemos tener en cuenta la posibilidad de quedarnos sin memoria; aun que casi siempre le dejamos esta tarea a nuestro buen amigo El Garbage Collector.
Lo cierto es que no podemos predecir en qué momento va a pasar a nuestra puerta a recoger la basura. Así mismo el Recolector no podrá realizar su trabajo adecuadamente si le ponemos una cadena y un candado a nuestro bote de basura, no creen?
Esto ocurre cuando nuestras aplicaciones emplean una estructura de clases compleja y los recursos que se están liberando no pueden ser o no deberían ser removidos aun, en vista que podrían estar realizando alguna actividad que se atraso.
La recomendación que nos hace Microsoft es que usemos el patrón Try Catch para poder atender situaciones de este tipo, en aquellas clases que pudieran encontrarse en ese escenario.
En un articulo que publique en febrero de este año presente un ejemplo donde definía una interface que empleaba un método que no desarrolle en dicho articulo, Lau me solicito un ejemplo desde Abril y debido ala carga de trabajo no había podido atender su solicitud, así que hoy pondremos un ejemplo que es el complemento de dicho articulo .

Ejemplo:

En ese ejemplo se presenta el patrón de repositorio, si observan con detenimiento tanto en la definición de la interface como en la clase que lo implementa podemos identificar una interface que se relacionan con el tema: IDisposable.
En el último párrafo de código aparece la región donde se implementa esta interface, pero aparece contraída, así que a continuación la voy a presentar para que puedan ver la forma en que se implementa:

En este primer párrafo vemos un destructor mismo que llama al método Dispose usando como parámetro un valor false, esta es la forma que pertenece al patrón recomendado por Microsoft para que se emplee en este tipo de situaciones:

En este segundo párrafo podemos ver que se llama un método Dispose que recibe un parámetro true y justamente después se llama al Garbage Collector pasándole como parámetro el objeto que lo está llamando.

En este último método que es llamado por los dos métodos anteriores, con diferente parámetro, podemos observar que cuando el destructor llama al Dispose, este no destruye la referencia que se creó al principio de nuestro ejemplo; sin embargo cuando es llamado al momento de tratar de disponer de el nuestro Garbage Collector, entonces si podemos ver la forma como se libera un recurso que por su naturaleza podría no haber sido liberado aun, y que se declaro al principio de esta clase, creando una relación con esta.
Espero que este ejemplo sirva para concluir la idea que en el artículo anterior quedo a medias.
Suerte.

Image Handler (MVC y WebForms)

2011-04-12T16:10:00.001-07:00

En una aplicación web , cualquier pista que le permitamos obtener a un hacker, es suficiente para que tengan alguna idea de cómo está organizado nuestro sitio, o simplemente saber cuál es el sistema operativo, etc. Algo tan simple como la ruta de una imagen al ser obtenida del sitio puede ser suficiente.

Http Handler

ASP.NET nos ofrece una funcionalidad que nos permite implementar un HTTP Handler. El principio es simple, cada vez que una página es solicitada la solicitud es atendida por un objeto que implementa la interface IHttpHandler, la cual requiere un método llamado ProcessRequest que se encarga de escribir lo necesario como salida.

El HTTP Handler implementa la misma interface, y por consiguiente es muy fácil crear un Rest Service que pueda enviar imágenes como resultado. Al handler podemos enviarle parámetros en la misma cadena de solicitud. Si usamos un entero o un Guid, la ruta quedaría encapsulada en la lógica del código de nuestro RestService.

Que necesitamos?

Un Generic Handler, al cual llamaremos ImageHandler:

El código original se ve así:

Nosotros tendremos que escribir el código del método que procesa la solicitud. Primero obtendremos el id que nos envía la pagina, ya sea un entero o un guid.

En la sección de declaraciones de variables, usaremos la ruta de una imagen default en caso de no encontrar la que se solicita. (Mecanismo no incluido)

Con este dato podríamos buscar en nuestra base de datos (código comentado).

Una vez obtenida la ruta, verificamos que el archivo exista para poder cargarlo:

Regresamos el resultado:

En la página el código html debe ser algo así:

Cuando ejecutamos nuestra aplicación la página presentara la imagen:

Este ejemplo funciona para MVC y WebForms.

Por ultimo el código completo del handler seria este:

El poder del código solo es completo, si tenemos el conocimiento de como usarlo.

Que tanto debo documentar mi código?

2011-04-11T11:17:00.001-07:00

Al igual que todos aquellos que sintieron curiosidad por este tema, yo también soy Desarrollador, disfruto solucionando problemas, y no me canso de agregar código a mi aplicación…pero si alguien se atreve a pedirme que agregue documentación a mi código, siento que debo levantarme de mi lugar e irme.

En serio lo entiendo, casi siempre que le he pedido a algún programador que agregue comentarios (para no usar la palabra documentación) aun que sea a los métodos, puedo ver la inconformidad en el rostro.

Que es lo que pasa?

La mayoría de nosotros pensamos que documentar es una pérdida de tiempo, no es cierto?. Pensamos que nuestro tiempo es muy valioso y que debería aprovecharse escribiendo código, no documentándolo…además lo que refuerza esta actitud es que casi siempre trabajamos para mostros mismos, por lo que sentimos que esos comentarios en nuestro propio código están de más, no?

Pero, cuando pasa el tiempo y debemos utilizar de nuevo ese código, y volvemos a abrir el archivo; cuando vemos el código después de tanto tiempo, sentimos que un mínimo de comentarios nos ayudarían en ese momento, para no tener que leer de nuevo las líneas y tratar de acordarnos que fue lo que hicimos. Y perder el tiempo tratando de recordar.

Y si el código es de otro programador, entonces ahí si queremos comentarios, cuando algunos comentarios estamos agradecidos, ya que una línea donde se explica es mejor que no tener nada. Tal vez sea cuestión de orgullo, de pensar que no necesitamos documentar nuestro código, pero la verdad es que si se necesita.

Como se agrega?

El Visual Studio nos ofrece tanto a quienes programamos en C# o en VB, la posibilidad de agregar comentarios de una forma simple y fácil de usar.

El VB solo debemos escribir tres apostrofes (‘’’) para ver algo como esto:

Este comentario es visible cuando estamos en la IDE y usamos el método, el intellisense nos presenta esta información que nos puede servir de guía:

Si estamos escribiendo nuestro código en C#, debemos usar tres barras diagonales ( ///).

Es muy fácil e incluso hace que nuestro código se vea más profesional, este simple detalle nos hace sentir seguros, y le inspira confianza a quien use nuestro código. Animo solo deben comentar el mínimo necesario, no más!

Para mayor referencia pueden visitar estas direcciones (están en ingles):

Para c#: http://msdn.microsoft.com/en-us/magazine/cc302121.aspx
Para VB: http://msdn.microsoft.com/en-us/library/ms172653(v=VS.80).aspx

Diferentes objetos una sola colección

2011-04-07T07:17:00.001-07:00

A veces nos hacemos una idea y nos aferramos a ella, a veces creemos que algo es posible y nos sentimos motivados cuando avanzamos en la solución y vemos que lo que nos imaginamos se va materializando frente a nuestros ojos. A veces este tipo de situaciones crean un espejismo que nos impide ver lo que en realidad estamos haciendo. Hoy me enfrasque en una tarea que me llevo a codificar un ejemplo para verificar que si era posible lo que me estaba imaginando.

Requerimientos

El proyecto en el que estoy trabajando contiene internamente varios componentes que generan información de diferente tipo, el problema es que debo devolver esta información de diferente tipo por medio de una sola clase. El reto consiste en poder almacenar cualquier tipo de dato, que pudiera ser agregado a la colección para ser devuelto posteriormente y manipulado en donde se reciba.

Análisis

Para poder almacenar objetos de diferentes tipos en una colección podemos usar Arreglos, sin embargo la implementación es muy pobre y deja poco margen de maniobra, así que me decidí por usar un diccionario.

Solución Aparente

Solo necesite dos clases para poder llevar a cabo esta prueba. Una Clase que contuviera internamente los diccionarios de tipos de dato y de objetos. Y otra más para poder exponer los elementos de forma individual. La primera clase se llamo Colección y estaba codificada de esta forma:

Declaraciones y propiedades:

Constructor:

Métodos para agregar y para obtener un elemento:

Para el método que se emplea en el For Each, se creo una clase que se llamo Par y esta codificada de esta manera:

Y por ultimo un método para emplear con el For Each

Para probarla use una aplicación de consola como siempre:

El resultado es:

Revisión de la solución aparente

A pesar que aparentemente soluciona nuestro problema, no es la forma correcta de hacerlo. En .NET se han creado todo tipo de colecciones para que puedan ser tipificadas, por lo que hacer algo que use objetos no específicos, es ir en contra de la evolución. Para recuperar objetos es necesario saber de antemano el tipo de objeto que queremos obtener.

En situaciones como esta lo que debemos hacer es detenemos un momento a pensar en los requerimientos, analizarlos con cuidado, si nos fijamos en el texto podemos identificar donde se creó el espejismo, fue en la parte que dice: “información de diferente tipo… por medio de una sola clase”; esto no quiere decir que nosotros debamos implementar un código para manejar objetos de diferente tipo en una misma clase.

Interfaces al rescate

Dentro del .NET podemos crear interfaces, que son un elemento muy valioso para proyectos con este tipo de complejidades. Si creamos una interface que contenga las propiedades que son comunes a todos los componentes, las que deben ser expuestas y verificamos que todos los componentes que creemos la implementen, entonces podremos crear una sola colección que reciba diferentes objetos pero que al implementar la misma interface, pueden ser tratados como uno mismo tipo.

Solución apropiada

Se requiere una interface y una colección que reciba objetos que implementen esta interface.
La interface quedo así:

Nuestra colección quedo de esta forma:
Declaraciones y propiedades:

Constructor:

Métodos para agregar y para obtener un elemento:

Podemos observar que nuestros métodos esperan la interface.
La clase para el método GetCurrent se llamo Pair y esta codificada de esta manera:

Un método para emplear con un For Each:

Las clases deben implementar nuestra Interface, este es el ejemplo de una de ellas:

Para probarla use una aplicación de consola como siempre:

El resultado es:

Conclusión

Siempre es importante que nos cuestionemos si lo que estamos haciendo es lo correcto, una solución aparente puede traernos muchos problemas con el tiempo.

DropDownList en MVC

2011-04-05T13:44:00.001-07:00

Desde que empecé a trabajar con las versiones beta de MVC, me tope con un reto que no le encontraba ni pies ni cabeza. Algo que siempre fue simple en ASP, resulto ser complicado en MVC. O al menos a si lo parecía. Así es, llenar un combo o Lista desplegable en MVC requería pasos extra, para poder completarse. Cuando vienes de un entorno donde todo se basa en controles y nos limitamos a llenarlos con el resultado de una consulta, el entorno MVC resulta confuso al principio.

Views

En MVC las páginas no existen como en WebPages, lo que se crea se denomina View; las Views son archivos que se limitan a presentar la información que el controller le proporciona al ViewEngine. Una View Tipificada está relacionada a una entidad para poder realizar esta tarea. O sea, cada elemento que se presenta como un control HTML esta en relación a una propiedad de esta clase o entidad.

Dentro del Código que define nuestra View, el Model es nuestra entidad principal, se define en las directivas al principio del código, por lo que podemos acceder a sus propiedades por medio de él.

Si queremos presentar una lista desplegable, entonces debemos proporcionarle al Engine esta información, y esto debe llevarse a cabo desde el controller, ya que según el patrón, el engine no debe realizar ninguna llamada al Model. Debido a esta limitante es necesario recurrir a una estructura que nos permita enviarle al engine la entidad y nuestra lista desplegable.

ViewModel

Para esta tarea debemos crear una clase especial que se conoce como ViewModel, este término resulta ser uno de los aspectos centrales de la arquitectura MVC. He encontrado muchos artículos donde lo comentan y según vi crea mucha polémica, pero como yo no quiero, mejor veamos cómo se usa.

Se debe crear una clase, con la estructura de datos que requiere nuestra view para poder crearse, se le debe proporcionar la entidad como una de estas propiedades y si queremos una lista desplegable, será necesario agregarle una lista genérica de la entidad que usaremos para llenar nuestro DropDownList. Es importante que le agreguemos una propiedad por medio de la cual se recibirá el ID que el usuario seleccione de la lista:

Una vez que se ha creado esta clase, debemos compilar el proyecto para que la nueva clase aparezca en nuestro asistente de View y podamos usar el ViewModel para nuestra vista tipificada. De esta forma nuestra View heredara de nuestra Clase ViewModel.

Al hacer esto nuestro Model contendrá un nivel extra para poder acceder a las propiedades de nuestra entidad:

Además será necesario llenar el ViewModel antes de enviárselo al Engine y que se cree nuestra View:

Código en View

En el código del View usaremos un helper:

La sintaxis del Helper requiere que le enviemos el nombre del elemento, así como nuestra lista Genérica como un enumerable, la siguiente propiedad es el value de la lista desplegable, seguida del texto que se presentara en la lista y por último la propiedad del model donde se almacenara el id seleccionado.

En la pagina se vería de este modo:

El valor seleccionado regresara a la acción por medio del automatic Binding y podrá ser accesible desde nuestra variable:

El poder del código solo es completo, si tenemos el conocimiento de como usarlo.

Validación

2011-04-01T08:55:00.001-07:00

Ya que hemos emprendido este camino de tratar de hacer las cosas de la mejor forma, no hay vuelta atrás. A partir de que cruzamos esa línea, nos cuestionaremos todo; sin embargo no es malo, por el contrario, resulta ser un proceso de madurez que al ser acompañado por aprendizaje, resulta motivador.

A veces los temas son conceptuales, y colisionan con nuestros conocimientos y principios sobre algo que ya sabemos, con lo que hemos estado trabajando desde siempre y que de repente se ve inmerso en una lista de dudas; por ejemplo ayer en una plática con el equipo de desarrollo, surgió la pregunta…

Donde ponemos la validación?

Y esta pregunta no se origino por el desconocimiento o por no saber cómo hacerlo, simplemente la duda surge porque la arquitectura del proyecto está formada por capas (basada en el patrón MVC), que tiene claramente definidas sus responsabilidades y que pueden realizar el proceso de validación todas y cada una de ellas.

Capas

UI.- Es la capa que da la cara al mundo, es por medio de esta capa que se recibe la información del usuario.

Controladores.-Hay dos diferentes tipos de clases que son el único medio de acceso a nuestro Framework, son las Clases Controladores o las Clases para atender Servicio. Ambas tienen acceso a un nivel que se encarga de realizar las validaciones, tanto de lógica de negocios como de datos.

Repositorios.- Envía la información recibida a la Capa de Acceso a datos, esta clase implementa el patrón de repositorio y es la única clase que saber cómo se realiza el acceso a datos, o sea encapsula dicha comunicación, para aislar a las capas superiores del origen de datos.

Model.- en este nivel encontramos el Entity Framework, el cual representa el Model y es el que en realidad realiza la plomería de comunicación al almacén de datos, ya sea para hacer persistentes los cambios o para recuperar información.

Base de datos: En la última capa encontramos a la base de datos, con las reglas de información, relaciones y datos que deben proporcionarse.

Tipos de validación

Aclaremos de ante mano que dentro de la validación común encontramos dos tipos las que son reglas de negocio, que resultaran altamente volátiles y la validación de datos, que muy pocas veces se modifica. Nos concentraremos en la validación de datos, ya que las reglas de negocio son un tema por sí mismas.

Si partimos de la idea que nuestra arquitectura fue diseñada para que las capas puedan ser reutilizas, para que no sean cohesivas y que puedan interconectarse en el futuro con clases nuevas que surjan en las capas anteriores y posteriores a ellas, no es recomendable caer en un escenario donde la validación sea obviada o excesiva. En situaciones como esta la validación de los datos debe hacerse lo más cerca de los datos en sí, de ser posible dentro de ellos mismos, como ocurre en la base de datos; de esta forma cuando usemos estos, sus reglas de validación estarían íntimamente relacionadas y serian reutilizables, por todo aquel que deba emplear estos.

Donde es más recomendable?

Estamos hablando de la Base de datos y de las entidades, las reglas de la base de datos se incorporan al Model, o sea nuestro EF, el cual efectúa estas validaciones. Sin embargo en nuestra arquitectura estamos usando Clases parciales, para poder extender las entidades del EF, con propiedades que no requerimos incluir en las entidades para que sean persistentes, pero que se requieren para la codificación, y los ViewModels que son una especie de entidades virtuales.

En estos dos casos, las propiedades nuevas que se añaden a las clases parciales y a los ViewModels, no tiene reglas de validación de los datos, nosotros debemos implementar el mecanismo correspondiente para que las reglas de validación de estos datos, se puedan reutilizar.

Solo ahí se pueden poner las validaciones?

En realidad, la preocupación principal es determinar si debemos hacer validación en todas las capas, o en cada capa solo debemos hacer un tipo de validación? Debemos asumir que la capa anterior cumplió con su tarea?

Hay otros puntos en relación con el tema que se deben tomar en consideración:

En la UI, para asegurarnos que la información proporcionada por el usuario sea la mínima necesaria, se requiere validar tipos de datos, formato adecuado, y datos requeridos. Esto se puede llevar a cabo con controles de captura. Nuevamente debemos aprender a separa las reglas de negocio de este tipo validaciones, las reglas de negocio no se deben poner en un control.

En el nivel de las clases controladoras, podemos aplicar un mínimo de validación solo por ser asertivos, verificando que nuestra clase reciba lo mínimo necesario para poder trabajar, sin embargo cuando se pueda debemos apoyarnos en la arquitectura de nuestro proyecto, esta tarea le correspondería a las clases de validación y de reglas de negocio.

En el repositorio no es necesario ya que este trabaja en intima relación con las controladoras o de servicios, y además el repositorio no puede ser accedido si no es a través de las a clases antes mencionadas, ya que su acceso está restringido, solo a clases dentro de nuestro Framework.

El ultimo bastión, la base de datos, aquí se deben establecer las reglas de tipos, datos que no deben ser nulos y datos que deben estar relacionados, ya sea por una relación maestro detalle, o por una relación de llaves foranes.

En un post próximo hablaré de las reglas de negocio.

RefreshMode en el EF

2011-03-30T12:41:00.001-07:00

El EF es una de las herramientas más poderosas con las que he tenido que trabajar usando tecnologías de Microsoft, sus alcances son muy interesantes, nos ofrece innumerables funcionalidades y mecanismos; a tal grado que cada día podemos descubrir algo nuevo, algo que no sabíamos, pero también puede ser un dolor de cabeza cuando no sabemos por dónde empezar.

La mayor parte del tiempo, damos por sentado que la herramienta hará todo por nosotros y pocos somos lo que nos interesamos en saber como lo hace.

Ayer se presento un problema en el proyecto en que estamos trabajando, mismo que fue solucionado después de investigar y leer sobre el tema.

Problema

En el proyecto se tiene una relación Master-Detail, en esta relación es necesario agregar entidades al detalle, mismas que ya existen en la base de datos, sin embargo, es necesario validar la información antes de guardar, ya que si no cumple con las reglas de validación no se debe guardar.

En aquellos casos en los que la información no cumple, deben permitirnos repetir el proceso una vez que los datos se actualicen; pero al momento de repetirlo (aparentemente) y realizar la validación por segunda vez, resulta que el detalle que agregamos la primera vez nunca se descargó ni tampoco volvió a cargar los datos originales desde la base de datos, tal parece que existiera algún cache o que se conservan en memoria, esto provoca que se sigan agregando los mismos datos de forma repetida, o que a la información que no cumplió las reglas (que aun esta en nuestro data context), se le puedan agregar nuevos datos que se almacenaran cuando la entidad se logre grabar, siempre y cuando no haya reglas en la base de datos que estén siendo violadas por la información que no debería salvarse.

Tal parece que con eliminar los datos que no cumplieron las reglas, se solucionaría el problema, sin embargo esto tampoco puede ser, ya que a estas alturas no sabe que se tenía originalmente.

Análisis

El problema podría solucionarse si pudiéramos revertir los cambios o si pudiéramos volver a cargar la información original.

El EF lleva un seguimiento de los cambios realizados en memoria, por ese motivo cuando se recuperan de nuevo los registros, el comportamiento default del EF descarta aquellos registros que ya hayan sido cargados previamente, para evitar que los cambios hasta el momento realizados, se pudieran perder; este mecanismo está basado en únicamente en las EntityKeys ( o sea los identificadores de la tabla), debido a esto, cuando se recuperan los datos, solo se verifica si los EntityKeys (id) existen, si existen, entonces la información cargada, no se modificara.

El comportamiento default es correcto, si no queremos sobre escribir los cambios hechos; pero, que pasa si queremos sobre escribirlos?

Solución

Para sobre escribir los cambios es necesario cambiar el comportamiento del objectContext. Sin embargo esto debe realizarse con mucho cuidado, ya que si no lo tenemos en cuanta, esto podría afectar a toda la aplicación.

Para no afectar a toda la aplicación, lo recomendable es que se modifique el comportamiento del objectContext, únicamente en donde se requiera.

La actualización puedes llevarse a cabo usando dos posibles modos:

ClientWins: Los cambios hechos, se conservan hasta que se llame Save.
StoreWins: Los cambios son sustituidos por la información del almacén de datos.

Nuestra solución fue, agregar un nuevo método a nuestro repositorio. Este método realiza una actualización de la información, solo que establece el modo a StoreWins.

El código del método es:

Como se debe usar

En este ejemplo, se obtiene una entidad solicitud existente en la base de datos. El valor del cupón almacenado es 456, se modifica a 325, al llamar el nuevo método Refresh, se restaura el valor del cupón al original, que era 456.
Este post se realizo con la colaboración de un integrante del equipo de trabajo, Julio Ávila. Gracias.