Es compatible con WordPress MVC? [cerrado]

Wordpress es algo así como MVC. Si algo es un diseño MVC de tipo PULL, donde la vista 'extrae' datos del modelo. Lo hace de una manera muy proceedural, 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 MVC kinda-sorta).

Veamos 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 debe cargarse (vista de categoría, vista de publicación única o página, etc.). Luego empaqueta esa respuesta de consulta INICIAL y la envía al archivo de vista.

Ese archivo de vista PUEDE ser un archivo estricto de solo visualización O puede solicitar información/consultas adicionales más allá del construido en uno. 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 widget, solicita esa información. Sin embargo, lo que los widgets deben estar allí está determinado por el controlador, que mira el modelo para qué widgets están en la barra lateral, y luego selecciona los 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 WP core sin (necesariamente) alterar nada sobre un tema. Del mismo modo, siempre y cuando use funciones integradas como 'get_pages ()', entonces el modelo y las tablas de la base de datos podrían cambiar siempre y cuando esas funciones aún devuelvan los datos correctos. Por lo tanto, 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 el núcleo normalmente hace).

Mientras QUE usted PODRÍA tener un objeto modelo que contiene un número de métodos y cosas como WPModel:: get_pages ('bla bla'), 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 nuevos), entonces se mantiene la separación de preocupaciones y una puede ser alterada sin molestar a las otras.

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

Y ser proceedural al respecto no es algo malo IMO. Una solicitud de un sitio web es bastante inherentemente proceedural: es un proceso con un principio 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 objeto y diseños de 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... puede que no te importe.

No hay una gran manera de hacer el desarrollo, y WP se encuentra como en el 20% de los sitios web, por lo que está haciendo algo bien. Probablemente algo que ver con no hacer que la gente tenga que aprender/memorizar jerarquías de clases complejas para que la base de datos responda a la pregunta '¿qué páginas son hijas 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 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.

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 el frontend, 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 generalmente asume algún tipo de paradigma de programación orientada a objetos detrás de él y Wordpress es principalmente implementado de manera procedimental, con consultas SQL simples en las funciones PHP, por lo tanto no tiene un modelo real tampoco.

Solo para actualizar esto con información más reciente para las personas que golpean esto desde los motores de búsqueda - el plugin wp-mvc http://wordpress.org/extend/plugins/wp-mvc / va un largo camino para crear un marco mvc para el desarrollo de complementos. Puedes encontrar más información aquí: http://wpmvc.org/documentation/70/tutorial /

Uno de los temas que surgen periódicamente en las discusiones en lo que se refiere a WordPress es la idea de WordPress y MVC.

Pero la cosa es que MVC no es la bala de plata del desarrollo web que tratamos de hacer que sea. 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.

Ejemplo: WordPress no es MVC.

Y eso es Vale. 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 aprovecha 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 dio a la aplicación un conjunto limpio de URLs predecibles en el formato de / people / update /1 o/people / all. ¿Qué Patrón Implementa WordPress?

WordPress implementa la arquitectura impulsada por eventos (de la cual hay varias variaciones como el Patrón Observer).

En resumen, conceptualmente se puede 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 hacer que funcione de la manera 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 impulsado por eventos, por lo que incluso si terminas tratando de implementar MVC, todavía vas a tener que utilizar el sistema de gancho.

Si no tienes cuidado, puedes terminar tratando de crear el arquitectura perfecta sin hacer su trabajo, y por lo tanto termina encontrándose tan alto en la atmósfera del software que efectivamente se ha convertido en un astronauta de la arquitectura. ¿Estás Diciendo Que Evites Los Patrones De Diseño?

¡Para nada! Los patrones de diseño tienen un propósito porque, por encima de todo, básicamente nos dan soluciones a problemas previamente y comúnmente resueltos. ¡Úsalos!

Pero el punto que estoy tratando de hacer es que no necesitamos tratar de forzar las cosas para que encajen 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 impulsado por eventos) y luego implemente patrones donde encajan (como la inyección de dependencias o algo por el estilo).

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

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

Solo para agregar a la lista de opciones, (admito que estoy sesgado como el autor,) swpMVC es un framework MVC ligero y con todas las funciones, inspirado en Rails, Sinatra, Express y FuelPHP. Está completamente documentado, y aunque he utilizado y disfrutado wp-mvc, quería algo donde los modelos fueran capaces de poblar las vistas por sí mismos, incluidos los controles de formulario para interactuar con dichos modelos.

Junté esto en gran medida para reducir la cantidad de código del controlador necesario para armar una aplicación en la parte superior de 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 mucho trabajando con este framework hasta ahora.

También incluye PHP de subrayado y PHP Quick Profiler (como se ve en FuelPHP.)

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

Recientemente tuve una fiesta en la creación de un plugin que hace uso de un simple sistema de controlador de vista, y me gustaron los resultados, así que separé el material de la plantilla a su propio repositorio. Ofrece controladores basados en objetos, pasando variables localmente a plantillas PHP, fragmentos de plantillas (plantillas dentro de plantillas) y componentes (fragmentos de plantillas con su propio subcontrolador). Todos en dos pequeñas clases!

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

Está lejos de mvc, no hay un poco-sorta cosa como algunas personas dicen, es MVC o no... El hecho de que escriba lógica en el nivel de vista no lo califica como un marco mvc. La razón por la que la gente lo usa - es fácil de aprender, no es necesario ser un programador de php hardcore, son perezosos.