El patrón repositorio es un patrón que se encarga de encapsular y centralizar la lógica relativa a la persistencia de los datos. Esto se hace para obtener una capa extra de abstracción en tus componentes, evitando la repetición del código (principio DRY), facilitando el testeo y desacoplándolo de la lógica de negocio.
Pero esto son muchas palabrejas que sin explicación carecen de sentido, así que vamos por partes.
👉 Encapsula y centraliza la persistencia
Para entender por qué el patrón repositorio «encapsula» tengo que definir el concepto de encapsulamiento en programación orientada a objetos:
La encapsulación se define como el empaquetado de datos en una sola unidad. Es el mecanismo que une el código y los datos que manipula.
GeekforGeeks – Encapsulation in Java (traducido)
Aceptando esa definición entonces tenemos que entender lo que hace el patrón para que este «empaquetado de datos» ocurra. Partamos de una situación hipotética donde no tenemos patrón repositorio y tenemos 3 páginas: autor, últimos articulos publicados y la página del artículo en sí mismo.
Así pues, nos encontramos en la siguiente situación:
1. La página de autor carga tanto los datos del autor como los artículos que haya escrito
2. La página de carga la información básica de los últimos artículos pero sin información del autor.
3. La página de artículo carga todo el contenido del artículo y una sección con breve información sobre el autor
Nada fuera de lo normal, ¿verdad? Es una distribución normal y super simplificada de cualquier blog. El problema es que si hicieramos esto así, en cada función de carga de los datos en el backend de cada página nuestro método tendría que tener directamente las consultas a la base de datos. Me voy a centrar en el punto 2, pero os hacéis una idea con el resto.
Esta situación se puede volver rápidamente una locura, aparte de hacer dificil de automatizar el testeo.
¿Y si luego decidimos que luego todos los artículos deben tener el nombre de los autores? Tenemos entonces que modificar la consulta en cada página donde hayamos incluido artículos, lo que deriva en una mayor probabilidad de error humano. Si, y esto es muy importante considerarlo, podemos olvidarnos fácilmente de modificar una de las sentencias para que ahora incluyan un JOIN con una tabla de autores.
Por ello, le damos una capa extra al sistema, lo que nos lleva al siguiente punto.
👉 Capa extra de abstracción
Con lo anteriormente visto entonces decidimos a añadir una capa extra para la infrastructura / persistencia, lo que nos deja este método para el usuario.
Y movemos la lógica que contacta con la base de datos a otro método en la clase para el repositorio. De esta manera, si decidimos hacer un cambio e incluir lo del autor, cambiado el método del repositorio, todas las páginas que necesitasen los datos del autor lo tendrían accesible con un único cambio. Una maravilla, ¿verdad? 🤩
Entiendo que llegados a este punto ya te habrás dado cuenta que esa capa actúa como intermediaria entre lo que le ofreces al cliente y tu base de datos, permitiendo una independencia en tu capa de persistencia.
Es decir, te permite que tu sistema se independice (basado en el ejemplo anterior) en tres partes:
1. Una capa con las lógicas de empresa (pseudo-capa de dominio) que corresponde con las diferentes clases como artículo, autor, etc.
2. Una capa de infrastructura que se encarga de la gestión de los datos y que realiza validaciones basadas en la capa de lógicas de empresa.
3. Una capa de aplicación que contiene los servicios con los que contacta directamente el cliente, que no sabe – y no necesita saber – cómo se implementa la persistencia de los datos ni su validación.
¡Has llegado al final del artículo, felicidades! 🥳🎉
¿Quizás te puedo interesar en el ejemplo completo de la implementación de un repositorio simple que veias en las imágenes? Si es así, échale un ojo en el artículo que verás a continuación.
Cómo implementar el patrón repositorio con ADO.NET y C#
En este ejemplo me voy a centrar en usar el patrón repositorio con ADO.NET, por ser la forma más básica con la que accedemos a nuestras bases de datos.
Como reflexión final, se que quizás ya a muchos os suena a arquitectura por capas, Domain Driven Design y todo eso, pero… ¡Qué le voy a hacer! Me gusta dividir en capas porque siento que se entiende mejor, honestamente 😅.
Dicho sea que el punto sobre la «creación de una capa de abstracción extra» yo lo he considerado como una ventaja, por la facilidad para poder luego explicar qué hace cada cosa de forma independiente. Sin embargo, aumenta la complejidad de la aplicación y podría considerarse una desventaja.
Al final es como todo, tómalo o déjalo según el tipo de proyecto o el punto del proyecto en el que estés. Puedes comenzar sin el repositorio y luego añadirlo o hacerlo desde el principio, está en tus manos esa decisión 😉
