¿Cumple WordPress MVC? [closed]

11 minutos de lectura

Algunas personas consideran que WordPress es una plataforma de blogs, algunos lo ven como un CMS, algunos se refieren a WordPress como un marco de desarrollo. Sea lo que sea, la pregunta sigue en pie. ¿Cumple WordPress MVC?

Leí los foros y alguien preguntó sobre MVC hace unos tres años. Hubo algunas respuestas positivas y otras negativas. Si bien nadie sabe exactamente qué es MVC y todos piensan en él a su manera, todavía hay un concepto general que está presente en todas las discusiones.

Tengo poca experiencia con marcos MVC y no parece haber nada sobre el marco en sí. La mayor parte del MVC lo realiza el programador, ¿verdad? Ahora, volviendo a WordPress, ¿podríamos considerar el motor de reescritura central (WP_Rewrite) como el controlador? ¿Consultas y lógica de complementos como modelo? Y temas como la vista? ¿O lo estoy entendiendo todo mal?

Gracias 😉

  • MVC es un patrón de diseño arquitectónico e independiente del tipo de software. Cualquier plataforma de blogs, CMS o marco de desarrollo podría ser MVC, dependiendo de cómo esté diseñado.

    – eKek0

    18 de mayo de 2010 a las 12:24


  • eKek0, pensé que sí. Pero bueno, debería haber algunos ejemplos de CMS y marcos que no cumplen con MVC, es decir, su arquitectura central no es MVC en absoluto. ¿Puedes pensar en alguno?

    – kovshenin

    18 de mayo de 2010 a las 12:39

avatar de usuario
usuario239974

WordPress en sí no está diseñado en MVC, pero uno puede construir temas y complementos muy orientados a MVC dentro del marco. Hay varias herramientas que pueden ayudar:

Soluciones WordPress MVC:

Subprocesos de MVC en WordPress.org Ideas y Trac:

  • Las ideas de MVC parecen ser muy impopulares: casi todas son rechazadas hasta la muerte.

    – Hexodus

    27 de octubre de 2013 a las 12:09

WordPress es una especie de MVC. En todo caso, es un diseño MVC de tipo pull, donde View ‘extrae’ datos del modelo. Hace esto de una manera muy procedimental, en lugar de usar muchos objetos diferentes, pero esto en realidad hace que las plantillas de front-end sean más fáciles de escribir de muchas maneras.

Esto también le da a las vistas cierto grado de lógica de controlador (por lo tanto, el tipo de MVC).

Analicemos esto: WordPress obtiene una URL. El núcleo de wordpress actúa como un controlador y determina qué consultas iniciales ejecutar de la base de datos y, por extensión, qué vista se debe cargar (vista de categoría, publicación única o vista de página, etc.). Luego empaqueta esa respuesta de consulta INTIAL y la envía al archivo de vista.

Ese archivo de vista PUEDE ser un archivo de solo visualización estricto O puede solicitar información/consultas adicionales más allá del integrado. Este es el tipo de extracción del MVC, donde la vista extrae datos del modelo en lugar de que el controlador “empuje” los datos del modelo a la vista.

Por lo tanto, cuando la vista ve el código para cargar una barra lateral o un área de widgets, solicita esa información. Sin embargo, los widgets que deben estar allí están determinados por el controlador, que busca en el modelo qué widgets hay en la barra lateral y luego selecciona aquellos que están configurados para mostrarse en la página actual y los devuelve a la vista.

Que cada parte de eso no sea un objeto no hace que esto sea menos MVC. Puede alterar el núcleo de WP sin (necesariamente) alterar nada sobre un tema. De manera similar, siempre que use funciones integradas como ‘get_pages ()’, el modelo y las tablas de la base de datos podrían cambiar siempre que esas funciones aún devuelvan los datos correctos. Por lo tanto, el modelo es independiente de la vista, y el controlador también lo es (excepto cuando la vista agrega lógica de controlador para hacer más de lo que normalmente hace el núcleo).

Si bien PODRÍA tener un objeto modelo que contenga una serie de métodos y cosas como WPModel::get_pages(‘blah blah’), y contener todo de esa manera, todavía hay una separación fundamental de preocupaciones.

Ver: archivos de plantilla Controlador: WP core Modelo: las diversas funciones que manejan el manejo de datos específicos.

Mientras los nombres, argumentos, etc., permanezcan iguales (o simplemente se agreguen otros nuevos), se mantiene la separación de preocupaciones y una puede modificarse sin molestar a las demás.

No es una versión súper limpia de MVC (especialmente cuando se involucran ganchos), pero en un nivel básico comienza allí.

Y ser procedimental al respecto no es algo malo, en mi opinión. Una solicitud de un sitio web es inherentemente procedimental: es un proceso con un comienzo y un final claros, y solo necesita un procedimiento para procesar la solicitud, obtener datos, empaquetarlos y luego morir. Puede configurar esos pasos con objetos y métodos de objetos y diseños OOP (lo que facilitaría algunas cosas) o simplemente puede escribir muchas llamadas a funciones y separarlas de esa manera. Los miembros de la clase, como las variables privadas, se pierden de esa manera, pero dependiendo de las necesidades de la aplicación… es posible que no le importe.

No existe una gran manera de hacer desarrollo, y WP se encuentra como en el 20% de los sitios web, por lo que está haciendo algo bien. Probablemente algo que tiene que ver con no hacer que las personas tengan que aprender/memorizar jerarquías de clases complejas para que la base de datos responda a la pregunta ‘¿qué páginas son secundarias de la página x?’ y tratar con esos datos. ¿Podrías hacerlo tan fácil con OOP? sí, pero si Joomla es un ejemplo de lo difícil que es implementar un sitio web personalizado complejo con OOP, entonces WP es MUCHO más fácil y rápido, y el tiempo es dinero.

  • Estoy comentando sobre mi propia escritura aquí. WordPress no es MVC por sí mismo. De hecho, los patrones de diseño a los que se acerca desde el primer momento definitivamente no son MVC en absoluto. Por lo general, uso los archivos de vista como page.php como un tipo de script de controlador (preparando variables, lógica comercial, etc. y hablando con la base de datos si es necesario) y luego cargo un archivo de vista separado, por ejemplo, page-view.php. Lo he estado haciendo de esa manera por un tiempo. Olvidé lo complicado que es el código WP normal hasta que miro las cosas demasiado complicadas que existen.

    – Brenn

    5 mayo 2014 a las 15:19

avatar de usuario
Narciso

Como ya se mencionó en los comentarios, MVC es un patrón de diseño arquitectónico, no un marco específico, y no, WordPress no sigue el patrón MVC.

Hay una separación de vistas (plantillas) de la lógica de programación, pero solo en la interfaz, no en el panel de administración y una separación general de vistas y lógica de aplicación no es inevitablemente MVC. Una implementación del patrón MVC generalmente asume algún tipo de paradigma de programación orientado a objetos detrás de él y WordPress es principalmente implementado de manera procedimental, con consultas SQL simples en las funciones de PHP, por lo que tampoco tiene un modelo real.

avatar de usuario
Raúl Balakrishna

Uno de los temas que surgen periódicamente en las discusiones en relación con WordPress es la idea de WordPress y MVC.

Pero la cuestión es que MVC no es la bala de plata del desarrollo web que intentamos que sea. Sí, es un patrón de diseño impresionante, y personalmente creo que se ajusta al modelo de aplicación web como anillo al dedo, pero no todos los marcos o plataformas implementan ese patrón de diseño.

Caso en cuestión: WordPress no es MVC.

Y eso está bien. Creo que debemos dejar de lado el deseo de tratar de calzarlo en nuestros proyectos, especialmente cuando el patrón que proporciona WordPress no solo es suficiente, sino que funciona bien cuando se aprovecha correctamente.

“¡Pero me encanta MVC!”

¡Yo también! De hecho, pasé el último año trabajando en un proyecto que imitaba más o menos la arquitectura MVC. Un ejemplo de alto nivel de MVC.

ingrese la descripción de la imagen aquí

Un ejemplo de alto nivel de MVC.

Por ejemplo:

Views were implemented using templates
Controllers were implemented by a combination of using function names like create, read, update, destroy, delete, and so on (even though these functions were hooked into the WordPress API
Models were functions also were called to validate and verify data prior to serializing the data. Again, this required that certain functions be hooked into WordPress to achieve the desired result.

Finalmente, un conjunto de reglas de reescritura le dio a la aplicación un conjunto limpio de URL predecibles en el formato de /personas/actualizar/1 o /personas/todos. ¿Qué patrón implementa WordPress?

WordPress implementa la arquitectura basada en eventos (de la cual hay varias variaciones, como el patrón Observer).

En resumen, puede pensar conceptualmente en esto de la siguiente manera:

Things happen when WordPress is processing information.
You can register your own function to fire when these things happen.

No es demasiado complicado, ¿verdad? Un ejemplo de alto nivel de patrones basados ​​en eventos
ingrese la descripción de la imagen aquí
Un ejemplo de alto nivel de patrones basados ​​en eventos

Cuando comienzas a pensar en términos del paradigma en el que funciona en lugar de tratar de hacer que funcione de la forma en que quieres que funcione, es liberador. Ayuda a resolver problemas mucho más fácilmente.

La conclusión es esta: WordPress implementa el patrón de diseño basado en eventos, por lo que incluso si termina intentando implementar MVC, aún tendrá que utilizar el sistema de enlace.

Si no tiene cuidado, puede terminar tratando de crear la arquitectura perfecta sin terminar su trabajo y, por lo tanto, terminar encontrándose tan alto en la atmósfera del software que efectivamente se ha convertido en un astronauta de la arquitectura. Entonces, ¿estás diciendo que evites los patrones de diseño?

¡De nada! Los patrones de diseño tienen un propósito porque, sobre todo, básicamente nos dan soluciones a problemas previamente resueltos. ¡Usalos, usalos a ellos!

Pero el punto que estoy tratando de hacer es que no necesitamos tratar de forzar las cosas para que encajen en el patrón solo porque nos gusta el patrón. Ese no es su propósito. En su lugar, aproveche el patrón principal que implementa su plataforma de elección (en nuestro caso, es un patrón basado en eventos) y luego implemente patrones donde encajen (como inyección de dependencia o algo así).

De lo contrario, es como tratar de poner el pie en un guante.

Cortesía (y totalmente copiada :P) de : http://tommcfarlin.com/wordpress-and-mvc/

Solo para actualizar esto con información más reciente para las personas que acceden a esto desde los motores de búsqueda: el complemento wp-mvc http://wordpress.org/extend/plugins/wp-mvc/ contribuye en gran medida a crear un marco mvc para el desarrollo de complementos. Puedes encontrar mas aqui: http://wpmvc.org/documentation/70/tutorial/

  • Se ve bien, pero las últimas actualizaciones de código tienen 2 años. ¿Sigue vivo este proyecto?

    – Hexodus

    27 de octubre de 2013 a las 12:01

avatar de usuario
Brian Zeligson

Solo para agregar a la lista de opciones (admito que soy parcial como autor) cambiarMVC es un marco MVC liviano y con todas las funciones, inspirado en Rails, Sinatra, Express y FuelPHP. Está completamente documentado, y aunque lo he usado y disfrutado wp-mvcquería algo donde los modelos pudieran completar las vistas por sí mismos, incluidos los controles de formulario para interactuar con dichos modelos.

Reuní esto en gran parte para reducir la cantidad de código de controlador necesario para armar una aplicación sobre WordPress, y el resultado es un marco muy rápido y efectivo que se ejecuta dentro de WordPress. Los modelos se basan en Registro activo de PHP y se incluyen 8 modelos para los tipos de datos de WordPress existentes, incluidos Post, PostMeta, User, UserMeta, Term y algunos más. El modelado de datos es muy fácil gracias a la biblioteca de registros activos, y hasta ahora he disfrutado muchísimo trabajando con este marco.

También se envía con guión bajo PHP y PHP Quick Profiler (como se ve en FuelPHP).

  • Se ve bien, pero las últimas actualizaciones de código tienen 2 años. ¿Sigue vivo este proyecto?

    – Hexodus

    27 de octubre de 2013 a las 12:01

avatar de usuario
rodrigo-silveira

RokkoMVC es un marco micro MVC creado especialmente para WordPress. El proyecto está destinado a simplificar la funcionalidad de AJAX en las aplicaciones de WordPress, además de brindar todos los demás beneficios del uso de modelos, vistas y controladores para su tema.

¿Ha sido útil esta solución?