Шаблон MVC и PHP, часть 2
Добро пожаловать во вторую часть этой серии из двух частей, в которой обсуждаются MVC и PHP, где мы обсудим некоторые соображения, которые необходимо учитывать при использовании архитектуры MVC. Если вы сразу пришли к этой статье, не прочитав сначала часть 1, я призываю вас вернуться и внимательно прочитать, так как этот будет предполагать, что вы прочитали и поняли все, что обсуждалось. Имея это в виду, давайте начнем!
Маршрутизация и URL
Хотя MVC, теоретически, должен работать безупречно во всех формах компьютерного программирования, включение MVC в Интернете с помощью PHP может быть немного сложнее. Первая проблема связана с маршрутизацией URL. Маршрутизация URL-адресов – это аспект, который никогда не рассматривался при создании MVC, и так как Интернет развивается и развивается с развитием технологий, то же самое следует делать и с шаблонами архитектуры, которые мы используем.
Итак, какие у нас есть варианты решения проблемы маршрутизации URL? Одним из решений является попытка выгрузить любые URL-адреса, которые нужны вашему сайту или веб-приложению, сохраняя их в постоянном хранилище вместе с информацией о том, какую модель, представление и контроллер следует загрузить для каждой страницы или раздела. Затем система получает URL-адрес, запрошенный пользователем, загружает определенные компоненты, назначенные для этой страницы, и начинает работать. Это идеальное решение, если вы создаете сайт-портфолио или статический сайт, который не использует динамические URL-адреса. Например:
$page = $_GET['page']; if (!empty($page)) $data = array( 'about' => array('model' => 'AboutModel', 'view' => 'AboutView', 'controller' => 'AboutController'), 'portfolio' => array('model' => 'PortfolioModel', 'view' => 'PortfolioView', 'controller' => 'PortfolioController') ); foreach($data as $key => $components) if ($page == $key) $model = $components['model']; $view = $components['view']; $controller = $components['controller']; break; > > if (isset($model)) $m = new $model(); $c = new $controller($model); $v = new $view($model); echo $v->output(); > >Наши URL будут выглядеть так:
example.com/index.php?page=about example.com/index.php?page=portfolio Пример системы MVC загружает определенный набор Model, View и Controller для запрашиваемой страницы. Если в параметре URL указано «about», отобразится страница «About». Если параметром является «портфолио», страница Портфолио будет вместо этого.
Это базовый пример статической маршрутизации, которая, даже несмотря на то, что она очень проста в настройке, имеет некоторые недостатки. Одним из наиболее очевидных недостатков является тот факт, что масштабируемость становится намного сложнее, поскольку широта вашего сайта ограничена жестко заданным массивом страниц.
Другой вариант – открыть назначение ваших классов Model, View и Controller и позволить URL-адресу определить эти параметры. В примере статической маршрутизации мы просто извлекали идентификацию класса из массива, который, в свою очередь, действовал как данные маршрутизации, поступающие из нашего постоянного хранилища. Замена массива элементами превращает нашу статическую маршрутизацию в динамическую маршрутизацию.
Несмотря на то, что мы извлекли ключ для каждой ассоциации в массиве с переменной URL, отношения с соответствующими классами уже были предопределены; мы не могли смешивать и сопоставлять значения в каждом ключе со статической маршрутизацией. Но зачем нам это делать? Ну, во-первых, нам не нужно было бы жестко кодировать каждый раздел нашей системы. Мы можем создавать разделы или страницы только путем создания отношений Модель, Представление и Контроллер. Например:
$model = $_GET['model']; $view = $_GET['view']; $controller = $_GET['controller']; $action = $_GET['action']; if (!(empty($model) || empty($view) || empty($controller) || empty($action))) $m = new $model(); $c = new $controller($m, $action); $v = new $view($m); echo $v->output(); >Наш новый URL теперь будет выглядеть так:
example.com/index.php?controller=controllername↦model=modelname&view=viewname&action=actionname Переменная URL действия сообщает системе, какую функцию в контроллере выполнить. Важно помнить, что когда эта функция передает данные в модель, она передает часть данных в модель, которая, в свою очередь, указывает, какое действие просмотра и просмотра загрузить. Это может быть переменная URL-адреса действия, но она также может быть отдельной, или данные, собираемые контроллером. Не забудьте никогда не позволять Контроллеру загружать или напрямую передавать данные в Представление; он должен взаимодействовать только с моделью и входами пользователя.
Оба подхода имеют свои плюсы и минусы: статическая маршрутизация является более стабильной, быстрее внедряется и дает разработчикам больший контроль над системой, а динамическая маршрутизация позволяет нам создавать более эффективную систему с огромным потенциалом для масштабируемости и переносимости.
Однако динамическая маршрутизация может возложить на контроллер больше ответственности, чем статическая маршрутизация, что можно рассматривать как изменение традиционного шаблона MVC. Тем не менее, если динамическая маршрутизация реализована правильно и эффективно, это может сделать контроллер более желательным в системе по сравнению с использованием статической маршрутизации.
Добавление Front Controller позволит вашей системе динамически загружать разделы, в зависимости от того, что вы хотите загрузить. Алехандро Жервасио написал фантастическую статью из двух частей о шаблоне Front Controller , в которой рассматриваются идеи использования Front Controller с элементами MVC. Я настоятельно рекомендую это для всех, кто хочет узнать больше о Front Controllers и MVC. Я также рекомендую быстро посетить сайт Тома Батлера, поскольку у него есть статья, в которой рассматривается внедрение Front Controller в его отношения «1.1 Controller: View», что идеально подходит для тех, кто хочет разработать настоящее решение динамической маршрутизации в своей системе MVC.
СУХОЙ (не повторяйся) и шаблоны
Одним из моих главных аргументов в пользу использования шаблона MVC является цель сделать вашу систему в целом максимально организованной. Наиболее очевидный способ сделать это – уменьшить количество возможностей иметь несколько экземпляров одного и того же кода. Любой разработчик согласится, что худшее, что можно найти в любом приложении, – это повторение одного и того же кода. Практика оптимизации вашего кода и максимально возможного использования повторно используемых компонентов известна как философия СУХОГО – не повторяйте себя.
Принцип DRY гласит, что «каждая часть знаний должна иметь одно, однозначное, авторитетное представление в системе». Цель DRY – расширить и изучить все возможные пути, открытые для разработчиков, чтобы сделать их систему максимально динамичной и оптимизированной. Принцип СУХОЙ подразумевает, что, если вам нужно написать один и тот же кусок кода во многих местах, вместо того, чтобы повторять код в этих местах, создайте отдельный метод и используйте его везде, где это необходимо. Это позволяет системе стать более оптимизированной и предоставляет возможность кэширования в наших системах, чтобы помочь улучшить общее время выполнения.
Правильная реализация DRY подразумевает, что изменение одного элемента системы не изменяет несвязанные элементы, что делает DRY важным принципом, с которым нужно работать при разработке с использованием шаблонов MVC.
Шаблоны
Слово «шаблон» может вызвать несколько вопросов у тех, кто раньше видел веб-фреймворки MVC, так как большинство людей смешивают часть шаблона с представлением. Как мы уже говорили ранее, это неверно, если вы хотите придерживаться традиционного шаблона MVC. В идеале, вы должны иметь представление, занимающееся обработкой и обработкой данных после сбора данных из модели. Поэтому для вашего компонента View имеет смысл только выбрать шаблон и передать данные из View в этот шаблон. Таким образом, он готов к отображению с использованием макета блочного кода или с помощью echo, print или любого другого выходного кода в PHP. Какой бы метод вы ни выбрали, главное помнить, что ваши данные ДОЛЖНЫ быть в состоянии готовности, когда вам нужно только распечатать данные в шаблоне. Если вы выполняете другие операции обработки или обработки данных в шаблоне, ваши настройки неверны, и, скорее всего, установка MVC неверна.
Вот быстрый пример вашего представления, загружающего шаблон и помещающего в него данные:
class Model public $tstring; public function __construct() $this->tstring = "The string has been loaded through the template."; $this->template = "tpl/template.php"; > > class View private $model; public function __construct($model) $this->controller = $controller; $this->model = $model; > public function output() $data = ""
. $this->model->tstring .""; require_once($this->model->template); > > html> head> meta charset="charset=utf-8"> title>The Template nametitle> head> body> h1> echo $data; ?>h1> body> html>Кроме того, шаблон передается через модель, что в принципе может позволить динамическое назначение шаблонов в зависимости от того, что должен делать каждый конкретный вид. Этот метод шаблонирования позволяет эффективно и уверенно расширять системы MVC, давая нам возможность отделить внутреннюю разработку от внешней. оригинальная цель паттерна MVC.
Вывод
Шаблон MVC изменил правила игры, когда впервые использовался для программирования на рабочем столе. Это была и остается дискуссионной темой между разработчиками в отношении интерпретации определенных сценариев при ее разработке. Дискуссия становится еще более интенсивной, когда вы добавляете в смесь PHP и Интернет, что является фантастическим признаком того, что все больше и больше разработчиков сосредоточиваются на улучшении дисциплин разработки для PHP.
MVC является личным фаворитом благодаря поощрению разделения между различными обрабатывающими частями и возможности разделения между передним концом и задним концом. Я умоляю любого, кто раньше не разрабатывал с MVC, особенно на PHP, погрузиться в эту замечательную модель разработки; ты не будешь разочарован.
Комментарии к этой статье закрыты. У вас есть вопрос о MVC Patterns и PHP? Почему бы не спросить об этом на наших форумах ?
Шаблоны в MVC на PHP
Представления, которые мы с вами изучали в предыдущем уроке, на самом деле представляют собой контент страницы. Кроме контента, на странице, как правило, есть еще хедер, сайдбары, футер. Эти части обычно одинаковые на всех страницах сайта.
В нашем фреймворке каждая страница сайта представляет собой один и тот же HTML файл шаблона, к которому для каждой страницы сайта подключается в заданное место контент страницы из представления.
Файл с шаблоном размещается по следующему пути: /project/layouts/default.php . Согласно правилам фреймворка, в этом файле доступна переменная $content . В том месте, где будет выведена эта переменная и произойдет вставка контента страницы.
По умолчанию этот файл содержит следующий простейший код:
Разместите в файле с шаблоном вот такой макет сайта:
Зайдите на любое действие любого контроллера. Посмотрите, что поменялось.
Тайтл страницы
В файле шаблона также доступна переменная $title , содержащая тайтл страницы. Очевидно, что этот заголовок также будет разным для различных страниц. Давайте используем эту переменную по назначению:
Для того, чтобы задать тайтл для определенного представления необходимо в контроллере записать его в свойство title :
Модифицируйте файл шаблона и все ваши контроллеры так, чтобы для каждого представления выводился свой тайтл.
Пусть в контроллере Page дан следующий массив:
pages = [ 1 => [‘title’=>’страница 1’, ‘text’=>’текст страницы 1’], 2 => [‘title’=>’страница 2’, ‘text’=>’текст страницы 2’], 3 => [‘title’=>’страница 3’, ‘text’=>’текст страницы 3’], ]; ?>
Сделайте действие show , которое будет выводить заданную страницу. Пусть в представлении текст страницы из ключа ‘text’ будет обернут в абзац, а текст из ключа ‘title’ станет тайтлом страницы.