themosis model-view-controller wordpress

model view controller - themosis - ¿Cumple WordPress MVC?



themosis documentation (9)

Algunas personas consideran que WordPress es una plataforma de blogs, algunos piensan que es un CMS, algunos se refieren a WordPress como un marco de desarrollo. Cualquiera que sea, la pregunta aún permanece. ¿Cumple WordPress MVC?

He leído los foros y alguien me preguntó acerca de MVC hace unos tres años. Hubo algunas respuestas positivas y algunas negativas. Aunque nadie sabe exactamente qué es MVC y todos lo piensan a su manera, todavía hay un concepto general presente en todas las discusiones.

Tengo poca experiencia con frameworks MVC y no parece haber nada sobre el framework en sí. La mayor parte del MVC lo hace el programador, ¿estoy en lo cierto? Ahora, volviendo a WordPress, ¿podríamos considerar el motor de reescritura principal (WP_Rewrite) del controlador? ¿Las consultas y la lógica del complemento como modelo? Y los temas como la vista? ¿O lo estoy entendiendo todo mal?

Gracias ;)

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 la lógica de la aplicación no es inevitablemente MVC. Una implementación del patrón MVC usualmente asume un tipo de paradigma de programación orientado a objetos detrás de él y Wordpress se implementa principalmente de forma procedural, con consultas SQL simples en las funciones de PHP, por lo tanto, tampoco tiene un modelo real.

Está lejos de mvc, no hay nada como dicen algunos, es MVC o no ... El hecho de que se escriba lógica en el nivel de vista no lo califica como un marco de mvc. La razón por la que la gente lo usa es fácil de aprender, no necesitas ser un programador de php duro, son flojos.

Solo para agregar a la lista de opciones (estoy swpMVC sesgado como autor), swpMVC es un framework MVC liviano con todas las funciones, inspirado en Rails, Sinatra, Express y FuelPHP. Está completamente documentado, y aunque he usado y disfrutado http://wordpress.org/extend/plugins/wp-mvc/ , quería algo en que los modelos pudieran poblar las vistas, incluidos los controles de formulario para interactuar con dichos modelos.

Lo armé en gran medida 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 eficaz que se ejecuta dentro de WordPress. Los modelos se basan en PHP Activerecord y se incluyen 8 modelos para los tipos de datos de WordPress existentes, incluidos Post, PostMeta, User, UserMeta, Term y algunos más. Modelar datos es muy fácil gracias a la biblioteca activerecord, y he disfrutado trabajar con este framework inmensamente hasta el momento.

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

Tuve una oportunidad recientemente de crear un complemento que hace uso de un sistema de control de vista simple, y me gustaron bastante los resultados, así que separé el material de la plantilla en su propio repositorio . Ofrece controladores basados ​​en objetos, pasando variables localmente a plantillas PHP, fragmentos de plantilla (plantillas dentro de plantillas) y componentes (fragmentos de plantilla con su propio subcontrolador). ¡Todo en dos clases pequeñas!

Por supuesto, escribí este código pensando que ningún otro desarrollador de WP había considerado el problema antes ;-) .

Uno de los temas que aparece periódicamente en las discusiones sobre 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 tratamos de hacer. Sí, es un patrón de diseño impresionante, y personalmente creo que se ajusta al modelo de aplicación web como un guante, 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 tenemos que 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 apalanca correctamente.

"¡Pero me encanta MVC!"

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

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 / people / update / 1 o / people / all. ¿Qué patrón implementa WordPress?

WordPress implementa la arquitectura impulsada por eventos (de los cuales hay varias variaciones, como el Patrón observador).

En resumen, puedes conceptualmente pensar en esto como lo siguiente:

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 impulsados ​​por eventos Un ejemplo de alto nivel de patrones impulsados ​​por eventos

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

La conclusión es la siguiente: WordPress implementa el patrón de diseño impulsado por eventos, por lo que incluso si termina por intentar implementar MVC, todavía tendrá que utilizar el sistema de enlace.

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

¡De ningún modo! Los patrones de diseño tienen un propósito porque, por encima de todo, básicamente nos dan soluciones a problemas resueltos previamente y comúnmente. ¡Usalos, usalos a ellos!

Pero el punto que trato de plantear es que no necesitamos intentar obligar a las cosas a ajustarse al patrón solo porque nos gusta el patrón. Ese no es su propósito. En su lugar, aproveche el patrón primario que implementa su plataforma de elección (en nuestro caso, es un patrón impulsado por eventos) y luego implemente patrones donde quepan (como la 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/

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

Soluciones WordPress MVC:

Subprocesos MVC en WordPress.org Ideas y Trac:

Wordpress es algo así como MVC. En todo caso, es un diseño de MVC de tipo pull, donde la vista ''extrae'' datos del modelo. Hace esto de una manera muy práctica, en lugar de usar muchos objetos diferentes, pero esto realmente hace que las plantillas de front-end sean más fáciles de escribir de muchas maneras.

Esto también le da a los puntos de vista un cierto grado de lógica de controlador (por lo tanto, el MVC algo así).

Vamos a ejecutar esto: Wordpress obtiene una URL. El núcleo de wordpress actúa como controlador y determina qué consultas iniciales se ejecutarán en 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.). A continuación, empaqueta esa respuesta de consulta INTIAL y la envía al archivo de vista.

Ese archivo de vista PUEDE ser un archivo de visualización estricta o puede solicitar información / consultas adicionales más allá de la incorporada. Este es el tipo de arrastre 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 código para cargar una barra lateral o área de widget, solicita esa información. Sin embargo, lo que los widgets deberían estar ahí está determinado por el controlador, que mira el modelo para ver 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 lo hace menos MVC. Puedes alterar el núcleo de WP sin alterar (necesariamente) nada sobre un tema. Del mismo modo, siempre que utilice funciones integradas como ''get_pages ()'', el modelo y las tablas de la base de datos podrían cambiar siempre que esas funciones devuelvan los datos correctos. Entonces, el modelo es independiente de la vista, y el controlador también es independiente (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 con varios métodos y cosas como WPModel :: get_pages (''blah blah''), y contener todo de esa manera, aún existe una separación fundamental de preocupaciones.

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

Mientras los nombres, argumentos, etc. permanezcan igual (o simplemente que se agreguen nuevos), entonces se mantiene la separación de las preocupaciones y se puede modificar una sin perturbar a las demás.

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

Y ser procesal al respecto no es algo malo. Una solicitud de un sitio web es bastante inherente procedural: es un proceso con un principio y un final claros, y solo necesita un procedimiento para procesar la solicitud, obtener datos, empaquetarlo 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 puede simplemente 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 hay una gran manera de hacer desarrollo, y WP se ubica en un 20% de sitios web, por lo que está haciendo algo bien. Probablemente tenga algo que ver con no hacer que las personas tengan que aprender / memorizar jerarquías complejas de clases para que la base de datos responda la pregunta ''¿qué páginas son secundarias para la página x?'' y tratar con esa información. ¿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.

RokkoMVC es un framework micro MVC construido especialmente para WordPress. El proyecto está destinado a simplificar la funcionalidad de AJAX en las aplicaciones de WordPress, así como a incorporar todos los demás beneficios de usar modelos, vistas y controladores a su tema.