Uno de los temas que periódicamente aparece en las discusiones en lo que se refiere a 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 de ejemplo: 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 amo el 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.
Por último, un conjunto de reglas de reescritura dieron la aplicación de un conjunto de direcciones URL limpia predecibles en el formato de/personas/actualización/o 1/personas/all. ¿Qué patrón implementa WordPress?
WordPress implementa la arquitectura controlada por eventos (de la que existen varias variaciones, como el Patrón de observador).
En resumen, se puede conceptualmente pensar en esto como el siguiente:
Things happen when WordPress is processing information.
You can register your own function to fire when these things happen.
No
demasiado complicado, ¿verdad? Un ejemplo de alto nivel de los patrones basados en eventos 
Un ejemplo de alto nivel de los patrones basados en eventos
Cuando se empieza a pensar en términos de paradigma en el que funciona en lugar de tratar de hacer que funcione el forma en 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 basado en 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 terminar su trabajo, y así terminar encontrándose tan arriba en la atmósfera del software que efectivamente se ha convertido en una arquitectura astronauta. ¿Así que está diciendo Evitar patrones de diseño?
¡Nada! 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 estoy tratando 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.
de guía (y totalmente copiado: P) de: http://tommcfarlin.com/wordpress-and-mvc/
MVC es un patrón de diseño arquitectónico e independiente del tipo de descargas. Cualquier plataforma de blogs, CMS o framework de desarrollo podría ser MVC, dependiendo de cómo esté estructurada. – eKek0
eKek0, pensé que sí. Pero bueno, debería haber algunos ejemplos de CMS y frameworks que no son compatibles con MVC, es decir, su arquitectura central no es MVC en absoluto. ¿Podrías pensar en alguno? – kovshenin