Diagrama Modelo Vista Controlador
Modelo vista controlador en WordPress

Vamos a aplicar el patrón de diseño software Modelo-Vista-Controlador en el desarrollo de plugins y temas WordPress.

El patrón de diseño software

Estamos ante uno de los patrones de diseño más usado en el desarrollo software. Se considera uno de los básicos a la hora de estructurar los proyectos.

Con él se consigue desacoplar la capa que muestra los datos en la interfaz, con la capa del modelo de datos. Todo ello a través de una capa de controladores, que se encargarán de que ambas partes «se entiendan».
En el siguiente esquema podemos ver su estructura:

Diagrama Modelo Vista Controlador

Este desacoplo nos permite por ejemplo cambiar el sistema de almacenar los datos, sin que la «aplicación pública» se vea comprometida. Es más, ese cambio sería 100% transparente para el usuario. Podemos por ejemplo pasar de tener los datos en una base de datos MYSQL, a tenerlos en un sistema de archivos en el servidor.

O nos permitiría por ejemplo, cambiar la vista de los datos, de html a un feed rss sin que el modelo de datos se vea alterado con ello.

Caso de uso

Vamos a implementar un portal para una inmobiliaria, en la que mostrar a los usuarios las propiedades disponibles, y poder solicitar información sobre ella.

Aplicándolo al desarrollo de plugins

La funcionalidad principal del portal será implementada a través de un plugin, al que llamaremos realhouse.
Veamos las distintas partes que componen el patrón de diseño MVC (modelo vista controlador), en nuestro plugin:

Estructura de carpetas del plugin

  • Vista: Usaremos shortcodes para mostrar la información en el frontend. A modo de referencia del código a mostrar, crearemos el shortcode: realhouse_search, que nos mostrará un buscador avanzado de propiedades.
  • Controlador: Crearemos clases que harán de controladores entre la vista y el modelo de datos. Desacoplando las vistas del modelo de datos.
  • Modelo: De los distintos modelos que contendrá el sistema, y que representarán las entidades «del mundo real», nos centraremos en el modelo que implementa a las propiedades inmobiliarias.

El flujo de información y peticiones que se producen en el patrón Modelo Vista Controlador, lo podemos ver en el siguiente diagrama de secuencia:

Diagrama de secuencia MVC

1: La vista necesita consultar el listado de propiedades, por lo que se lo pide al controlador.

1.1: El controlador al recibir la consulta, pide al modelo de datos la información requerida.

1.1.1: El modelo de datos devuelve al controlador la información que se le pidió.

1.1.1.1: El controlador, que ya tiene los datos disponibles, se los revuelve a la vista, para que pueda mostrar por pantalla dicha información.

Como podemos ver, en ningún momento la vista sabe cómo se almacenan los datos, ni el modelo sabe cómo se muestran los datos. A esto es a lo que llamamos «desacoplamiento».

Veamos la implementación:

Empezando por el modelo de datos, que representará a las entidades inmobiliarias, y haciendo uso de las herramientas que nos ofrece WordPress, lo implementaremos mediante un custom post type llamado property. Para su gestión, en la clase RealhouseProperty, implementaremos los métodos CRUD (crear, leer, actualizar y borrar).

Nuestro controlador RealhousePropertyController estará a la escucha de las posibles peticiones que desde la vista le puedan llegar. Interpretándolas, gestionándolas y dando respuesta, tomando como fuente de información la clase del modelo RealhouseProperty.

Y por último tenemos la vista, nuestro shortcode. Que en lugar de encargarse de hacer la gestión de datos y todo el proceso, simplemente se encarga de su acometido, «pintar». El shortcode hará sus peticiones al conrtrolador, sin saber en ningún momento cómo ni dónde se guardan los datos.

Aplicándolo al desarrollo de temas

En el desarrollo de temas, es evidente donde tenemos la parte de «la vista», quedando por definir el controlador y el modelo.

La teoría dice que la funcionalidad de un tema debería ser definida en el propio tema, si es funcionalidad vinculada a él, y en un plugin si es más independiente.

Ya con el patrón MVC se pretende desacoplar las distintas partes, recomiendo implementar la parte del controlador y el modelo en un plugin, por lo que podemos seguir las indicaciones dadas arriba.