Beneficios del patrón de repositorio: por qué deberíamos considerarlo
Ayer, di una introducción al patrón del repositorio. En resumen, es uno de esos patrones que creo que cualquier persona que trabaje con middleware construido sobre WordPress debería entender.
Al dar una introducción a un patrón como este, puede ser difícil hacer justicia al patrón cuando se necesita:
- presentarlo,
- explicar cómo funciona,
- cubrir los beneficios,
- y dar una pequeña demostración.
Pero la verdadera ventaja del repositorio radica no solo en abstraer la capa de datos del resto de la aplicación, sino que puede (o debería) poder intercambiarse fácilmente con varios almacenes de datos sin cambiar la API.
Por ejemplo, en un caso, es posible que deba recuperar datos de la base de datos de WordPress, en otros casos, es posible que deba recuperar algo de una API de terceros, o tal vez haya algún otro lugar del que necesite recuperar datos.
Independientemente, la idea detrás del patrón de repositorio es que lo que sea que se encuentre detrás de él no importa siempre que la API que proporciona funcione para la capa de la aplicación que lo llama.
Y dado que hemos cubierto una introducción al patrón de repositorio, echemos un vistazo a algunos de los beneficios del patrón de repositorio y cómo podemos implementarlo en el contexto de los proyectos de WordPress.
Beneficios del patrón de repositorio
Hay algunas formas de empezar a explicar el patrón, así que voy a empezar con un diagrama simple:
Los beneficios del patrón de repositorio incluyen la abstracción del almacén de datos
Observe en la imagen de arriba, hay tres componentes principales:
- la lógica de dominio (o la lógica de negocios) que he etiquetado como "Aplicación",
- el repositorio,
- el almacén de datos,
En cuanto a la aplicación, las reglas de negocio siempre se mantendrán relativamente consistentes. Al menos deberían, ¿verdad?
El repositorio es lo que actúa como medio de comunicación entre la lógica empresarial y el almacén de datos.
Ahora, el almacén de datos puede ser una base de datos, quizás un conjunto de archivos (que no recomendaría), una API para un tercero, una lista de información recuperada de otra aplicación, etc.
El punto es que el repositorio proporcionará una API limpia en la que la lógica empresarial puede escribir y leer (y más sobre esto en un momento) sin preocuparse por los detalles de adónde van los datos o cómo regresan.
Ese es el trabajo del repositorio. Y eso es lo que hace que sea importante tener una API consistente y eso es lo importante para asegurarse de que tenga los detalles de implementación del almacén de datos con el que está interactuando.
en el acoplamiento
Además de tener su aplicación correctamente segmentada, el patrón de repositorio beneficia a la arquitectura ya que ayuda a desacoplar las partes de su aplicación.
Es decir, la lógica empresarial no sabe nada sobre cómo o dónde se almacenan los datos. Simplemente sabe que puede escribirlo y recuperarlo y puede hacerlo usando una API limpia.
El repositorio es responsable de comunicar dicho almacén de datos para organizar la serialización y la recuperación, pero debe proporcionar una API coherente, por lo que la capa de datos no tiene que hacer gimnasia sintáctica para leer y escribir su información.
Detalles de implementacion
Hasta este punto, he estado representando el repositorio como una clase concreta.
La cuestión es que una aplicación probablemente tendrá varios repositorios. Y por eso, es una buena idea tener interfaces que cada repositorio pueda implementar.
Así es como se define el contrato de métodos que proporcionará el repositorio. Y así es como puede asegurarse de que cada repositorio esté conectado al almacén de datos adecuado.
Una implementación de interfaz para múltiples repositorios.
Entonces, digamos que su aplicación necesita comunicarse con la base de datos de WordPress, así como con una API de terceros.
Idealmente, la interfaz proporcionaría un conjunto común de métodos, pero los detalles de implementación variarían según el repositorio porque cada repositorio tendrá las credenciales y la capacidad necesarias para comunicarse con el almacén de datos.
Sin embargo, el avance a la interfaz es lo que le da al patrón su poder. La lógica del dominio no tiene que preocuparse por cómo se guarda la información o cómo se recupera. Simplemente llama a los métodos definidos en la interfaz y el objeto necesario se ocupa de ello.
Simplemente llama a los métodos definidos en la interfaz y el objeto necesario se ocupa de ello.
¿Cómo se vería esto en WordPress?
Esta es una buena pregunta (y no, no la inventé solo para responderla por mi cuenta 🙂), y puede ser difícil dar un gran ejemplo porque gran parte de lo que hacemos interactúa directamente con la base de datos de WordPress.
Esto no significa que no haya abstracciones que podamos usar, como Publicaciones, Páginas, Usuarios o cualquier otro tipo de publicación personalizada que optemos por crear.
Pero WordPress proporciona una API para gran parte de esto. Puedo ver un caso en el que, por ejemplo, un usuario con campos adicionales que se han agregado podría beneficiarse de un repositorio de usuarios.
O un tipo de publicación personalizada con una gran cantidad de metadatos también podría beneficiarse de un repositorio al tener los detalles encapsulados en el repositorio.
Un ejemplo de alto nivel
Digamos, por ejemplo, que tiene un tipo de publicación personalizada para un evento, y el evento tiene un título y una descripción que encajarían naturalmente con el título y el contenido de la publicación.
Pero luego tiene metadatos sobre su ubicación, su hora de inicio, su hora de finalización, etc. Eso también podría ser encapsulado por el repositorio para que pueda tener un objeto Evento, pasarlo al repositorio y luego dejar que el repositorio envíe la información al lugar adecuado en la base de datos.
Y lo mismo ocurre con la recuperación de la información: sabe dónde obtenerla, cómo completar un objeto de evento y luego devolvérselo a la persona que llama.
Volver sobre la pista
Pero toda esta charla sobre un evento se está desviando un poco del tema, por lo que tal vez continúe hablando sobre eso y cómo encaja con el repositorio en una publicación de seguimiento. Claramente, cuando se habla de esto, hay mucho que cubrir.
Prefiero tomarlo en pasos más pequeños
En resumen, si tiene un repositorio de eventos, es probable que tenga un objeto de evento o una entidad de evento. Y cómo esto encaja en WordPress, los tipos de publicaciones personalizadas, los metadatos, etc. introduce un nivel de complejidad que puede parecer desalentador al principio, pero finalmente vale la pena cuando se trabaja con una aplicación web más grande.