[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 { 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!