[.NET] Entendiendo el Patrón de Repositorio

Implementar el patrón de repositorio es una práctica muy común en aquellos proyectos que necesitan trabajar con datos externos, ya sea esto a través de bases de datos, servicios web, archivos u otros.

Este patrón nos ayuda mejorar la mantenibilidad y la capacidad de prueba. Con la correcta separación de intereses, nuestra lógica de negocio ya se puede concentrar en el negocio en sí y no preocuparse en operaciones de bajo nivel, como abrir una conexión a una base de datos o algún socket.

Este patrón nos habla de una capa intermedia entre la lógica de negocio y la fuente de datos, pero hay muchas formas de entenderlo así que exploremos algunos puntos.

1. Reponsabilidad única

En el siguiente programa estamos accediendo a una base de datos para obtener un listado y también para mostrarlo en pantalla, pero todo se encuentra en una sola clase violando el principio de diseño de responsabilidad única.

Lo ideal sería mover la lógica correspondiente a la conexión a base de datos a una una clase aparte en otro proyecto de librería de clases.

Y terminar con la clase principal de la siguiente forma:

2. Repositorios genéricos

En muchas operaciones con datos, creamos, modificamos, eliminamos o consultamos registros, por ello es usual considerar la creación de una interfaz para un repositorio genérico.

Sin embargo, esta idea nos puede llevar a encontrarnos con situaciones muy parecidas a estas:

No es que se acabe el mundo, pero hay que tomarlo en consideración ya que podría dificultar el diseño de nuestras aplicaciones y viola un principio de diseño.

3. Segregación de interfaces

Implementar las interfaces adecuadamente nos ayuda a tener mejores resultados. Si creamos una interfaz como esta:

Tendremos la capacidad de trabajar con diferentes implementaciones según la ocasión.

Y en nuestro programa principal solo nos preocupariamos de la interface y de como se realizaría la instanciación que necesitamos.

Algunos extienden esto usando inyección de dependencias, otros se organizan usando espacios de nombre y otros hacen cosas diferentes. La resolución o complejidad de esto ya depende de los requisitos del proyecto o elección de cada uno.