Introducción al patrón del repositorio
Cada vez que trabaja en un proyecto más grande que se basa en WordPress, las probabilidades de que trabaje con más de una sola fuente de datos, es decir, la base de datos de WordPress, son más altas de lo normal. Por ejemplo, puede estar trabajando en un proyecto que tiene que coordinar información de:
- la base de datos de WordPress,
- un sistema de tickets de la mesa de ayuda,
- un sistema de importación de contenido,
- otra API de terceros,
- y posible más.
Y cuando esto sucede, puede volverse un poco engorroso escribir código que facilite la recuperación de información de esos diferentes lugares. De esto suelen hablar los desarrolladores cuando se refieren a tratar con "capas" en su aplicación. Es decir,
- hay capas para presentar información al usuario,
capas para manejar la lógica empresarial (o lógica de dominio), - capas para comunicarse con las API,
- y capas para almacenar datos.
Honestamente, no es necesario tener una variedad de almacenes de datos para observar para crear una capa que facilite el envío y la recuperación de datos de la base de datos, justo cuando es más común. Puede trabajar con la misma eficacia con un único almacén de datos, como la base de datos de WordPress, al implementar el patrón de repositorio.
De todos modos, si está creando un sitio web, una aplicación web o un complemento más grande, implementar el patrón de repositorio es algo que puede generar beneficios en el mantenimiento, la claridad del código y la separación de preocupaciones.
Pero, ¿cómo podría implementarse esto dentro de WordPress? No es un gran desafío, pero primero, vale la pena revisar un manual de repositorio antes de saltar a cualquier código.
Una cartilla de patrones de repositorio
Antes de ver una implementación real en WordPress, es importante comprender qué es el repositorio, cómo se define, qué ofrece y una implementación genérica del mismo. Compartiré algunas lecturas adicionales al final del artículo, pero hasta entonces cubriré mi opinión general sobre el patrón aquí.
Primero, la implementación de este patrón puede volverse más complicada de lo necesario para los principiantes. Esto no quiere decir que no valga la pena entender el patrón real, pero si solo busca mojarse con esto, no soy un fanático de arrojar a los lectores al fondo. No creo que sea la mejor manera de aprender.
En cambio, vale la pena dividir el problema y luego reconstruirlo en algo un poco más elegante. Así que eso es lo que voy a intentar hacer.
Una palabra sobre el desacoplamiento
Cuando hablamos de programación orientada a objetos, a menudo hablamos de la idea de "desacoplar" partes del sistema. Si está familiarizado con el acoplamiento y la cohesión, entonces sabe por qué.
Pero si no, baste decir que cuanto más acoplados estén los componentes de su sistema, más difícil será cambiarlos. Saben demasiado el uno del otro. Es decir, si cambia uno de los aspectos del sistema, es probable que se produzca una cascada o un impacto en otra parte del sistema que nunca tuvo la intención de que sucediera. Luego, tendrá que pasar mucho más tiempo reparando todos estos otros "puntos de contacto" en todo el sistema que no deberían ser necesarios.
La implementación de varias estrategias, como el patrón de repositorio, puede ayudar a desacoplar partes del sistema. Caso en cuestión: la capa de presentación no sabe cómo está organizado el almacén de datos subyacente. No necesita saber SQL. No necesita saber que es una base de datos. En cambio, solo necesita saber cómo comunicarse con el repositorio.
Bonito, ¿verdad?
Esto significa que puede intercambiar el almacén de datos de back-end y, suponiendo que su API sea sólida; su aplicación continuará funcionando con poco o ningún cambio. Y eso es lo que significa estar verdaderamente desacoplado.
Una implementación del patrón de repositorio
Entonces, ¿cómo se ve el patrón del repositorio? Como con la mayoría de los patrones de diseño, hay una forma genérica del patrón, y eso siempre es útil, pero creo que también nos ayuda a los que trabajamos en WordPress a ver cómo podría funcionar dentro del contexto de, ya sabes, WordPress.
Entonces, primero, quiero desglosar el patrón en sí y luego dar un ejemplo de cómo se vería cuando se trabaja con WordPress.
Una implementación genérica del patrón de repositorio
La implementación real del patrón de repositorio es bastante simple. De hecho, nunca estoy seguro de si es tan útil porque solo muestra cómo los almacenes de datos, el repositorio y el resto de la aplicación interactúan entre sí.
No me malinterpreten: estoy a favor de los modelos conceptuales de cómo se organizan las cosas. Personalmente, me ayuda pensar en la estructura de una aplicación cuando la construyo, pero si es demasiado general, no es de mucha ayuda.
Pero para llegar a un implemento concreto, tenemos que empezar por alguna parte, ¿no? Así que empezaré en el nivel más alto posible y trabajaré hacia abajo.
Como puede ver en la imagen de arriba, tiene un par de almacenes de datos, todos los cuales se leen a través del repositorio, y luego la aplicación consulta el repositorio que, a su vez, recupera información del almacén de datos.
Sí, hay opciones para almacenar información en caché, invalidar el caché y todas esas cosas divertidas. Pero está fuera del alcance de una primaria del repositorio. Así que no voy a seguir ese camino en particular por ahora. Tal vez en una publicación futura (si esta te resulta útil).
El patrón de repositorio en WordPress
Dicho esto, echemos un vistazo a una implementación básica de cómo se vería esto en una instalación estándar de WordPress. Es decir, todo lo que tenemos es el almacén de datos. No nos estamos comunicando con nada más, pero queremos asegurarnos de que todo lo que interactúa con la base de datos o la API sea manejado por el repositorio.
Esto se vería algo como esto:
Cómo podría verse con WordPress
Y esto se puede resumir aún más. Tal vez haya un repositorio de publicaciones o un repositorio de usuarios. Personalmente, soy fanático de tener un repositorio para cada tipo de entidad porque ayuda a contener la lógica comercial relacionada sin crear esas grandes clases que lo saben todo (e innecesariamente).
Así que esto podría verse así:
Un paquete de repositorios
Luego, subamos un nivel más y digamos que está trabajando con la API de Twitter, la API de ZenDesk, la API de usuario de WordPress y la API de publicación de WordPress. ¿Y que? Hay más repositorios.
Tal vez estén contenidos en su espacio de nombres (que deberían estar), tal vez estén implementando una interfaz común (para lo cual existe un caso), pero durante el tiempo de desarrollo, creo que es importante indicar explícitamente qué repositorio está utilizando. para que quede lo más claro posible.
Es decir, no use un genérico y deje que el tiempo de ejecución lo resuelva:
$support_repository = new Support_Repository();
$support_repository->get_tickets_for( 'tommcfarlin' );En su lugar, sea explícito:
$zendesk_repository = new ZenDesk_Repository();
$zendesk_repository->get_tickets_from( 'yesterday' );Esto puede parecer mucho. No sé si experimenta esto, pero hay una sensación extraña en la programación orientada a objetos donde queremos crear clases pequeñas y enfocadas, pero crea muchos archivos.
Así que tienes estos archivos cuidadosamente configurados, cada uno de los cuales está haciendo algo pequeño y con un propósito. No permita que la cantidad de archivos que componen un proyecto le dé la impresión de que tiene una arquitectura deficiente.
Conclusión
Este es el manual básico sobre el patrón del repositorio. Naturalmente, hay un código que va junto con esto, pero antes de profundizar en esa parte, porque el código es donde las cosas se pierden fácilmente en la traducción, quería asegurarme de ayudar a proporcionar una ilustración para desarrollar un modelo conceptual de cómo funciona el patrón.
A partir de aquí, podemos empezar a hablar de una implementación del patrón. Así que en la próxima publicación o en las próximas dos publicaciones, haré exactamente eso.
Mientras tanto, no dude en dejar cualquier comentario o pregunta sobre lo que hemos cubierto aquí.
Lectura relacionada
- El patrón de repositorio a través de 8th Light
- El patrón de repositorio a través de MSDN
- Una implementación del patrón de repositorio