Utilizando Inyección de Dependencias en WordPress


Aunque la mayoría de los desarrollos web que hacemos son en Symfony2, en Simettric trabajamos mucho con WordPress. Elegimos esta opción de CMS frente a otras por su mercado y popularidad, decidiendo enfocarnos en una sola opción para dar un mejor servicio.

Pero WordPress no es perfecto, tiene muchas limitaciones que aún no están solventadas y que impiden pensar en esta solución de CMS de la misma forma en la que pensamos con herramientas o frameworks como Symfony2 o Silex. A pesar de esto, muchos clientes que empiezan con su servicio en Internet establecen como requisito esta opción para construir sus plataformas o ya disponen de un desarrollo que ha ido evolucionando sobre esta opción.

En proyectos de este tipo a veces WordPress es una opción factible por la tipología de producto a desarrollar coincidiendo con un presupuesto reducido. En otros proyectos no es la mejor opción, sobre todo si el producto va a evolucionar en features, necesitando ser mantenible y evolucionar de forma coherente también en UX, esto último complicado sin invertir en desarrollo y diseño.

¿Qué es y por qué utilizamos Inyección de dependencias en un proyecto de WordPress?

Algo importante si vamos a construir un proyecto WordPress que va a requerir escalar o si debemos migrar una plataforma hecha sobre este sistema a otra arquitectura más solida como la que nos pueden proporcionar Symfony2 o Laravel, es el pensar cómo podemos reutilizar el código ya hecho.

La Inyección de Dependencias es un patrón de arquitectura de software que nos permite desacoplar nuestro código al máximo, para poder no sólo migrar de un framework/cms/desarrollo a medida a otras soluciones, sino también el poder sustituir cada una de las partes que lo forman.

En este sentido, gracias a la Inyección de Dependencia lo que hacemos es separar nuestro código de negocio de todo código que tenga que ver con WordPress. Esto nos permite tener una capa totalmente independiente que podemos mover en un futuro de una instalación WordPress a un proyecto Symfony2 sin modificar prácticamente nada de lo que hayamos programado.

¿Cómo lo implementamos?

Existen varias librerías que nos permiten gestionar Inyección de Dependencias en php, las más conocidas y usadas son Pimple y el componente de Symfony2 de Inyección de Dependencias que además cuenta con un sistema de configuración de servicios muy potente.

Para WordPress o desarrollo simples por lo general utilizamos Pimple por ser una opción más simple y ligera. Vamos a ver un ejemplo simple de cómo trabajaríamos con esta librería.

En este primer ejemplo, vemos cómo hemos inicializado el contenedor de dependencias en primer lugar. Este contenedor nos servirá para almacenar instancias de objetos, a las que llamamos “servicios” y parámetros que pueden ser datos de configuraciones o todo lo que no sea una instancia de un objeto.

En este ejemplo, hemos creado un servicio “wordpress.query” que nos devolverá el $wp_query global que estamos acostumbrados a usar en cualquier desarrollo WordPress. Aunque pueda parecer que este ejemplo no da mucho valor o no tiene sentido, en realidad hemos dotado de una flexibilidad a nuestro código de una forma muy sencilla.
Si en un futuro necesitamos extender la clase \WP_Query y utilizar una implementación propia, tenemos la certeza de que si hemos usado el servicio “wordpress.query” sólo tenemos que cambiar el código en la implementación del servicio “wordpress.query”, el resto de código que haga uso de este servicio seguiría funcionando sin ningún cambio.

Vamos a ver un ejemplo donde este valor se va a ver con más claridad.

Imaginemos que necesitamos desarrollar un sistema de contactos sobre WordPress que haga uso de Custom Post Types y que pueda ser migrable en un futuro a un framework como Symfony2 o Silex.

Lo primero que hacemos es crear la clase que hará de entidad de los contactos.

Una vez creada la clase Contact, vamos a crear una interfaz que definirá cómo trabajamos con los contactos a nivel de guardado y recuperación de datos.

Con esta interfaz definimos cómo debería hacerse la lectura y escritura de datos en la fuente que sea: base de datos, servicio web… lo que sea, nos es indiferente.

Tras crear la interfaz, creamos una clase que implementa dicha interfaz.

Esta clase estará acoplada a la lógica y funcionamiento de WordPress y es la que tendremos que sustituir al migrar a Symfony2 para que utilice Doctrine2 por ejemplo en lugar de WordPress.

Ahora vamos a crear el modelo en el que tendremos la lógica de negocio y que estará aislada de WordPress.

En el modelo de contacto ya podemos hacer operaciones sin pensar de dónde estamos recuperando la información de contacto o dónde la estamos guardando.

Obviamente este es un ejemplo muy simple y probablemente necesitaríamos crearnos más implementaciones para otros servicios que dependan de funcionalidad de WordPress, como el envío de correo con \wp_mail por ejemplo.

Pero lo que pretendo mostrar con este ejemplo es cómo desacoplar la lógica de negocio de uno de los puntos que más suele atarnos a WordPress: el acceso a los datos.

Una vez teniendo separadas las partes implementadas, vamos a instanciarlas para poder utilizarlas en nuestro plugin o theme.

Como vemos, hemos definido cada instancia de clase con su servicio en el contenedor. Hay que matizar que cada vez que se llame por ejemplo al servicio “contact.model” siempre se traerá la misma instancia de ese objeto en lugar de crear una instancia nueva. Es como utilizar el patrón Singleton, pero sin sus defectos y con la flexibilidad de poder cambiar las clases desde un único sitio.
No obstante, si se desea que se comporte de otro modo, en la documentación de Pimple podéis encontrar cómo hacerlo.

Desde nuestro plugin o theme podríamos entonces utilizar nuestro código de esta forma:

Como podemos comprobar, las operaciones que no tienen que ver con WordPress no dependen del mismo.

Si en un futuro cambiamos a Symfony2, bastaría con cambiar el objeto que implemente la interfaz RepositoryInterface dentro del servicio “contact.repository”.
Con este cambio, podremos mover nuestro código sin cambiar nada en el servicio “contact.model” que es el que hace todo el trabajo de negocio.

Hay otra ventaja adicional y es que el separar en servicios nuestro código, este se puede cubrir con tests unitarios sin problemas, haciendo el código mucho más robusto y estable aunque esté funcionando bajo WordPress.

En definitiva, desarrollando de esta forma la calidad y flexibilidad de nuestros desarrollos aumenta significativamente.

 

Escrito por Asier Marqués

Implementando un sistema de login en Xamarin.Forms

Aunque la mayoría de los desarrollos web que hacemos son en Symfony2, en Simettric trabajamos mucho con WordPress. Elegimos esta opción de CMS frente a otras por su mercado y popularidad, decidiendo enfocarnos en una sola opción para dar un mejor servicio. Pero WordPress no es perfecto, tiene muchas limitaciones que aún no están solventadas […]

Cómo hacer que el control Editor se ajuste al texto en Xamarin.Forms

Aunque la mayoría de los desarrollos web que hacemos son en Symfony2, en Simettric trabajamos mucho con WordPress. Elegimos esta opción de CMS frente a otras por su mercado y popularidad, decidiendo enfocarnos en una sola opción para dar un mejor servicio. Pero WordPress no es perfecto, tiene muchas limitaciones que aún no están solventadas […]