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

August 4, 2014, 6:41 pm

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

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

        public string Titulo { get; set; }

        public string ContenidoHtml { get; set; }

        public List<string> Etiquetas { get; set; }
    }

    public class Empleado
    {
        public string Id { get; set; }

        public string Nombre { get; set; }

        public string Telefono { get; set; }

        public string Direccion { get; set; }

        public List<Articulo> Articulos { get; set; }

        public DatosContacto DatosContacto { get; set; }
    }

    public class DatosContacto
    {
        public string SitioWeb { get; set; }

        public string FaceBook { get; set; }

        public string Twitter { get; set; }

        public string LinkedIn { get; set; }
    }

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

No olvides visitar mi página en Facebook para mantenerte actualizado de lo que pasa en el Tavo.Net https://www.facebook.com/eltavo.net
Saludos, y buena suerte!

↧

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

August 13, 2014, 8:16 pm

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

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

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

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

        [Required]
        [StringLength(50)]
        public string Nombre { get; set; }

        [StringLength(10)]
        public string Telefono { get; set; }

        [StringLength(50)]
        public string Direccion { get; set; }
    }

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.Empleado, Empleado>();
            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

No olvides visitar mi página en Facebook para mantenerte actualizado de lo que pasa en el Tavo.Net https://www.facebook.com/eltavo.net
Saludos, y buena suerte!

↧

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

August 24, 2014, 2:40 pm

≫ Next: Apis, construyendo una nueva era

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

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

        public string Titulo { get; set; }

        public string ContenidoHtml { get; set; }

        public List<string> Etiquetas { get; set; }

        public string IdEmpleado { get; set; }
    }

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.Articulo, Articulo>();
            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 { get; set; }

        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.

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

Este ejemplo lo puedes descargar de mi repositorio en GitHub

No olvides visitar mi página en Facebook para mantenerte actualizado de lo que pasa en el Tavo.Net https://www.facebook.com/eltavo.net
Saludos, y buena suerte!

↧

Apis, construyendo una nueva era

September 24, 2014, 7:23 pm

≫ Next: [Patrones] Implementando patrón repositorio - Repository pattern en C# Parte IV

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

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.

↧

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

October 20, 2014, 9:33 pm

≫ Next: [EntityFramework] Logueando e interceptando operaciones

≪ Previous: Apis, construyendo una nueva era

En el artículo anterior observamos cómo crear los repositorios para MongoDB y para Asp.Net Web Api, ahora observaremos como consumir estos repositorios que hemos creado a lo largo de esta serie desde una aplicación, en este caso usaremos una aplicación web Asp.Net MVC, desde la cual consumiremos todos los repositorios. Entonces crearemos un módulo para administrar los empleados ~~que recordemos están en una base de datos Sql Server~~, incluyendo sus datos de contacto ~~que recordemos están expuestos en un servicios Web Api~~ y un módulo para administrar los artículos escritos por estos empleados ~~que recordemos están almacenados en una base de datos documental en MongoDB.~~ Lo primero que vamos a hacer es crear un sitio Asp.Net MVC en Visual Studio, y una vez lo tengamos vamos a crear los controladores para el formulario de empleados y para el formulario de artículos, y obviamente vamos a crear sus vistas, teniendo una estructura como la siguiente:

Recordemos que nuestros controladores se comunicarán con nuestros repositorios, por lo cual los debemos referenciar a nuestro proyecto Asp.Net MVC, de esta forma vamos a utilizar todo el acceso a las diferentes fuentes de datos (Sql server, MongoDB y Web Api) y nuestra aplicación web no sabrá de donde provienen los datos y por ende estará desacoplada del acceso a datos. Visualmente tendremos un Crud bastante sencillo para los empleados y sus datos de contacto y un crud para los artículos como se aprecia en las siguientes imágenes:

Ahora veamos el código de nuestros controladores y como se comunican con los repositorios:

        private IEmpleadoRepository empleadoRepository;

        // GET: Empleado
        public ActionResult Index()
        {
            empleadoRepository = new EmpleadoRepository();
            var empleados = empleadoRepository.ObtenerEmpleados();
            return View(empleados);
        }

        // GET: Empleado/Details/5
        public ActionResult Details(string id)
        {
            empleadoRepository = new EmpleadoRepository();
            var empleado = empleadoRepository.ObtenEmpleadoPoId(id.ToString());

            var datosRepository = new DatosContactoRepository();
            empleado.DatosContacto = datosRepository.ObtenerDatosContactoEmpleado(id.ToString());

            return View(empleado);
        }

        // POST: Empleado/Create
        [HttpPost]
        public ActionResult Create(Empleado model)
        {
            try
            {
                empleadoRepository = new EmpleadoRepository();
                model.Id = DateTime.Now.Ticks.ToString();
                empleadoRepository.GuardarEmpleado(model);

                return RedirectToAction("Index");
            }
            catch
            {
                return View(model);
            }
        }

Como podemos ver, en nuestro controlador de Empleados, en la acción Index creamos una instancia de EmpleadoRepository y hacemos uso del método ObtenerEmpleados, el cual se encarga de obtener los empleados almacenados en la base de datos Sql Server, recordemos que dicho repositorio implementa una interface y adicional hereda de un repositorio base, lo cual nos brinda la oportunidad de cambiar por otra implementación concreta en caso de que sea necesario.

De esta forma nuestros repositorios nos ayudan a aislar todas las operaciones de acceso a datos, por ejemplo en este caso, obtuvimos datos de Sql Server y adicional datos de un Web Api, y nuestra aplicación Asp.Net MVC no se dio por enterada de dónde salieron los datos. Ahora observemos el controlador para interactuar con los artículos escritos por los empleados ~~que recordemos están en una base de datos No Sql como lo es MongoDB.~~

        private IArticuloRepository _articuloRepository;

        // GET: Articulo
        public ActionResult Index()
        {
            _articuloRepository = new ArticuloRepository();
            var articulos = _articuloRepository.ObtenerArticulos();
            return View(articulos);
        }

        // GET: Articulo/Create
        public ActionResult Create()
        {
            return View();
        }

        // POST: Articulo/Create
        [HttpPost]
        [ValidateInput(false)]
        public ActionResult Create(Articulo model)
        {
            try
            {
                _articuloRepository = new ArticuloRepository();
                _articuloRepository.GuardarArticulo(model);

                return RedirectToAction("Index");
            }
            catch
            {
                return View();
            }
        }

Como podemos observar, de igual forma nuestro controlador de artículos se comunica solo con nuestro repositorio y en ningún momento sabe que los datos provienen o se llevan a una base de datos MongoDB.

Y bueno amigos, con esto damos por terminada esta mini serie sobre el patrón repositorio o repository pattern, espero que sea de utilidad para ustedes.

Artículos anteriores de la serie:

Implementando patrón repositorio - Repository pattern en C# Parte III
Implementando patrón repositorio - Repository pattern en C# Parte II
Implementando patrón repositorio - Repository pattern en C# Parte I

Este ejemplo lo puedes descargar de mi repositorio en GitHub

No olvides visitar mi página en Facebook para mantenerte actualizado de lo que pasa en el Tavo.Net https://www.facebook.com/eltavo.net
Saludos, y buena suerte!

↧

[EntityFramework] Logueando e interceptando operaciones

November 14, 2014, 7:58 pm

≫ Next: Introducción a Asp.Net MVC

≪ Previous: [Patrones] Implementando patrón repositorio - Repository pattern en C# Parte IV

Hola amigos, tuve el gusto de ser invitado a participar con un par de vídeos para la campaña #100DevDays de Microsoft Visual Estudio, realizada en el Channel9 Latam, en esta ocasión expliqué un poco acerca de intercepción de operaciones en EntityFramework, aquí les dejo el vídeo:

↧

Introducción a Asp.Net MVC

November 20, 2014, 6:51 pm

≫ Next: Introducción a la arquitectura de software

≪ Previous: [EntityFramework] Logueando e interceptando operaciones

Hola amigos, hace algún tiempo dicté una charla de introducción a Asp.Net Mvc, aquí les comparto la presentación, espero sea de utilidad. Saludos!

Introducción a Asp.Net Mvc from Tavo Alzate Sandoval

↧

Introducción a la arquitectura de software

November 20, 2014, 7:00 pm

≫ Next: [EntityFramework] Usando EntityFramewok y sql Azure

≪ Previous: Introducción a Asp.Net MVC

Hola amigos, hace algún tiempo dicté una charla de introducción a la arquitectura del software, aquí les comparto la presentación, espero sea de utilidad. Saludos!

Introducción a la Arquitectura de Software from Tavo Alzate Sandoval

↧

[EntityFramework] Usando EntityFramewok y sql Azure

November 26, 2014, 7:40 pm

≫ Next: Big Data & Hadoop & HDInsight

≪ Previous: Introducción a la arquitectura de software

Hola amigos, tuve el gusto de ser invitado a participar con un par de vídeos para la campaña #100DevDays de Microsoft Visual Estudio, realizada en el Channel9 Latam, en esta ocasión expliqué como usar EntityFramework y Sql Azure, aquí les dejo el vídeo y también puedes observar el paso a paso en este artículo: EntityFramework y Sql Azure

↧

Big Data & Hadoop & HDInsight

December 7, 2014, 4:33 pm

≫ Next: Usando ExistDB (No Sql) desde .Net con C#

≪ Previous: [EntityFramework] Usando EntityFramewok y sql Azure

Hola amigos, el día de ayer 6 de diciembre de 2014, estuve en el evento CloudCamp Medellín organizado por Microsoft Colombia DX, en el cual estuve compartiendo sobre Big data en general, y acerca de una herramienta como lo es Hadoop, y obviamente compartiendo la propuesta por parte de Microsoft llamada HDInsight, la cual esta basada sobre Hadoop y nos permite tener una versión on premise y una versión en la nube, acá les dejo la presentación y espero sea de utilidad para ustedes. Saludos!

Big data, Hadoop, HDInsight from Tavo Alzate Sandoval

↧

Usando ExistDB (No Sql) desde .Net con C#

December 23, 2014, 7:29 pm

≫ Next: Microsoft MVP .Net 2015

≪ Previous: Big Data & Hadoop & HDInsight

ExistDB es una base de datos No Sql, de la familia documental, es decir es una base de datos basada en documentos, y estos documentos tienen notación Xml. A través de las bases de datos No Sql podemos llegar a suplir requerimientos de manejo de grandes volúmenes de datos sin afectar el rendimiento de nuestras aplicaciones, y pensadas para aplicaciones donde la consistencia y transaccionalidad de datos no sean la prioridad, al contrario de los sistemas de bases de datos relaciones RDBMS como Sql Server por ejemplo. Si no estás muy familiarizado con las bases de datos No Sql aquí te dejo esta presentación que te puede orientar un poco: Introducción a las bases de datos No Sql

Si quieres encontrar más información acerca de ExistDB, puedes observar su sitio oficial exist-db.org, adicional en la siguiente página toda la documentación del producto ExistDB Documentación y como no puede faltar también cuenta con una guía para desarrolladores.

Y después de esta breve introducción, ahora si vamos a ver cómo podemos guardar documentos Xml en una base de datos ExistDB desde .Net, con nuestro lenguaje preferido C#. Y este artículo surge básicamente por la falta de documentación del tema en Internet, ya que la verdad no pude encontrar ejemplos de esto y por eso les quiero compartir un ejemplo muy sencillo, de como interactuar con esta base de datos a través de unas Apis Rest que expone (de otras opciones que tiene)

var credenciales = new HttpClientHandler { Credentials = new NetworkCredential("user", "pass")};
            
using (var httpClient = new HttpClient(credenciales))
{
     var request = new HttpRequestMessage(HttpMethod.Put, string.Concat("UrlExistDB", "NombreColeccion", "nombreArchivo"))
     {
        Content = new StringContent("DocumentoXML", Encoding.UTF8, "text/xml")
     };
     var response = httpClient.SendAsync(request).Result;
     //response.Content.ReadAsStringAsync();
}

Como podemos ver es algo bastante sencillo, en donde consumimos el Api expuesta por la instalación que hicimos de ExistDB, indicamos en que colección queremos almacenar el archivo, ~~ExistDB agrupa en diferentes colecciones que creamos para almacenar los diferentes archivos xml~~ el nombre del archivo y por último enviamos el archivo xml que queremos almacenar, y todo usando un httpClient o cualquiera de las otras opciones que nos ofrece .Net para realizar este tipo de peticiones. Nótese que en esta ocasión usamos el verbo http Put, pero podríamos usar cualquier otro dependiendo de la operación que queramos realizar en la base de datos.

Cabe resaltar que el secreto está en estudiar las diferentes Apis que nos ofrece ExistDB y obviamente comprender REST, y al manejar esta filosofía es bastante eficiente el almacenamiento, lo puedo decir ya que he tenido óptimos resultados almacenando archivos xml bastante grandes.

Y bueno amigos eso es todo de este ejemplo de cómo interactuar con ExistDB desde .Net usando el lenguaje C#, espero sea de utilidad. saludos y buena suerte!

↧

Microsoft MVP .Net 2015

January 15, 2015, 8:10 pm

≫ Next: !Apunte semanal - Utilizar nombres de variables con palabras reservadas de C#

≪ Previous: Usando ExistDB (No Sql) desde .Net con C#

Hola amigos, al inicio de este año recibí una gran noticia por parte de Microsoft, más específicamente del programa Microsoft MVP, que es un programa en el cual se reconocen a líderes excepcionales de la comunidad por sus aportes en ella y por su especialidad en algún producto de Microsoft. Pues bien, esa gran noticia es que he sido reconocido este año como Microsoft MVP en la especialidad de .NET.

Es para mí un orgullo pertenecer a este selecto grupo y no quería dejar pasar la oportunidad para

agradecerles a ustedes, Comunidad, quienes hacen esto posible, gracias a ti, que lees mis post y aportas a ellos, pues ustedes son quienes fortalecen la labor de apasionados por la tecnología como yo y como muchos otros, que buscan aportar su granito de arena para que la comunidad tecnológica siga creciendo y cambiando el mundo.

Aprovecho también para felicitar a los nuevos MVP`s de mi país Colombia, y a todos los nuevos MVP`s de todo el mundo, y a los demás MVP`s antiguos quienes aportan a la comunidad en su especialidad.

Muchas gracias a todos! y espero poder seguir escribiendo, aportando en los foros, dictando charlas y demás cosas que me apasionan y contribuyen y ayudan a las demás personas.

Saludos y buena suerte!

↧

!Apunte semanal - Utilizar nombres de variables con palabras reservadas de C#

January 16, 2015, 8:02 pm

≫ Next: !Apunte semanal - Configurando el pool de conexiones de Entity Framework.

≪ Previous: Microsoft MVP .Net 2015

Hola amigos, en este apunte semanal les quiero compartir un truco bastante sencillo, que si bien no es una buena práctica puede servir en algún caso extremo que tengamos y que por motivos de fuerza mayor necesitemos utilizar, sin embargo solo lo recomiendo en un caso extremo que tengamos.

Sabemos que en C# y en los diferentes lenguajes no podemos usar las palabras reservadas del lenguaje para el nombramiento de variables como por ejemplo, using, namespace, int, string y un lago etcétera, ya que obtendremos un error como el siguiente:

Como en este caso se quiere utilizar el nombre de variable int, se debe anteponer el carácter @ al nombre de la variable, como se muestra a continuación:

Como podemos apreciar no es una buena práctica ni muy cómodo para escribir, leer o mantener el código, sin embargo como digo puede servir en un caso de fuerza mayor, o por ejemplo si queremos interactuar con código escrito en otro lenguaje, es decir si por ejemplo tenemos una librería de clases escrita en VisualBasic .net y en esta librería tenemos escrita alguna palabra reservada de C# pero que no es reservada en Vb, nos compilaría perfectamente la librería, pero al momento de invocarla desde C# tendríamos un error de compilación, en este caso podemos resolver el problema usando el carácter @ para referirnos a la palabra reservada.

Bueno y eso es todo de este apunte semanal, espero sea de utilidad.

Saludos y buena suerte!

↧

!Apunte semanal - Configurando el pool de conexiones de Entity Framework.

January 31, 2015, 8:13 pm

≫ Next: !Apunte semanal - Problemas al depurar tareas en paralelo?

≪ Previous: !Apunte semanal - Utilizar nombres de variables con palabras reservadas de C#

Sin lugar a dudas uno de los aspectos más importantes y que pueden afectar favorablemente o desfavorablemente el rendimiento de nuestras aplicaciones, es el acceso a fuentes de datos, ya que implica un costo considerable establecer conexión con dichas fuentes. Es por eso que una técnica muy utilizada para lidiar con este problema es el connection pooling o pool de conexiones, el cual permite mantener un número definido de conexiones abiertas y disponibles para que la aplicación o aplicaciones puedan usarlas sin tener que esperar a abrir una conexión, y es el pool quien se encarga de mantener estas conexiones y distribuirlas según se requiera.

Entity Framework a diferencia de otros ORM's no maneja directamente el pool de sesiones, sino que lo hace a través de ADO.Net, quien se encarga de manejar los pool para los diferentes Data Providers.

¿Y cómo puedo configurar este pool de Ado.Net?

ADO.Net maneja un pool de conexiones por cada cadena de conexión que tengamos en nuestra aplicación, quiere decir que si nos conectamos a dos bases de datos diferentes habrá un pool para cada una de ellas, o si generamos cadenas de conexión dinámicamente en tiempo de ejecución tendremos N pools de conexiones dependiendo de las que generemos ~~(Esto de generar cadenas de conexión en tiempo de ejecución, es muy contraproducente para el manejo del pool)~~, es por esto que si queremos configurar el pool de conexiones debemos hacerlo modificando los siguientes parámetros:

Parámetros a modificar en la cadena de conexión:

<add name="ConnectioName" connectionString="data source=TAVOPC;initial catalog=PoolDemo;integrated security=True;MultipleActiveResultSets=True;App=EntityFramework;
Connection Lifetime=120; Max Pool Size=20; Min Pool Size = 1; Pooling=True;" providerName="System.Data.SqlClient" />

Como podemos ver hacemos uso de cuatro parámetros en la cadena de conexión que corresponden a la configuración del pool, aunque sus nombres son muy dicientes veamos de que se trata cada uno:

Connection LifeTime: Define el tiempo de duración de las conexiones abiertas, se compara la hora en que se creó la conexión con el tiempo actual, para determinar según esta variable si se destruye la conexión o si permanece en pool, su valor esta dado en segundos y su valor por defecto es 0 que indica configurar el mayor tiempo de duración permitido.

Max Pool Size: Define el número máximo de conexiones gestionadas por el pool.

Min Pool Size: Define el número mínimo de conexiones gestionadas por el pool.

Pooling: Define si se va a utilizar el pool para gestionar las conexiones o no.

Bueno y eso es todo de este apunte semanal, espero sea de utilidad.

Saludos y buena suerte!

↧

!Apunte semanal - Problemas al depurar tareas en paralelo?

February 8, 2015, 2:20 pm

≫ Next: Conceptos básicos de Asp.Net MVC

≪ Previous: !Apunte semanal - Configurando el pool de conexiones de Entity Framework.

Hola amigos, en anteriores artículos tuvimos una introducción al paralelismo, y mucho más enfocado en lo que Microsoft .Net nos ofrece para trabajar con él, en resumidas cuentas tenemos la TPL que es la librería que nos permite trabajar con paralelismo de una forma muy sencilla, y que nos ofrece varias formas de trabajo como lo son el trabajo con datos a través de ciclos paralelos, paralelismo a través de tareas (Task), Plinq que nos permite realizar consultas linq en paralelo, entre otras. Y entre estas formas de trabajo hay una en particular que se convierte en transversal para todas, y es la depuración de procesos en paralelo, de suma importancia y utilidad para llevar un paso a paso de las instrucciones en las cuales estemos empleando el paralelismo, ya que en este tipo de instrucciones en paralelo podemos tener problemas a la hora de depurar, ya que cuando estamos haciendo paso a paso de una instrucción en ocasiones el depurador se salta y va a otra instrucción que se está ejecutando en simultánea, y luego vuelve a anterior, con lo cual tenemos un gran problema para comprender y seguir la depuración de una tarea en específico, yo por ejemplo he tenido este problema cuando trabajo referenciando dlls de otros proyectos de los cuales no tengo los proyectos agregados en la solución que estoy depurando.

Pues bueno para solucionar este problema si es que se nos presenta, podemos usar la clase Debugger del NameSpace System.Diagnostics, la cual nos permitirá hacer un punto de ruptura a través del método Break(), veamos cómo lo podemos hacer:

Primero vamos a crear en una aplicación de consola con una ejecución de tareas que invoquen diferentes métodos, tal como vemos a continuación:

        static void Main(string[] args)
        {
            Task t = new Task(TareaA);
            t.Start();

            Task t2 = new Task(TareaB);
            t2.Start();

            Task t3 = new Task(TareaC);
            t3.Start();

            Task.WaitAll(new Task[] { t, t2, t3 });
            Console.Write("Terminó la ejecución de las tareas A, B y C.");
        }

Y ahora vamos usar un punto de ruptura en alguna de las tareas:

        private static void TareaA()
        {
            Debugger.Break();
            Thread.Sleep(2000);
            Console.Write("Se ejecutó la tárea A");
        }

Con este Debugger.Break() ahora podemos depurar el contenido de la tarea A, sin tener problemas de con las otras tareas que se ejecutan en paralelo, adicional también nos podría ser de utilidad cuando tenemos instrucciones muy tediosas de depurar, por ejemplo si estamos recorriendo una lista de 10000 ítems y tenemos un error que solo se genera con alguno de los ítems, podríamos realizar una condicional y usar el Debugger.Break para capturar con mayor facilidad el problema ~~(aunque también lo podríamos hacer con las condicionales que nos ofrecen los puntos de interrupción de Visual Studio)~~.

Bueno y eso es todo de este apunte semanal, espero sea de utilidad.

Saludos y buena suerte!

↧

Conceptos básicos de Asp.Net MVC

February 19, 2015, 5:22 am

≫ Next: !Apunte semanal - De objetos inmutables, proxies inversos y otras finas hierbas

≪ Previous: !Apunte semanal - Problemas al depurar tareas en paralelo?

Hola amigos, hace algún tiempo dicté una charla de conceptos básicos de Asp.Net MVC, aquí les comparto la presentación, espero sea de utilidad. Saludos!

↧

!Apunte semanal - De objetos inmutables, proxies inversos y otras finas hierbas

March 8, 2015, 6:59 pm

≫ Next: Introducción a DocumentDB, la base de datos NoSql de Microsoft Azure.

≪ Previous: Conceptos básicos de Asp.Net MVC

En nuestra disciplina, carrera, medio o como lo queramos llamar, existen diversas palabras técnicas las cuales suenan bastante complejas, y que pueden poner nuestra imaginación a volar cuando las escuchamos, y aunque lo más probable es que las usemos todos los días ~~sin darnos cuenta~~, no sepamos su significado u objetivo, como por ejemplo, cuántos términos te son familiares de la siguiente lista?

:Pues sí, es bastante conocida y graciosa esta imagen o generador de excusas aleatorias para los informáticos, y como vemos hay muchos términos que son para dejar con la boca abierta a muchos, y otra frase que podríamos encajar perfectamente en la primera columna del generador de excusas es "Cuando logremos cambiar el valor del objeto inmutable" - "de las clases de abstracción" - "del acelerador de transacciones" o_O no suena nada mal!

Pues bien, de eso va este apunte semanal, y no se trata precisamente de enriquecer nuestro generador de excusas, si no de comprender de qué se tratan los objetos inmutables, objetos que usamos a diario en nuestra profesión como desarrolladores.

Un objeto inmutable es un objeto cuyo valor no puede cambiar una vez es creado, a diferencia de los objetos mutables, los cuales pueden sufrir cambios después de su creación.

En C# suelen manejarse muchos tipos inmutables, es por esto que debemos tener cuidado con su uso, y para comprender esto vamos a usar como ejemplo, un tipo que usamos todos los días, y que es inmutable "string"~~a eso me refería con que usamos todos los días objetos inmutables.~~

Por si no lo sabías cuando concatenamos otra cadena a una variable de tipo string, en realidad no estamos modificando directamente su contenido, si no que estamos creando otra variable la cual contiene el nuevo valor, aja! es por esto que siempre es recomendable usar en estos casos en los cuales tenemos que cambiar repetitivamente el valor inicial de la cadena, el tipo StringBuilder ya que es un tipo mutable, y debido a esto podemos cambiar su valor sin que el compilador tenga que crear nuevas cadenas.

string  mensaje = "este es el primer mensaje";
        mensaje += "(mensaje 1)";
        mensaje += "(mensaje 2)";

En el caso anterior tendríamos tres variables de tipo string, mientras que en el siguiente caso estaríamos creando una variable de tipo StringBuilder y la modificaremos en varias oportunidades.

var sb = new StringBuilder("este es ");
    sb.Append("el primer");
    sb.Append("mensaje");
    sb.Append("(mensaje 1)");
    sb.Append("(mensaje 2)");

Bueno y eso es todo de este apunte semanal, espero sea de utilidad y nos pueda servir para optimizar nuestro código.

Saludos y buena suerte!

↧

Introducción a DocumentDB, la base de datos NoSql de Microsoft Azure.

March 15, 2015, 12:59 pm

≫ Next: Presentación: DocumentDB, la base de datos NoSql de Microsoft Azure

≪ Previous: !Apunte semanal - De objetos inmutables, proxies inversos y otras finas hierbas

Hola amigos, hace un par de días tuve la oportunidad de dictar una introducción a documentDB, ya que fui invitado por parte de DevAcademy para participar en uno de sus Hangouts, aquí les comparto la grabación de la charla y espero sea de utilidad.

↧

Presentación: DocumentDB, la base de datos NoSql de Microsoft Azure

March 19, 2015, 8:31 am

≫ Next: DocumentDB, la base de datos NoSql de Microsoft Azure

≪ Previous: Introducción a DocumentDB, la base de datos NoSql de Microsoft Azure.

↧

DocumentDB, la base de datos NoSql de Microsoft Azure

March 19, 2015, 10:28 am

≫ Next: Creando mi primera base de datos DocumentDB

≪ Previous: Presentación: DocumentDB, la base de datos NoSql de Microsoft Azure

En la actualidad las aplicaciones cada vez más demandan y consumen una gran cantidad y volúmenes de datos y requieren seguir teniendo rápidos tiempos de respuesta, es por esto que cada vez toma más fuerza el concepto de NoSql, que fue diseñado para este fin, manejar grandes volúmenes de datos sin afectar la experiencia del usuario, ofreciendo facilidades para la escalabilidad horizontal y el no uso de un esquema rígido para la base de datos (Schema less).

Como respuesta a esto Microsoft combina el concepto de NoSql con el flexible y potente concepto de Cloud, a través del cual nos ofrece un servicio de base de datos NoSql documental llamado DocumentDb alojado en su plataforma en la nube Microsoft Azure.

como mencioné anteriormente DocumentDb es una base de datos NoSql de tipo documental, es decir que almacena la información en documentos, y usa notación JSON para esto, de igual forma como lo hacen otras base de datos como MongoDb y CouchDb por ejemplo. Cabe recordar que la sombrilla de NoSql tiene los siguientes tipos: Documental, clave valor, grafos y familia de columnas, cada tipo con ventajas para diferentes escenarios, si estás interesando en conocer los conceptos básicos de NoSql te invito a darle un vistazo a la siguiente diapositiva: Introducción a las bases de datos NoSql.

Una de las ventajas de DocumentDb es que podemos realizar consultas a nuestros documentos utilizando un lenguaje de consulta muy similar a Sql, y podemos crear procedimientos almacenados, triggers, y funciones utilizando javascript, en dónde podemos realizar operaciones Crud a través de este lenguaje. Adicional otra ventaja de DocumentDb al ser una base de datos diseñada para la nube es su flexibilidad para escalabilidad y elasticidad que se ajustan a nuestras necesidades.

La estructura de recursos de una base de datos DocumentDb es la siguiente:

Como podemos ver, debemos contar con una cuenta de almacenamiento, y sobre esta cuenta podemos tener N bases de datos, las cuales tienen usuarios con permisos asociados y colecciones, que nos permiten agrupar de una manera lógica nuestro documentos, como por ejemplo podríamos tener una colección para artículos, otra para autores, otra para categorías, etc. Y en cada colección tendremos nuestros documentos Json que contendrán nuestra información y para cada colección podemos manejar procedimientos almacenados, triggers y funciones, que recordemos programaremos con JavaScript.

Ahora, para el tema de desarrollo de aplicaciones DocumentDb nos ofrece una Api Rest a través de la cual expone los recursos de la base de datos, lo cual quiere decir que podemos interactuar con la base de datos mediante cualquier lenguaje o plataforma capaz de consumir servicios de este tipo y adicional al utilizar Apis de tipo Rest podemos consumirlas muy fácilmente desde cualquier dispositivo.

Además del Api Rest que expone DocumentDb también contamos con librerías específicas para plataformas las cuales nos ayudan y facilitan la interacción con la base de datos, en la actualidad tenemos librerías para las siguientes plataformas:

.Net
Node Js
JavaScript
Pyton

Y bueno amigos eso fue todo de esta introducción sobre DocumentDb la base de datos NoSql del Microsoft Azure, espero sea de utilidad, en próximos artículos observaremos cómo crear la base de datos y sus diferentes recursos, así mismo veremos como interactuar con ella a través del SDK para .Net y también a través de las Apis Rest.

Si quieres profundizar más sobre el tema te recomiendo el sitio oficial de Microsoft Azure: https://azure.microsoft.com/es-es/services/documentdb/

No olvides visitar mi página en Facebook para mantenerte actualizado de lo que pasa en el Tavo.Net https://www.facebook.com/eltavo.net

Saludos y buena suerte!

↧