Компонентный (блочный) подход

В предыдущей статье мы с Вами обсуждали отличный подход MVC. Отличный не с точки зрения практики применения, сколько с точки зрения самой концепции. И более развитым решением, которое уже очень часто применяется на практике, является компонентный (блочный) подход.

В компонентом подходе остаются всё те же 3 элемента: Model, View и Controller. Но очень важное отличие: в чистом MVC пользователь обращался к Controller, однако, гораздо логичнее обращаться к View. И как раз в компонентом подходе идёт обращение именно к указанному элементу.

Второй важнейшее отличие состоит в том, что Controller разбивается на несколько частей, компонентов, каждый из которых отвечает за свою часть. Например, блок с новостями, панель пользователя, блок с комментариями и так далее. Разумеется, вся обработка идёт в соответствующем блоке. Например, если нужно обработать добавление нового комментария, то эта обработка помещается в компонент, отвечающий за комментарии. А не всё в одну кучу, как это было в MVC (когда вся обработка отправлялась в 1 файл, controller.php).

Давайте с Вами разберём компонентный подход на примере из прошлой статьи. Начнём с файла index.php, принадлежащий Шаблону.

Теперь рассмотрим файл comments.php, отвечающий за комментарии:

Может показаться, что ничего не изменилось. Ведь остался тот же PHP-код в файлах Шаблона. Однако, нам удалось сделать так, чтобы дизайнер и только дизайнер решал, какие блоки и где выводить. Это очень значимый результат. Теперь дизайнер может в своём Шаблоне, взять весь этот код подключения комментариев и переставить в другое место или, например, вообще удалить. В то же время, если программист придумает какой-то более быстрый способ получения комментариев, он спокойно исправит Model, никак не изменяя View.

Данный способ идеален для небольших сайтов, например, сайтов-визиток. Однако, минусы у данного способа имеются:

• По-прежнему, остался PHP-код в Шаблоне.
• Для больших сайтов данный способ не подойдёт. Ведь у сайта есть множество повторяющихся элементов, например, шапка сайта (не просто одна картинка, а некоторая структура HTML-кода). И если потребуется изменить её, то потребуется менять все страницы вручную. А если их будет 1000?

В связи с этими минусами, были придуманы Шаблонизаторы, которые лишены этих двух минусов. Их существует большое количество, например, Smarty, но я Вам рекомендую создать свой. В любом случае, у каждого Шаблонизатора будут свои минусы. Например, наличие служебных конструкций в Шаблоне (именно служебных конструкций, а не PHP-кода), которые являются тем же кодом, просто в виде HTML-комментариев, который в Шаблонизаторе преобразуется в PHP-код. Либо если вынести всю обработку в Шаблонизатор, оставив идеально чистый Шаблон с только HTML-кодом без всяких служебных конструкций, то тогда придётся смириться с некоторой зависимостью программной части и внешнего вида. Это означает, если принципиально изменить вывод чего-либо (например, был выпадающий список, а теперь нужно вывести всё в теге <p>), то придётся изменять программную часть.

Но в любом случае, именно Шаблонизатор Вы и должны использовать для создания крупных проектов. Можете использовать уже готовый, прочитать документацию и использовать, а можете написать свой собственный, как это сделал я. Безусловно, он также не лишён недостатков. Но, кто знает, быть может именно Вы создадите идеальный Шаблонизатор, тем самым, мгновенно прославившись в кругу программистов.