Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Creative Coding

WordPress para el Desarrollo de Aplicaciones Web: Repensado la Arquitectura

by
Read Time:7 minsLanguages:
This post is part of a series called Using WordPress for Web Application Development.
WordPress for Web App Development: An Introduction
WordPress for Web App Development: The Conceptual Model

Spanish (Español) translation by David Castrillón (you can also view the original English article)

En esta serie, estamos en el proceso de hablar sobre cómo podemos construir aplicaciones web usando WordPress. Y aunque esto no es una seria técnica en la que vamos mirando código, estamos cubriendo temas tales como frameworks, bases, patrones de diseño, arquitecturas y así sucesivamente.

Si no has leído el primer post de la serie, te lo recomiendo; sin embargo, para los efectos de este post, podemos resumir el post anterior así:

En resumen, el software puede ser construido sobre frameworks, el software puede extenderse en bases.

Sencillamente, hemos distinguido entre frameworks y bases - dos términos que a menudo se usan indistintamente en el software a pesar de que no son lo mismo. WordPress es una base porque se trata de una aplicación en sí misma. No es un framework.

Para ello, a la hora de crear aplicaciones web en WordPress, necesitamos repensar la arquitectura o reconsiderar nuestros modelos conceptuales de cómo se construyen las aplicaciones.


La Estructura de una Aplicación Web

En el nivel más alto posible, las aplicaciones web son normalmente estructuradas con los siguientes tres componentes:

  1. La Capa de Base de Datos
  2. La Capa de la Aplicación
  3. La Capa de Presentación

En general, la capa de presentación es lo que el usuario ve y con lo que el usuario interactúa. Incluye todos los estilos, el código del lado del cliente y el marcado necesario para poner algo delante del usuario.

Cuando el usuario hace clic en algo, o la página procesa la información obtenida de la base de datos, está interactuando con la capa de la aplicación.

La Capa de la Aplicación es la responsable de coordinar la información desde el navegador o de una acción del usuario a la base de datos. A veces, consiste en escribir la información de la base de datos - tal como la información de un campo del formulario - para leer información desde la base de datos, como recuperar la información de la cuenta del usuario.

Al igual que la capa de presentación que consta de diferentes componentes, tales como estilos, JavaScript, marcado y así sucesivamente - la capa de la aplicación puede consistir en una variedad de diferentes componentes tales como sistemas que son necesarios para leer y escribir datos en la base de datos, limpieza de la información, validación de la información y hacer cumplir ciertas reglas que son únicas para el problema.

Por último, la capa de la base de datos es donde se almacenan los datos. Puede consistir del sistema de archivos, puede consistir en una base de datos de MySQL, o puede consistir en una solución de terceros como un almacén de datos que está "en la nube" como Amazon S3 o algo como eso.

Todo es Abstracto

El punto principal para tomar distancia de esto es que en el software, siempre tratamos con cierto nivel de abstracción. Por ejemplo, hablamos del almacén de datos o la capa de la base de datos, pero realmente no estamos siendo específicos. Lo mismo pasa con la capa de la aplicación y la capa de la presentación.

  • ¿Estamos hablando de una base de datos relacional con varias tablas, o estamos hablando de almacenamiento en la nube?
  • ¿Qué tipo de capa de acceso a los datos vamos a conectar a la capa de la aplicación para que hable con la base de datos?
  • ¿Qué frameworks y lenguajes estamos utilizando en el front-end? ¿Vanilla JavaScript, jQuery, Knockout.js? ¿Y sobre los  preprocesadores de CSS - LESS o Sass?

Obviamente, no estamos tratando de dar respuestas a estas preguntas ahora, pero el punto es que todas las aplicaciones web consisten en componentes similares, pero los detalles de cada componente varían de proyecto a proyecto.


Los Componentes de WordPress

Como una aplicación web, WordPress es un ejemplo perfecto de cómo distintas tecnologías vienen juntas para formar una aplicación web:

  1. La Capa de la Base de Datos es una Base de Datos MySQL.
  2. La Capa de la Aplicación - que algunos considerarían WordPress en sí mismo - está escrita en PHP y se encarga de muchas de las operaciones fundamentales para la lectura y la escritura de los datos, mientras proporciona APIs para que los desarrolladores aprovechen aún más.
  3. La Capa de la Presentación utiliza CSS básico (al menos por ahora), HTML (con algunos temas que ahora usan HTML5), jQuery y con partes del tablero de administración que usan Backbone.js.

Así que esa es la arquitectura de WordPress, pero ¿qué pasa con los proyectos que queremos construir sobre la aplicación? ¿Cómo siguen la misma arquitectura?

Bien, recordemos que WordPress es una base - no un framework - por eso estamos sometidos a la arquitectura de WordPress por defecto. Esto no significa que no podamos incluir nuestras propias librerías en algunos casos, pero si influye la manera en la que están construidas nuestras aplicaciones y proyectos.

Hablaremos más acerca de las librerías, la extensibilidad y más dentro de poco, pero en primer lugar, es importante tener en cuenta que en tiempos donde el paradigma MVC (y el MVVM y otras variantes del Modelo, Vista, Lo que sea) está de moda, WordPress no sigue la Convención.

Hay discusiones a favor y en contra sobre el por qué puede ser algo bueno o malo, pero ese no es el propósito de este artículo. En su lugar, cabe simplemente señalar que WordPress utiliza un patrón de eventos, en lugar del panel modelo-vista-controlador.

Y para ello, vale la pena comprender cómo el modelo de eventos funciona para que tengas una idea clara de cómo trabajan los hooks de WordPress y cómo puedes cambiar lo que estás pensando sobre el MVC o cualquier otro paradigma que estés acostumbrado a usar, hacia cómo WordPress gestiona su información.


¿Qué Significa Ser Orientado a Eventos?

Antes de que echamos un vistazo a un ejemplo de una aplicación orientada a eventos, vamos a revisar lo que significa seguir el paradigma MVC.

  • En primer lugar, la vista es la presentación. El usuario ve información e interactúa con la interfaz de usuario.
  • A continuación, los controladores coordinan información hacia y desde el modelo y la vista. Responden a las acciones del usuario y recuperan la información desde el modelo y la conducen a la vista.
  • Después de eso, el modelo representa los datos en la base de datos. Esto se puede hacer de cualquier cantidad de maneras, pero una de las formas más populares es mapear los datos en la base de datos, en un modelo objeto-relacional para que los datos se representan en el formato de los objetos.

Todo el modelo MVC se ve así:

MVCMVCMVC
MVC

Ahora, las aplicaciones orientadas a eventos pueden tener algunos de los mismos componentes - es decir, tienen vistas y modelos o vistaa y los objetos de datos - pero no necesariamente tienen un controlador que coordina la información del front-end al back-end.

En cambio, la programación por eventos trabaja fuera de la premisa de "algo como sucedió". Por lo tanto el nombre para las acciones en la jerga de WordPress (por supuesto, también contamos con filtros, pero los cubriremos momentáneamente).

WordPress ofrece ganchos (hooks) que son literalmente puntos en ejecución en los cuales podemos introducir nuestras propias funcionalidades de manera que WordPress reconoce que "cuando este evento ocurra, necesito disparar estas funciones" donde estas funciones se definen como lo que sea que ofrezcamos.

La verdad es que los filtros funcionan del mismo modo, pero su propósito es diferente. En resumen, los filtros son acciones que sirven para la manipulación de datos (por ejemplo, anexar, anteponerle, quitar o actualizar el contenido) de alguna manera antes de regresar a la ejecución de la aplicación.

Así que ¿esto cómo se ve?

EventsEventsEvents
Eventos

¿Nada terriblemente complicado, de acuerdo?


¿Entonces cuál es nuestra nueva arquitectura?

El punto de este artículo es conseguir principalmente que pensemos en términos de programación orientada a eventos y cómo coordinamos nuestros esfuerzos de construir aplicaciones web en WordPress.

Es decir que es importante pensar en términos de eventos o el hecho de que "algo ha sucedido" para que sepamos cuándo insertar adecuadamente nuestras propias acciones. Vamos a hablar un poco más de esto en detalle en el próximo artículo, pero el punto principal que quiero que tomen de este artículo es que sólo porque algo no sea MVC (o cualquiera que sea el próximo paradigma popular) no significa que no sea adecuado para el desarrollo de aplicaciones.

Cada patrón y arquitectura nos brinda ventajas y desventajas que pueden contribuir al éxito de la construcción de una aplicación web.


A continuación...

A continuación en esta serie, daremos una mirada más detallada en cómo los hooks juegan un papel vital en la construcción de aplicaciones web en WordPress, y luego empezaremos a mirar algunas de las instalaciones que WordPress ofrece fuera-de-la-caja que la hacen una opción sólida para ciertos tipos (Leáse: no todos los tipos) de aplicaciones web.

Advertisement
Did you find this post useful?
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.