Паттерн MVC и PHP, часть 2






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

PHP

Роутинг

Хотя в теории MVC должен отлично работать при разработке архитектуры любых систем, применительно к разработке веб-приложений обычно появляются некоторые дополнительные сложности. Первая проблема — это роутинг URLов. Роутинг это то, что не принималось во внимание, когда разрабатывался паттерн MVC, поскольку веба в то время попросту не существовало.

Итак, какие есть варианты решения проблемы роутинга? Один из вариантов решения состоит в том, чтобы заранее определить URL, на которые должно отзываться ваше приложение, и описать в базе данных или файле конфигурации необходимые для обработки каждого URL контроллер, модель и представление. Это вполне подходящее решение в случае, если вы разрабатываете статический веб-сайт вроде портфолио, где не требуется использование динамических URL. Ниже приведён пример кода, реализующий подобное решение:

Таким образом, URLы вашего приложения будут выглядеть так:

Приведённый выше пример MVC-системы загружает необходимую связку модель-представление-контроллер в зависимости от значения GET-параметра 'page'.

Хотя приведённых пример прост для понимания и реализации, всё же он обладает рядом недостатков. Самым очевидным и критическим является то, что приложение не готово к масштабированию, поскольку оно стеснено жёстко-закодированным набором обрабатываемых URL.

Немного изменив подход, можно отказаться от жёсткого определения в коде соответствий URLов классам MVC. Вместо этого можно использовать сам URL для определения соответствия модели, контроллера и представления, получив то, что называется динамическим роутингом.

В случае со статическим роутингом, реализованным в предыдущем примере, мы не можем динамически менять одну или более частей из связки модель-представление-контроллер для каждого URL, ведь они определены в коде. Избежать этого ограничения можно подобным образом:

Таким образом, теперь наше приложение будет принимать URL вида:

В параметре 'action' передаётся имя метода контроллера, который необходимо вызвать. Обратите особое внимание на то, что этот метод передаёт часть данных модели, которая в свою очередь определяет, какое представление и какое его действие (метод) использовать. Это может быть значение параметра 'action' или данные полученные контроллером, или что-либо другое. Важно одно: никогда не позволяйте контроллеру напрямую передавать данные в представление. Контроллер может работать только с моделью и пользовательским вводом.

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

Помимо прочего, динамический роутинг накладывает больше ответственности на контроллер, нежели в случае со статическим роутингом, который можно рассматривать как расширение традиционного MVC-паттерна. Однако, если вы приложите усилия для того, чтобы создать ясную реализацию контроллера, не помещая в него ничего лишнего, вы обязательно получите лучший результат, чем со статическим вариантом.

Если ко всему прочему воспользоваться паттерном Front Controller, то вы получите полный контроль над загрузкой данных во время обработки запроса. Alejandro Gervasio написал неплохую статью о паттерне Front Controller, освещающую основную идею паттерна в связке с концепцией MVC. Автор также рекомендует к ознакомлению сайт Tom Butler — идеальное чтиво для тех, кто желает разобраться в принципах построения системы динамического роутинга в контексте MVC.

DRY

Ключевым аргументом в пользу использования MVC является возможность ясной организации структуры создаваемой системы за счёт минимизации дублирования кода. Любой хороший разработчик придёт в ужас, увидев в исходных кодах одно и то же в разных местах. Практика построения чистого кода, повторно используя имеющиеся компоненты настолько, насколько это возможно, следует философии DRY — Don't Repeat Yourself.

Принцип DRY гласит: «каждая часть знания должна иметь единственное, непротиворечивое и авторитетное представление в рамках системы». Целью DRY является мотивировать разработчика проектировать и строить каждый аспект системы так, чтобы в результате получить логически организованное, гибкое и легко расширяемое решение. Если вы заметили, что дублируете код, расположенный в другой части системы, создайте метод, содержащий этот код, и используйте его вызов везде, где вам это потребуется. Таким образом вы сможете создать оптимальную систему, готовую использованию кэширования, что в свою очередь позволит сократить время её работы.

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

Темплейты

Слово «темплейт» может вызвать несколько вопросов у разработчиков, знакомых с существующими MVC веб-фреймворками, поскольку традиционно стало считаться, что темплейт — это часть представления. Как мы уже обсудили ранее, это утверждение неверно, если вы хотите вписаться в рамки паттерна MVC. В идеальном варианте представление получает данные от модели, которая уже выполнила всю необходимую обработку, то есть всё, что остаётся представлению — это выбрать нужный темплейт и передать данные. Какое бы решение вы ни выбрали, вы всегда должны помнить: в темплейте данные должны быть уже в полностью готовом для вывода виде. Никаких вычислений. Если ваш темплейт делает что-то с данными кроме того, что выводит их, вы где-то свернули не туда и нарушили один из базовых принципов MVC.

Чтобы было понятней, о чём речь, рассмотрим коротенький пример загрузки шаблона в представлении и передачи ему данных:

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

Заключение

Паттер MVC в своё время оказал большое влияние на процесс разработки десктоп-приложений. Он был и по сей день является горячей темой для обсуждения среди разработчиков. Споры разгораются тем больше, когда речь заходит об использовании его в контексте PHP-приложений, и это является хорошим знаком того, что PHP-разработчики тянутся к прекрасному, стараясь применять лучшие принципы в своей работе. Если вы всё ещё не знакомы с MVC, пожалуйста, потратьте немного своего драгоценного времени на его изучение. Вы не пожалеете!

Источник: SitePoint




Паттерн MVC и PHP, часть 2: 4 комментария

  1. Спасибо. Наконец-то порядок начинает наводиться в голове, а то на данный момент инфа в интернете, по данному паттерну, напоминает «бабушка надвое сказала». Жду новых статей по ООП и паттернам.

Комментарии запрещены.