Соответствует ли WordPress MVC?

Wordpress - это своего рода MVC. Во всяком случае, это макет MVC с pull-type, где View 'pulls' данные из модели. Он делает это очень боеспособным способом, вместо использования множества разных объектов, но это фактически упрощает запись шаблонов на лицевой панели многими способами.

Это также дает представлениям некоторую степень логики контроллера (таким образом, sorta-sorta MVC).

Позволяет выполнить это: Wordpress получает URL-адрес. Ядро wordpress действует как контроллер и определяет, какие начальные запросы для запуска базы данных и по расширению, какой вид должен быть загружен (просмотр категории, одно сообщение или просмотр страницы и т.д.). Затем он отправляет этот запрос INTIAL и отправляет его в файл вида.

Этот файл просмотра может быть строгим отображением только файла или он может запрашивать дополнительную информацию/запросы за пределами встроенного. Это тип pull-типа MVC, в котором представление выводит данные из модели вместо того, чтобы "выталкивать" данные контроллера из модели в представление.

Таким образом, когда вид видит, что код загружает боковую панель или область виджетов, он запрашивает эту информацию. Тем не менее, какие виджеты должны быть там, определяется контроллером, который смотрит на модель, какие виджеты находятся на боковой панели, а затем выбирает те, которые установлены для отображения на текущей странице, и возвращает их в представление.

То, что каждая часть этого объекта не является объектом, не делает это менее MVC. Вы можете изменить ядро ​​WP без (обязательно) изменения чего-либо о теме. Аналогично, до тех пор, пока вы используете встроенные функции типа "get_pages()", модель и таблицы базы данных могут измениться, пока эти функции по-прежнему возвращают правильные данные. Таким образом, модель не зависит от представления, а контроллер также независим (кроме случаев, когда представление добавляет логику контроллера, чтобы делать больше, чем обычно делает ядро).

В то время как у вас есть модельный объект, содержащий несколько методов и т.д., таких как WPModel:: get_pages ( "бла-бла" ), и содержать все таким образом, все еще существует принципиальное разделение проблем.

Просмотр: файлы шаблонов Контроллер: ядро ​​WP Модель: различные функции, которые обрабатывают конкретную обработку данных.

Пока имена, аргументы и т.д. остаются неизменными (или просто добавляются новые), то разделение проблем сохраняется и можно изменять, не нарушая других.

Это не супер-чистая версия MVC (особенно когда задействованы крючки), но на базовом уровне она начинается там.

И быть продолжением об этом не плохо, ИМО. Запрос с веб-сайта довольно по своей сути является продолжением: это процесс с четким началом и концом, и ему просто нужна процедура для обработки запроса, получения данных, упаковки, а затем умения. Вы можете настроить эти шаги с помощью объектов и методов объектов и макетов OOP (что упростит некоторые вещи), или вы можете просто написать много вызовов функций и разделить их таким образом. Члены класса, такие как частные переменные, теряются таким образом, но в зависимости от потребностей приложения... вам может быть безразлично.

Существует не один-единственный способ сделать разработку, и WP сидит на 20% веб-сайтов, поэтому он делает что-то правильно. Вероятно, что-то связано с тем, что люди не должны изучать/запоминать сложные иерархии классов, чтобы получить базу данных, чтобы ответить на вопрос "какие страницы являются дочерними страницами страницы x?" и справиться с этими данными. Не могли бы вы сделать это с ООП? да, но если Joomla - это пример того, как сложно реализовать сложный пользовательский веб-сайт с ООП, тогда WP будет быстрее и быстрее, а время - деньги.

Как уже упоминалось в комментариях, MVC представляет собой архитектурный шаблон проектирования, а не определенную структуру, и нет, Wordpress не соответствует шаблону MVC.

Существует разделение представлений (шаблонов) от логики программирования, но только в интерфейсе, а не в панели администратора, а общее разделение представлений и логики приложения не обязательно связано с MVC. Реализация шаблона MVC обычно предполагает какую-то парадигму объектно-ориентированного программирования, а Wordpress в основном реализуется процедурно, с обычными SQL-запросами в PHP-функциях, поэтому не имеет реальной модели.

Просто обновить эту информацию с помощью новейшей информации для людей, попавших в нее из поисковых систем - плагин wp-mvc http://wordpress.org/extend/plugins/wp-mvc/ проходит долгий путь к созданию структуры mvc для разработки плагинов. Вы можете узнать больше здесь: http://wpmvc.org/documentation/70/tutorial/

Одной из тем, периодически возникающих в дискуссиях по отношению к WordPress, является идея WordPress и MVC.

Но дело в том, что MVC - это не серебряная пуля веб-разработки, которую мы пытаемся сделать. Да, это потрясающий шаблон дизайна, и я лично считаю, что он подходит для модели веб-приложений, как перчатка, но не каждая платформа или платформа реализует этот шаблон дизайна.

Пример: WordPress не MVC.

И все в порядке. Мне кажется, нам нужно оставить желание попытаться отбросить его в наши проекты, особенно если шаблон WordPress не только достаточен, но и хорошо работает при правильном использовании.

"Но я люблю MVC!"

Так и я! Фактически, я провел последний год, работая над проектом, который более или менее имитировал архитектуру MVC. Высокоуровневый пример MVC.

Высокоуровневый пример MVC.

Например:

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.

Наконец, набор правил перезаписи дал приложению чистый набор прогнозируемых URL-адресов в формате /people/update/ 1 или/people/all. Какой шаблон использует WordPress?

WordPress реализует управляемую событиями архитектуру (из которой существует несколько вариантов, таких как шаблон Observer).

Короче говоря, вы можете концептуально подумать об этом как о следующем:

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

Не слишком сложно, не так ли? Высокоуровневый пример управляемых событиями шаблонов Высокоуровневый пример шаблонов, управляемых событиями

Когда вы начинаете думать в терминах парадигмы, в которой она работает, а не пытаться заставить ее работать так, как вы хотите, чтобы она работала, ее освобождение. Это помогает решать проблемы намного легче.

Суть в следующем: WordPress реализует шаблон дизайна, управляемый событиями, поэтому даже если вы попытаетесь реализовать MVC, вам все равно придется использовать систему hook.

Если вы не будете осторожны, вы можете в конечном итоге попытаться создать идеальную архитектуру, не выполнив свою работу, и, таким образом, окажетесь так высоко в атмосфере программного обеспечения, что вы фактически станете астронавтом архитектуры. Итак, Youre Saying Избегайте шаблонов дизайна?

Совсем нет! Шаблоны проектирования служат целям, потому что, прежде всего, они в основном дают нам решения ранее и часто решаемых проблем. Используйте их!

Но точка, которую я пытаюсь сделать, заключается в том, что нам не нужно пытаться заставить вещи соответствовать шаблону только потому, что нам нравится шаблон. Это не их цель. Вместо этого используйте основной шаблон, который реализует ваша платформа выбора - в нашем случае - шаблон, управляемый событиями, и затем реализуйте шаблоны, где они подходят (например, инъекция зависимостей или что-то в этом роде).

В противном случае это похоже на попытку поставить ногу в перчатку.

Предоставлено (и полностью скопировано: P) из: http://tommcfarlin.com/wordpress-and-mvc/

Просто добавьте в список вариантов (я, по общему признанию, предвзятый, как автор) swpMVC - полнофункциональный, легкий MVC рамки, вдохновленные Rails, Sinatra, Express и FuelPHP. Он полностью задокументирован, и пока я использовал и наслаждался wp-mvc, мне хотелось, чтобы модели могли сами заполнить представления, включая элементы управления формой для взаимодействия с указанными моделями.

Я объединил это в основном для уменьшения количества кода контроллера, необходимого для создания приложения поверх WordPress, и результатом является очень быстрая и эффективная структура, которая работает внутри WordPress. Модели основаны на PHP Activerecord и 8 моделей включены для существующих типов данных WordPress, включая Post, PostMeta, User, UserMeta, Term и еще несколько. Моделирование данных очень легко благодаря библиотеке activerecord, и мне очень понравилось работать с этой картой до сих пор.

Также поставляется с подчеркиванием PHP и PHP Quick Profiler (как показано в FuelPHP.)

RokkoMVC - это микро-MVC-инфраструктура, созданная специально для WordPress. Проект призван упростить функциональность AJAX в приложениях WordPress, а также использовать все другие преимущества использования моделей, представлений и контроллеров для вашей темы.

Недавно я создал bash при создании плагина, который использует простую систему управления представлением, и мне очень понравились результаты, поэтому я отделил материал шаблона в свое собственное репо. Он предлагает объектно-ориентированные контроллеры, локально передавая переменные в шаблоны PHP, фрагменты шаблонов (шаблоны в шаблонах) и компоненты (фрагменты шаблонов с собственным подконтролем). Все в двух крошечных классах!

Конечно, я написал этот код, думая, что ни один другой разработчик WP не рассмотрел проблему до ;-).

Это далеко не mvc, нет ничего рода, вроде некоторых, скажем, это либо MVC, либо нет... Тот факт, что вы пишете логику на уровне представления, не квалифицирует ее как структуру mvc. Причина, по которой люди это используют - это легко учиться, вам не нужно быть хардкорным программистом php, они ленивы.