miércoles, 24 de septiembre de 2014

Apis, construyendo una nueva era

Hola amigos, les quiero compartir la edición número 45 de la revista Software Gurú, en la cual tuve la oportunidad de escribir un artículo acerca de la era de las Apis, espero sea de su interés y agradezco la invitación por parte de la revista para contribuir en esta edición.

domingo, 24 de agosto de 2014

[Patrones] Implementando patrón repositorio - Repository pattern en C# Parte III

En el artículo anterior creamos la estructura para nuestros repositorios y creamos el repositorio para acceso a la base de datos en Sql Server a través de Entity Framework Code First, ahora observaremos como crear los repositorios para acceder a los artículos almacenados en MongoDB y también para obtener los datos de contacto de los empleados que nos proveerá una API en Asp.Net Web Api.

Para iniciar veamos cómo quedará la estructura de nuestro repositorio de MongoDB para cuando lo hayamos terminado:


Como podemos ver tiene la misma estructura que nuestro repositorio de Sql Server del artículo anterior, a diferencia que en este repo utilizamos la entidad Articulo podría ser Empleado, DatosContacto o cualquier otra y también tenemos un repositorio base, el cual nos ayudara a realizar operaciones comunes con la base de datos de Mongo, como por ejemplo, conectarse al servidor, obtener la base de datos, obtener una colección en específico y hacer operaciones sobre esta colección, si quieres ver una introducción sobre MongoDB te invito a que leas este artículo que tengo al respecto.

Ahora observemos el código de nuestro repositorio base para MongoDB

    public class BaseRepository<T> where T : class
    {
        private readonly string _nombreColeccion;
        private MongoDatabase database;
 
        public BaseRepository(string nombreColeccion)
        {
            _nombreColeccion = nombreColeccion;
        }
 
        public void ConectarDb()
        {
            const string connectionString = "mongodb://localhost";
            var client = new MongoClient(connectionString);
            MongoServer server = client.GetServer();
            database = server.GetDatabase("RepositoryPatternDemo");
        }
 
        public void Insertar(T entidad)
        {
            var coleccion = database.GetCollection<T>(_nombreColeccion);
            coleccion.Insert(entidad);
        }
 
        public IQueryable<T> ObtenerTodos()
        {
            var coleccion = database.GetCollection<T>(_nombreColeccion);
            return coleccion.FindAll().AsQueryable();
        }
    }

Nuestro repo base nos permite conectarnos a una base de datos MongoDB  usando el string de conexión y base de datos que vemos en el código esto debería estar en un archivo de configuración, pero para este ejemplo no tiene mucha importancia adicional nos permite insertar un nuevo documento en cualquier colección y nos permite obtener todos los documentos de la base de datos. Es un repositorio base bastante simple al cual le podríamos agregar muchas más operaciones.

Ahora veamos la entidad Artículo la cual se almacena directamente en MongoDB como un documento de tipo Json:

    public class Articulo
    {
        public ObjectId Id { getset; }
 
        public string Titulo { getset; }
 
        public string ContenidoHtml { getset; }
 
        public List<string> Etiquetas { getset; }
 
        public string IdEmpleado { getset; }
    }

Como podemos ver tenemos una propiedad de tipo ObjectId, el cual se generará al guardar el documento en MongoDB, recordemos que todos los documentos en Mongo deben tener este ObjectId por lo tanto aquí lo tenemos en esta entidad y recordemos también que esta entidad será mapeado por Automapper a nuestra entidad de dominio Articulo que es la que en realidad van a conocer los clientes que usen este repositorio.

Y para finalizar con el repositorio de MongoDB observemos el repo específico:

    public class ArticuloRepository : BaseRepository<Articulo>IArticuloRepository
    {
        public ArticuloRepository(string nombreColeccion = "Articulos")
            : base(nombreColeccion)
        {
        }
 
        public List<Dominio.Articulo> ObtenerArticulos()
        {
            AutoMapper.Mapper.CreateMap<Articulo, Dominio.Articulo>();
 
            ConectarDb();
            return new List<Dominio.Articulo>(ObtenerTodos().Select(c =>
                AutoMapper.Mapper.Map<Dominio.Articulo>(c)
                ));
        }
 
        public void GuardarArticulo(Dominio.Articulo articulo)
        {
            AutoMapper.Mapper.CreateMap<Dominio.ArticuloArticulo>();
            var art = AutoMapper.Mapper.Map<Articulo>(articulo);
 
            ConectarDb();
            Insertar(art);
        }
    }

Como podemos observar es un repo bastante sencillo con tan solo dos operaciones, podríamos implementar las que fueran necesarias, y podemos ver que se trabaja de igual forma que el repo de Sql Server del artículo anterior usando automapper para mapear la entidad usada por el repo a la entidad de dominio en este caso la entidad de dominio Articulo.

Y para finalizar el artículo implementaremos el último repositorio del ejemplo, el cual nos permite obtener los datos de contacto de un empleado a través de un servicio Asp.net Web Api. Si quieres obtener más información acerca de Web Api, te invito a visitar el blog de mi amigo y Crack Hernan Guzman.

En este repo usaremos directamente la entidad de dominio DatosContacto, por lo que no necesitaremos del uso de automapper, y tendremos como siempre un repositorio base el cual encapsulará la conexión a nuestra Api y tendremos un repo específico que heredará del repo base. Ahora veamos como es el código del repositorio base:

    public class BaseRepository<T> where T : class 
    {
        public string UrlApi { getset; }
 
        public T ObtenerPorId(string id)
        {
            var client = new HttpClient { BaseAddress = new Uri("http://localhost:38417/") };
 
            client.DefaultRequestHeaders.Accept.Add(
                new MediaTypeWithQualityHeaderValue("application/json"));
 
            HttpResponseMessage response = client.GetAsync(string.Format("api/DatosContacto/{0}", id)).Result;
 
            if (response.IsSuccessStatusCode)
            {
                var datosContacto = response.Content.ReadAsStringAsync();
                return JsonConvert.DeserializeObject<T>(datosContacto.Result);
            }
            else
            {
                return null;
            }
        }
    }

Nuestro repositorio base se encarga de consumir el servicio Web Api, enviando el id del empleado para obtener en formato Json su información de contacto, posteriormente deserializa los datos de contacto en la entidad de dominio DatosContacto y la retorna. (El código de ejemplo del Api lo puedes encontrar en el repositorio en GitHub correspondiente a esta serie de artículos).

Ahora para finalizar observemos como es el código de nuestro repositorio específico para DatosContacto:

    public class DatosContactoRepository : BaseRepository<Dominio.DatosContacto>IDatosContactoRepository
    {
        public Dominio.DatosContacto ObtenerDatosContactoEmpleado(string idEmpleado)
        {
            return ObtenerPorId(idEmpleado);
        }
    }

Es bastante simple, dado que solo tiene una operación.

Y bueno eso es todo por este artículo, en el cual implementamos los repositorios para acceso a MongoDB y para acceso a Web Api, en el próximo artículo terminaremos esta pequeña serie sobre el patrón repositorio o repositoy pattern observando como consumir los repositorios que hemos creado desde algún cliente, como por ejemplo una aplicación Asp.Net Mvc. Espero sea de utilidad y de interés para ustedes.

Este ejemplo lo puedes descargar de mi repositorio en GitHub

Saludos, y buena suerte!

miércoles, 13 de agosto de 2014

[Patrones] Implementando patrón repositorio - Repository pattern en C# Parte II

En el artículo anterior conocimos y explicamos el patrón repositorio, vimos su propósito, su estructura, algunos casos comunes de uso, adicional creamos la estructura base en una solución de visual estudio, la cual seguiremos desarrollando a lo largo de este artículo y nos centraremos en la implementación de nuestros repositorios, recordemos que vamos a tener un repo para SqlServer, otro para MongoDB y otro para un Api "externa". Recordemos como va hasta el momento nuestra solución y nos enfocaremos en la parte señalada en rojo:


Para iniciar en el proyecto de Contrato vamos a crear las interfaces para cada repositorio, que definirán el contrato a implementar por los repositorios que vamos a crear o nuevos repos que puedan surgir en el futuro y que usen nuestras entidades de dominio Empleado, Artículo y DatosContacto, veamos entonces como quedan dichas interfaces:

    public interface IEmpleadoRepository
    {
        List<Empleado> ObtenerEmpleados();
 
        Empleado ObtenEmpleadoPoId(string id);
 
        void GuardarEmpleado(Empleado empleado);
    }

    public interface IArticuloRepository
    {
        List<Articulo> ObtenerArticulos();
 
        Articulo ObtenArticuloPorId(string id);
 
        ICollection<Articulo> ObtenerArticulosPorIdEmpleado(string idEmpleado);
 
        void GuardarArticulo(Articulo articulo);
    }

    public interface IDatosContactoRepository
    {
        DatosContacto ObtenerDatosContactoEmpleado(string idEmpleado);
    }

Ahora procedemos a crear el repositorio para SqlServer, para esto agregamos la siguiente estructura en el proyecto SqlRepository:


Como podemos ver tenemos una clase llamada Contexto, la que representará nuestro contexto de Entity Framework para interactuar con nuestra base de datos en Sql Server, en esta ocasión usaremos el enfoque de EF llamado Code First, si quieres profundizar más sobre este tema, te invito a leer esta serie de post relacionados. Adicional en la raíz del proyecto también tenemos una clase llamada BaseRepository, la cual contiene todas las operaciones básicas que pueden aplicar para cualquier entidad que se tenga que interactúe con la base de datos. Vamos a ver el código de estas dos clases que menciono:

    public partial class Contexto : DbContext
    {
        public Contexto()
            : base("name=Contexto")
        {
        }
 
        public virtual DbSet<Empleado.Empleado> Empleados { getset; }
 
        protected override void OnModelCreating(DbModelBuilder modelBuilder)
        {
            modelBuilder.Entity<Empleado.Empleado>()
                .Property(e => e.Id)
                .IsUnicode(false);
 
            modelBuilder.Entity<Empleado.Empleado>()
                .Property(e => e.Nombre)
                .IsUnicode(false);
 
            modelBuilder.Entity<Empleado.Empleado>()
                .Property(e => e.Telefono)
                .IsUnicode(false);
        }
    }

Tenemos el mapeo a la base de datos de la tabla Empleados, y tenemos algunas configuraciones a través de Fluent Api para esta.

    public class BaseRepository<T> where T : class
    {
        protected DbContext Contexto = new Contexto();
        protected DbSet<T> DbSet;
 
        public BaseRepository()
        {
            DbSet = Contexto.Set<T>();
        }
 
        public void Insertar(T entidad)
        {
            DbSet.Add(entidad);
        }
 
        public void Eliminar(T entidad)
        {
            DbSet.Remove(entidad);
        }
 
        public IQueryable<T> Filtrar(Expression<Func<T, bool>> expresion)
        {
            return DbSet.Where(expresion);
        }
 
        public T ObtenerPorId(string id)
        {
            return DbSet.Find(id);
        }
 
        public IQueryable<T> ObtenerTodos()
        {
            return DbSet;
        }
 
        public void GuardarCambios()
        {
            Contexto.SaveChanges();
        }
    }

Como mencioné antes nuestro repositorio base para Sql Server, nos permite usarlo con cualquier entidad de Code First y realizar algunas operaciones básicas como obtener todos los registros, obtener filtrando por id, realizar una consulta filtrada, insertar y eliminar.

Ahora vamos a observar las entidades que tenemos al interior de la carpeta Empleado, que son Empleado y EmpladoRepository. La clase empleado se encarga de mapear la tabla Empleados de la base de datos y EmpleadoRepository es el repositorio específico para realizar operaciones con la tabla Empleados y hereda de nuestro repositorio base para implementar las operaciones que este expone.

    [Table("Empleados")]
    public partial class Empleado
    {
        [StringLength(50)]
        public string Id { getset; }
 
        [Required]
        [StringLength(50)]
        public string Nombre { getset; }
 
        [StringLength(10)]
        public string Telefono { getset; }
 
        [StringLength(50)]
        public string Direccion { getset; }
    }

Tenemos el mapeo de la tabla Empleados en nuestra base de datos y su configuración a través de Data Anottations.

    public class EmpleadoRepository : BaseRepository<Empleado>IEmpleadoRepository
    {
        public List<Dominio.Empleado> ObtenerEmpleados()
        {
            AutoMapper.Mapper.CreateMap<Empleado, Dominio.Empleado>();
            return
                new List<Dominio.Empleado>(ObtenerTodos().AsEnumerable().Select(AutoMapper.Mapper.Map<Dominio.Empleado>
                    )).ToList();
        }
 
        public Dominio.Empleado ObtenEmpleadoPoId(string id)
        {
            var empleado = ObtenerPorId(id);
 
            AutoMapper.Mapper.CreateMap<Empleado, Dominio.Empleado>();
            return AutoMapper.Mapper.Map<Dominio.Empleado>(empleado);
        }
 
        public void GuardarEmpleado(Dominio.Empleado empleado)
        {
            AutoMapper.Mapper.CreateMap<Dominio.EmpleadoEmpleado>();
            var emple = AutoMapper.Mapper.Map<Empleado>(empleado);
 
            Insertar(emple);
        }
    }

Como podemos ver, el EmpleadoRepository hereda de BaseRepository usando la entidad Empleado para realizar las operaciones, adicional implementa la interfaz IEmpleadoRepository, que define el contrato a implementar para este repositorio. En este repositorio tenemos tres métodos, ObtenerEmpelados(), ObtenerEmpleadoPorId() y GuardarEmpleado() los cuales usan métodos del repositorio base respectivamente.

Por último algo curioso en este repositorio es el uso del AutoMapper, que es una herramienta que nos permite mapear dos objetos que pueden tener una estructura diferente pero contener todos o algunos datos iguales. En este caso lo usamos para mapear la entidad Empleados de CodeFirst a nuestra entidad de domino Empleado, que recordemos se encuentra en el proyecto de dominio, y es la entidad devuelta por el repositorio y usada por los clientes que consuman el repo, esto con el fin de que todos los clientes "hablen" en términos del domino y todo quede centralizado en estas entidades. Si quieres profundizar más acerca del tema AutoMapper puedes observar este artículo del crack JulitoGTU.

Ahora ya tenemos listo el repositorio para interactuar con la base de datos Sql Server, es decir tenemos centralizada toda la lógica de acceso a datos en el repo, ahora podríamos consumir el repo a través de algún cliente (Aplicación web, escritorio, consola, etc.) para interactuar con la base de datos y estos no sabrían sobre la proveniencia de los datos.

Y bueno eso es todo por este artículo, en el cual implementamos el contrato de los repositorios y el repositorio especifico para acceso a datos de Sql Server usando Entity Framework Code First, en el próximo artículo terminaremos los repositorios, implementando el repo para acceso a datos en MongoDB y también para obtener información del servicio web api. Espero sea de utilidad y de interés para ustedes.

Continua en: Implementando patrón repositorio - Repository pattern en C# Parte III

Este ejemplo lo puedes descargar de mi repositorio en GitHub

Saludos, y buena suerte!

lunes, 4 de agosto de 2014

[Patrones] Implementando patrón repositorio - Repository pattern en C# Parte I

El patrón repositorio o repository pattern está íntimamente relacionado con el acceso a datos y nos permite tener una abstracción de la implementación de acceso a datos en nuestras aplicaciones, de modo que nuestra lógica de negocio no conozca ni esté acoplada a la fuente de datos. En pocas palabras esto quiere decir que el repositorio actúa como un intermediario entre nuestra lógica de negocio y nuestra lógica de acceso a datos para que se centralice en un solo punto, y de esta forma se logre evitar redundancia de código. Y como dije antes al ser una abstracción del acceso a datos nos permite desacoplar y testear de una forma más sencilla nuestro código, ya que al estar desacoplado podemos generar pruebas unitarias con mayor facilidad. Adicional al estar centralizado en un solo punto de acceso, podemos reutilizar nuestra lógica de acceso a datos desde cualquier cliente, es decir desde otras aplicaciones que tengamos en nuestro entorno corporativo, incluso desde una app móvil si exponemos los repositorios a través de Apis por ejemplo.

Uno de los escenarios donde más se suele usar el patrón repositorio, es cuando tenemos múltiples fuentes de datos. Por ejemplo obtenemos gran parte de la información de una base de datos relacional Sql Server, obtenemos otros datos desde un servicio web y obtenemos otros desde una base de datos No Sql por ejemplo. en este contexto el patrón repositorio nos ayudara a centralizar el acceso a cada una de estas fuentes de datos para que nuestros aplicativos cliente no tengan que lidiar con este engorroso trabajo.

Ahora veamos cual la estructura del patrón para comprenderlo mucho mejor:

Imagen tomada de: http://msdn.microsoft.com/en-us/library/ff649690.aspx

Como podemos observar en la imagen, la lógica de negocio de nuestro cliente no interactúa directamente con la fuente de datos, ya que con este patrón la lógica de negocio es totalmente agnóstica a los datos, es decir no sabe de dónde provienen ni como se obtuvieron. Y también podemos apreciar que se comunica directamente con el repositorio el cual se encarga de hacer los mapeos necesarios y comunicarse con la fuente de datos.

Ahora veamos cómo sería la estructura si utilizamos múltiples fuentes de datos en nuestra aplicación:

Imagen tomada de Pluralsight.

Como vemos el concepto es el mismo, solo que ahora tenemos tres fuentes de datos, y podemos obtener diferentes datos de cada una de ellas, por ejemplo los empleados se obtienen y se gestionan a través de un web service, los productos en una base de datos relacional y los clientes en un archivo o grupo de archivos, también podríamos tener por ejemplo una base de datos No Sql u otro tipo de repositorio de datos. Esto recibe el nombre de persistencia poliglota y es cuando como en este caso usamos múltiples fuentes de datos, y sin lugar a dudas el patrón de repositorio nos facilita el manejo de esto, encapsulando toda la lógica que esto implica y exponiendo a la lógica de negocio de nuestros clientes los datos de tal forma que no se den por enterados de dónde provienen y no tengan que preguntar por el tipo de fuente de datos a la que desean acceder.

Y ahora que conocemos mejor el patrón, su estructura y sabemos en qué escenarios es útil usarlo vamos a ver cómo es su implementación en C#, creando una estructura de repositorios que nos permitan conectarnos a tres fuentes de datos, más exactamente Sql server a través de Entity Framework, MongoDB y una Api web, que nos exponen la información de empleados, artículos escritos por los empleados y sus datos de contacto de redes sociales, respectivamente.

Nuestra solución en Visual Studio tendrá la siguiente estructura:


En nuestro proyecto de dominio tendremos las clases Empleado.cs, Articulo.cs y DatosContacto.cs, que representarán nuestras entidades de dominio. Al interior de la carpeta Repositorios, tendremos un proyecto de repositorio para cada fuente de datos, ya que cada uno se manejará diferente, adicional un proyecto que contendrá el contrato o interfaces que se deberán usar para cada entidad de dominio. Y por último tendremos en la carpeta cliente web, un proyecto para las reglas de negocio especificas del proyecto web y un proyecto web MVC.

Veamos entonces como queda el código de nuestras tres entidades de dominio:

    public class Articulo
    {
        public string Id { getset; }
 
        public string Titulo { getset; }
 
        public string ContenidoHtml { getset; }
 
        public List<string> Etiquetas { getset; }
    }

    public class Empleado
    {
        public string Id { getset; }
 
        public string Nombre { getset; }
 
        public string Telefono { getset; }
 
        public string Direccion { getset; }
 
        public List<Articulo> Articulos { getset; }
 
        public DatosContacto DatosContacto { getset; }
    }

    public class DatosContacto
    {
        public string SitioWeb { getset; }
 
        public string FaceBook { getset; }
 
        public string Twitter { getset; }
 
        public string LinkedIn { getset; }
    }

Hasta el momento tenemos, la estructura base de nuestro proyecto y tenemos completo nuestro proyecto de dominio, en la segunda parte de este artículo veremos cómo construir cada uno de los repositorios para las diferentes fuentes de datos.

Bueno amigos eso es todo de esta primera parte del patrón de diseño repositorio o repository pattern, espero sea de utilidad y de interés para ustedes.

Continua en: Implementando patrón repositorio - Repository pattern en C# Parte II

Este ejemplo lo puedes descargar de mi repositorio en GitHub

Saludos, y buena suerte!

lunes, 14 de julio de 2014

[Patrones] Implementando patrón fachada - Facade pattern en C#

El patrón fachada nos permite disminuir la complejidad de un sistema, a través de la división de este en subsistemas, y adicional permite reducir la dependencia de un cliente con respecto a determinado componente. es decir, si tenemos una cantidad de operaciones que suelen ser complicadas, por ejemplo para hacer algo con un "Empleado", podríamos crear una fachada de empleado que nos permita consumir estas operaciones de una forma más simple y adicional centralice el acceso a estas operaciones, de esta forma cualquier cliente podría realizarlas sin tener que entrar en detalle de las operaciones complejas correspondientes a "Empleado" y además no tendría una dependencia directa con las implementaciones concretas de "Empleado" si no con la fachada, de modo que si algo cambia en estas implementaciones concretas, basta con modificar la fachada y los demás clientes no se darían por enterados.

Ahora veamos cómo es la estructura de este patrón y analicémoslo un poco antes de implementarlo en C#:

Imagen tomada de Wikipedia de (http://es.wikipedia.org/wiki/Facade_(patr%C3%B3n_de_dise%C3%B1o))

Como vemos en el diagrama, tenemos tres módulos A, B y C, los cuales tienen responsabilidades diferentes y estos interactúan entre sí para completar algunas de sus operaciones, y también vemos que el componente facade o fachada, usa estos tres módulos para exponer una funcionalidad que los involucra, quiere decir que un cliente que es otro componente que no vemos en el diagrama, accede a la fachada y no lo hace directamente a cada uno de los tres módulos que tenemos. Entonces la fachada es la encargada de operar con la complejidad que pueda tener cada uno de estos módulos y lo expone de una manera mucho más sencilla y entendible a un cliente que pueda necesitarlo, adicional la fachada nos permite desacoplar nuestros clientes de implementaciones concretas como las que tenemos en cada módulo, y de cambiar alguno de ellos, el cambio afectaría solo a la fachada y nuestros clientes no se darían cuenta de ello.

Ahora que conocemos el propósito de este patrón y sabemos cuál es su estructura, vamos a ver cómo es su implementación en Microsoft .Net usando C#, para esto nos vamos a plantear el siguiente escenario de aplicación:

En un sistema tenemos tres módulos que son, Nómina, Incentivos y Subsidios. Dichos módulos realizan operaciones que pueden ser complejas y críticas para un negocio, ya que operan en diferentes frentes relacionados con los empleados de una compañía, sin embargo, existen varias aplicaciones y existirán muchas más que necesiten usar funcionalidades de estos módulos y estas deben lograrlo de una manera sencilla y fácil de usar, sin tener que entrar en detalle de cada una de las reglas de negocio de cada módulo.

Para esto vamos a crear una solución en Visual Studio con los siguientes proyectos, que explicaré a continuación:


Los proyectos Beneficios, Incentivos y Nomina, son los tres módulos que tenemos en nuestra aplicación y son los que corresponden en el diagrama a ModuleA, ModuleB y ModuleC respectivamente, y es allí donde tenemos bastantes reglas de negocio y operaciones complejas, que queremos exponer de una forma mucho más simple.

El en proyecto Domino se encuentran nuestras entidades de dominio, es decir las entidades que son relevantes para el negocio, y las cuales transportaremos entre los diferentes proyecto para hablar en un mismo término de negocio, adicional estas entidades podrían estar mapeadas a nuestra base de datos por ejemplo.un de estas entidades es la entidad Empleado.

En el proyecto de fachada para nuestro ejemplo tenemos una sola clase llamada EmpleadoFacade la cual recibe ese nombre para efectos de este ejemplo, y es quien realiza el llamado a nuestros tres módulos nombrados anteriormente.

Y por último tenemos el proyecto ClienteFacturacion que es una aplicación dedicada al área de facturación, y que requiere el uso de las operaciones complejas de cada empleado, y como esta aplicación pueden existir muchas más que la necesiten, por esto consume todas las operaciones a través de la fachada.

Ahora veamos cómo es la implementación de cada uno de estos componentes:

Módulo de Nómina:

    public class Nomina
    {
        public double ObtenerSalarioEmpleado(string idEmpleado)
        {
            // Simulamos los empleados de la compañía
            var empleados = new List<Empleado>()
            {
                new Empleado() {Id = "1", Nombre = "Empleado 1", Salario = 1500000},
                new Empleado() {Id = "2", Nombre = "Empleado 2", Salario = 2000000},
                new Empleado() {Id = "3", Nombre = "Empleado 3", Salario = 3000000},
                new Empleado() {Id = "4", Nombre = "Empleado 4", Salario = 4000000},
            };
 
            // ... Operaciones complejas y calculos del negocio.
 
            return empleados.First(c => c.Id.Equals(idEmpleado)).Salario;
        }
    }

Módulo de Beneficios:

    public class Beneficio
    {
        public List<dominio.Beneficio> ObtenerrBeneficiosEmpleado(string idEmpleado)
        {
            // ... Buscar beneficios del empleado en particular.
 
            // ... Calculos para determinar si el empleado tiene un beneficio o no.
 
            return new List<dominio.Beneficio>()
            {
                new dominio.Beneficio {Nombre = "Prima extralegal 1", Valor = 2000000},
                new dominio.Beneficio {Nombre = "Prima extralegal 2", Valor = 1000000},
                new dominio.Beneficio {Nombre = "Subsidio para hijos", Valor = 500000}
            };
        }
    }

Módulo de Incentivos:

    public class Incentivo
    {
        public List<dominio.Incentivo> ObtenerIncentivosEmpleado(string idEmpleado)
        {
            // ... Buscar incentivos otorgados al empleado con reglas de negocio.
 
            return new List<dominio.Incentivo>()
            {
                new dominio.Incentivo {Concepto = "Bono por cumplimiento", Valor = 200000},
                new dominio.Incentivo {Concepto = "Bono por felicitaciones del cliente", Valor = 200000}
            };
        }
    }

Estos son nuestros módulos con implementaciones concretas, ahora veamos como la fachada usa cada uno de ellos y expone su funcionalidad con una interfaz mucho más simple:

    public class EmpleadoFacade
    {
        public double ObtenerTotalIngresosEmpleado(string idEmpleado)
        {
            var nomina = new Nomina.Nomina();
            var beneficio = new Beneficio();
            var incentivo = new Incentivo();
 
            var salario = nomina.ObtenerSalarioEmpleado(idEmpleado);
            var totalBeneficios = beneficio.ObtenerrBeneficiosEmpleado(idEmpleado).Sum(c => c.Valor);
            var totalIncentivos = incentivo.ObtenerIncentivosEmpleado(idEmpleado).Sum(c => c.Valor);
 
            return salario + totalBeneficios + totalIncentivos;
        }
    }

Como vemos nuestra fachada nos permite obtener los ingresos totales de un empleado en específico, invocando cada uno de nuestros módulos y operando con cada uno de ellos, con el fin de exponer de una manera mucho más fácil la información.

Y por último veamos cómo, nuestro cliente de facturación, en nuestro caso una aplicación de consola hace uso de la fachada:

    class Program
    {
        static void Main(string[] args)
        {
            Console.Write("Digite la identificación del empleado para obtener su total de ingresos ...");
            var idEmpleado = Console.ReadLine();
 
            var empleadoFacade = new EmpleadoFacade();
            var salario = empleadoFacade.ObtenerTotalIngresosEmpleado(idEmpleado);
            Console.Write("Los ingresos totales del empleado con identificación {0}, son: {1}", idEmpleado, salario);
            Console.ReadLine();
        }
    }

Como podemos ver este cliente logra acceder a la información de una forma muy simple, y si por algún motivo las reglas de negocio cambian, con respecto a la nómina, beneficios, incentivos, o se crea un nuevo módulo, nuestros clientes no sufrirán impacto, y solo tendremos que modificar nuestra fachada.

Bueno amigos eso es todo de esta muestra acerca del patrón de diseño fachada o Facade pattern, espero sea de utilidad y de interés para ustedes.

Este ejemplo lo puedes descargar de mi repositorio en GitHub

Saludos, y buena suerte!

lunes, 30 de junio de 2014

[Patrones] Implementando Patrón adaptador - Adapter Pattern en C#

El patrón adaptador nos permite convertir o transformar una interface existente en otra interface esperada por un cliente, para realizar determinada operación, es decir en muchas ocasiones necesitamos hacer alguna operación desde nuestras aplicaciones (cliente), y en muchos casos ya tenemos esta operación implementada en una librería de clases por ejemplo. Pero también nos podemos encontrar que la interface que usa nuestro cliente no sea compatible con la interface que usa este componente genérico que tenemos. Es allí donde cobra importancia el patrón adaptador o adapter pattern, el cual nos permite a través de un componente intermedio entre las dos interfaces lograr que sean compatibles y lograr reutilizar nuestro código sin necesidad de repetirlo o acoplarlo fuertemente a alguna implementación en específico.

Veamos para comprender mejor en primera instancia el ejemplo más usado de este patrón con una imagen de la vida real:


Ahora veamos cómo sería el diagrama de clases de este patrón y analicémoslo un poco antes de implementarlo en C#:

Imagen tomada de Wikipedia (http://es.wikipedia.org/wiki/Adapter_(patr%C3%B3n_de_dise%C3%B1o))

Sin lugar a duda comprender en primera instancia un patrón de diseño suele ser algo complejo, por eso vamos a describir los diferentes componentes que vemos en el diagrama.

Target: Es una interface, la cual usa el cliente en el cual se quiere reutilizar el componente genérico que tenemos (Adaptee), es allí donde radica el problema que soluciona el patrón adaptador, ya que Target es diferente de la interface usada por el componente genérico que tenemos (Adaptee).

Adaptee: Es el componente genérico que tenemos, en el cual tenemos implementada cierta funcionalidad que queremos reutilizar desde nuestro cliente, al ser un componente genérico y pensado en cierta ocasión para algún escenario su interface es incompatible con Target, es decir la firma de su método puede retornar un valor diferente y recibir parámetros diferentes, es por esto que son incompatibles.

Adapter: Es nuestro adaptador o también conocido como Wrapper, el cual nos permite convertir en compatibles estas dos interfaces que son incompatibles por naturaleza, y como vemos en el diagrama, Adapter es una clase que hereda de Adaptee y que implementa la interface Target, de este modo puede cumplir con el contrato esperado por el cliente y a su vez utilizar la implementación existente en Adaptee.

Y tenemos un componente más que no se encuentra en el diagrama que es el Cliente, y es la aplicación u otro componente, desde la cual deseamos reutilizar la funcionalidad que tenemos en nuestro Adaptee, es por esto que anteriormente nos referimos mucho al cliente.

Ahora que conocemos bien que hace cada componente, comprendemos que nuestro Adapter invocará nuestro Adaptee y operará de modo que cumpla con el contrato esperado por nuestro cliente, es decir Target.

Probablemente lo primero que se nos venga a la cabeza es: ¿Y por qué no crear otro componente basado en el existente copiando el código que ya tengo? ó ¿por qué no envío un parámetro adicional a mi Adaptee de modo que pueda indicar cómo comportarse dependiendo del cliente que lo invoca? ó ¿Por qué no creo una sobrecarga de mi método en el Adaptee que si cumpla con el contrato esperado por mi nuevo cliente?

Pues bueno, la verdad es posible resolver el problema planteado a través de las alternativas anteriores, pero si nos detenemos a pensar, no estaríamos reutilizando componentes si no copiando y pegando, es decir replicando código que ya tenemos, también estaríamos acoplando fuertemente nuestro componente "genérico" a implementaciones concretas, o estaríamos modificando el comportamiento de nuestro componente creado inicialmente, lo cual iría en contra del principio solid "Open / Close" que nos indica que nuestro componente debería estar abierto a ser extendido y debería estar cerrado a ser modificado.

Es por esto que el patrón adaptador nos permite una solución, que sea desacoplada y que permita hacer extensible nuestro componente, sin tener que modificarlo directamente, y nos permite hacer múltiples adaptaciones de un componente para diferentes requerimientos de nuevos clientes.

Y bueno después de comprender el propósito y aplicación de este patrón, que en mi opinión es lo más complejo e importante, ahora vamos a ver como lo podemos implementar a través del lenguaje C#, aplicándolo en el siguiente escenario:

En nuestro ejemplo vamos a hacer una adaptación de un componente que nos permite guardar un error en archivo txt este es nuestro Adaptee, el cual en un principio solo fue pensado para esto. Pero lo deseamos reutilizar en otra aplicación que requiere otro comportamiento diferente.

    public class HelperLog
    {
        public void GuardarError(Exception ex)
        {
            using (var w = File.AppendText("log.txt"))
            {
                w.Write("\r\nLog Entry : ");
                w.WriteLine("{0} {1}"DateTime.Now.ToLongTimeString(), DateTime.Now.ToLongDateString());
                w.WriteLine("  :");
                w.WriteLine("  :{0}", ex.Message);
                w.WriteLine("-------------------------------");
                w.Write("\r\nError StackTrace : {0}", ex.StackTrace);
            }
        }
    }

Como vemos, en esta firma recibimos una excepción, la almacenamos en el archivo de log y no retornamos ningún valor, pero para nuestra nueva aplicación se requiere que se envíe solo el mensaje de error y un código de error personalizado, con el cual se obtendrá un mensaje amigable para el usuario de un archivo Xml y por último se le mostrará al mismo. Por lo tanto requerimos de un adaptador que nos ayude a reutilizar este componente volviendo compatibles las interfaces. Ahora veamos la interface que se requiere.

    public interface IClienteLog
    {
        string GuardarErrorLog(string error, string codigoError);
    }

Como vemos tenemos incompatibilidad, y es allí donde entra a jugar nuestro adaptador, el cual debe heredar de nuestra clase HelperLog e implementar nuestra interface IClienteLog.

    public class LogAdapter : HelperLogIClienteLog
    {
 
        public string GuardarErrorLog(string error, string codigoError)
        {
            GuardarError(new Exception(error));
 
            // Se obtiene el mensaje amigable de error basado en su código
            var root = XElement.Load("Mensajes.xml");
 
            return (from c in root.Elements("Mensaje")
                   where (string)c.Attribute("codigo"== codigoError
                   select c.Value).First();
        }
    }

Como vemos reutilizamos nuestro helper de log, y a la vez cumplimos con el contrato que requiere nuestro nuevo cliente, observemos como lo usamos desde una aplicación de consola por ejemplo:

    class Program
    {
        static void Main(string[] args)
        {
            IClienteLog clienteLog = new LogAdapter();
 
            try
            {
                Console.Write("Digite el número a convertir...");
                var cadena = Console.ReadLine();
                var numero = Convert.ToInt16(cadena);
            }
            catch (Exception ex)
            {
                Console.Write(clienteLog.GuardarErrorLog(ex.Message, "2"));
                Console.ReadLine();
            }
        }
    }

En este escenario utilizamos el la adaptación del helper log, para almacenar un error que corresponde a un error de conversión de tipos, el parámetro "2" corresponde al mensaje de este error en el xml, como podrás ver en la solución de código fuente que indico al final.

Bueno amigos eso es todo de esta muestra acerca del patrón de diseño adaptador o Adapter pattern, espero sea de utilidad y de interés para ustedes.

Este ejemplo lo puedes descargar de mi repositorio en GitHub



Saludos, y buena suerte!

martes, 17 de junio de 2014

¿Qué hay de los patrones de diseño?

En muchas ocasiones hemos escuchado hablar acerca de los famosos patrones de diseño, escuchamos que nos facilitan la vida al desarrollar o al plantear una arquitectura de software. Escuchamos que son soluciones probadas y certificadas a problemas comunes y conocidos en el desarrollo de software, y la verdad aunque escuchamos mucho acerca de ellos y los utilizamos a diario (Aunque a veces no nos demos cuenta) en ocasiones pasamos por alto la importancia que tienen. En mi opinión los patrones de diseño hacen parte de las buenas prácticas que garantizan resolver un problema de una manera óptima y además de eso de una manera que ya se sabe que funciona correctamente. Ahora no quiere decir que en todos los casos de nuestros proyectos apliquen todos los patrones de diseño, o que siempre un patrón de diseño será infalible en todos los casos, pues no, recordemos que en el desarrollo de software no existen balas de plata como dicen por ahí, y que no todo recurso es efectivo para atacar o resolver todos los problemas, es allí donde es importante tener conocimiento de gran parte de los recursos con los que contamos, en este caso los patrones de diseño, para echar mano de alguno en específico en un problema determinado.

Adicional cabe destacar que como en todo, no hay que abusar de ellos, pues es bueno analizar si en un determinado caso agregamos solo complejidad innecesaria a nuestras implementaciones, dando lugar a anti patrones con los cuales lo único que lograremos es tener un gran y complejo proyecto el cual se dificulte de comprender y mantener por otros desarrolladores, que en una etapa de mantenimiento que suele ser la más costosa del ciclo de desarrollo, no queremos.

Ahora después de esta introducción tan personal, entremos un poco en materia y veamos algunos aspectos básicos e importantes de los patrones de diseño:

"Los patrones de diseño son la base para la búsqueda de soluciones a problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces.

Un patrón de diseño resulta ser una solución a un problema de diseño. Para que una solución sea considerada un patrón debe poseer ciertas características. Una de ellas es que debe haber comprobado su efectividad resolviendo problemas similares en ocasiones anteriores. Otra es que debe ser reutilizable, lo que significa que es aplicable a diferentes problemas de diseño en distintas circunstancias."


Esta, la definición de Wikipedia y el link por si quieren profundizar un poco más en el tema. Y como vemos la importancia de que un patrón compruebe que efectivamente soluciona un problema y que es reusable para múltiples escenarios que se puedan parecer. Como es el caso del patrón Iterador por ejemplo, cuyo propósito es permitir acceder secuencialmente a un grupo de objetos de una colección, y que es un patrón que usamos a diario en nuestras labores, y como mencioné anteriormente muchas veces no nos percatamos de ello, y sin contar un sin fin de patrones que son utilizados por los FrameWorks que usamos y que nos facilitan la vida.

Para terminar con este breve artículo sobre patrones de diseño, vamos a ver algunos de los patrones de diseño más conocidos y por ende más usados, y cómo estos se clasifican dependiendo de su propósito:

Patrones Creacionales:
  • Abstract Factory
  • Builder
  • Factory Method
  • Prototype
  • Singleton
Patrones estructurales:

  • Adapter
  • Bridge
  • Composite
  • Decorator
  • Proxy

Patrones de comportamiento:
  • Chain of Responsibility
  • Command
  • Iterator
  • Observer
  • Strategy
Bueno amigos eso es todo de esta introducción y opinión personal sobre los patrones de diseño, espero sea de utilidad y de interés para ustedes, en próximos artículos iniciaremos una serie de post sobre este tema, en los cuales hablaremos acerca de algunos patrones (Propósitos, ventajas, desventajas, escenarios de aplicabilidad, etc) y veremos cómo implementarlos a través del lenguaje C#.

Saludos, y buena suerte!