php mvc простой пример
Пример MVC в php. Вторая статья. Маршрутизация, контролеры, экшены, шаблоны и модели
Содержание цикла статей:
Теперь можно проверять работу перенаправления, введите любой адрес и посмотрите, что получиться: test-mvc.web/sdf/sdf/ или test-mvc.web/sdf/sdf/2342/не важно, на экране в любом случае, должно появиться «Test». Если Вы увидели эту надпись, значит, у нас все получилось.
Продолжим, давайте для удобства создадим в корне сайта файл config.php, в котором будем задавать различные константы, облегчающие своим существование настройку сайта. Это могут быть различные пути к скриптам, подступы к базе данных и так далее. Сейчас в конфиге давайте зададим следующее:
Класс хранилища Registry.php, будет находиться в папке /classes/
Код файла router.php, который находиться в папке /classes/
Теперь необходимо создать папки для хранения контроллеров, шаблонов и моделей – в корне создадим три папки controllers, views и models. И создадим несколько тестовых файлов /controllers/index.php, /views/index/index.php и /models/model_users.php, а теперь заполним файлы:
Для контроллера:
Как вы могли заметить, класс контролера наследуется от родительского класса Controller_Base. Это сделано, для того, чтобы упростить класс контролера. Поскольку нам еще необходимо подключать класс для работы с шаблонами, его подключение вынесено в Controller_Base.
Приведу его код, он расположен в папке /classes/ и называется controller_base.php :
Теперь осталось только разобраться с шаблонами. В абстрактном классе Controller_Base мы вызываем класс Template и передаем ему имя шаблона и имя контроллера.
Код класса Template, который лежит тут /classes/ и называется template.php
Если вы внимательно прочитали код, то наверняка поняли, что для отображения на страницах у нас используется шаблон first_layouts и вьюха(отображение) index.php – ее код я приводил чуть выше. Все что нам осталось, это создать файл шаблона first_layouts. Расположим его в папке /views/layouts/first_layouts.php
Шаблон будет содержать вот такой код:
Вот и все, на этом создание «каркаса» закончено. Сейчас у нас получилась самая простая структура, использующая в своей основе паттерн MVC. В этой статье я не стал затрагивать работу с базой данных, только вскользь упомянул ее, поскольку статья и так получилась большая. Непосредственно работу с базой данных я опишу в следующей статье.
На этом статья закончена, скачать исходники можно архивом тут.
MVC для новичков на примере маленького информационного сайта (без использования ООП)
Как и все начинающие Web разработчики сначала я изучал HTML потом CSS. Поскольку я сторонник мнения того что лучшее обучение — это практика, то тут же практиковал создание маленького информационного сайта путем выученных технологий. Когда же я перешел к изучению PHP, то столкнулся с небольшой проблемой: как его применять на практике, для продолжения создания моего сайта? Конечно первым делом я переименовал Index.html в Index.php, и разбил его на различные файлы *.php которые просто содержали контент блоков html. Но когда дело дошло до работы с базой данных — то уже начинало получаться как-то не очень красиво, и я решил посмотреть вообще на логику (архитектуру) построения CMS систем. Наиболее понятной для меня стала архитектура MVC. Я тут же решил взяться за ее освоение на практике. Но поскольку все (даже самые простенькие) примеры построения CMS с использованием MVC были написаны с применением ООП, то мои потуги что-то понять, заканчивались на разборе кода работы роутера. И тогда я решил сделать свою маленькую CMS систему с применением концепции MVС, но на уровне процедурного стиля программирования. Уж очень хотелось «пощупать» MVC в живую.
Как устроена логика MVC уже много где написано, но для понимания общей картины я все же повторюсь в двух словах. Итак, все содержимое приложения (в нашем случае сайта) разбито на 3 основных блока: Модель (M-model), представление (V-view) и контроллер (C-controller). Контроллер является «коммандиром» всего приложения и принимает основные решения. Представление хранит в себе html разметку сайта (визуальную часть приложения). А модель — работает с базой данных сайта. И все это работает как правило через единую точку входа — файл Index.php.
В нашем случае мы будем применять эту концепцию на примере создания маленького одностраничного информационного сайта о рыбалке. В общих чертах это работает так: пользователь попадает на наш сайт Index.php, делает какое-либо действие, Index.php передает управление на контроллер, который обрабатывает это действие, и в зависимости от того что это за действие — контроллер подключает вид. В виде запрашивается модель и выводится все это пользователю обратно.
Итак что будет делать наш сайт? Всего два действия: первое — выводить на главную страницу
небольшие отрывки (анонс) статей хранящихся в базе данных, и второе — по нажатии на любую из статей — выводить ее полный текст в блоке главной страницы.
Рассмотрим это на примере. Действие1: пользователь перешел на главную страницу Index.php (запрос 1), тогда контроллер Front_controller.php подключает вид Shablon1.php внутри вида загружается файл модели Articls_preview.php которая делает выборку анонса свежих статей из базы данных MySQL и выводит их обратно в файл вида Shablon1.php как бы встраивая текст статей в html разметку вида Shablon1.php.
В результате на экран выведется главная страница с фрагментами свежих
статей:
Итак ознакомимся с файловой структурой нашего сайта:
Сайт называется fishing_blog_procedure, поэтому его корневая папка носит то же название.
Далее в ней стоит обратить внимание только на 3 папки: это model — в ней расположены файлы скриптов работы с базой данных, controllers — в которой расположен файл скрипта нашего контроллера, и view — в которой расположены файлы представления нашего сайта. В папке components расположен файл подключения к базе данных который используют файлы модели. Папка nbproject к делу не относиться — это лишь папка моей IDE.
Итак первым делом настроим наш сайт так, что бы все запросы к нему приходящие — попадали на Index.php: для этого в файл .htaccess внесем следующее:
Не будим вдаваться в подробности — теперь все запросы будут перенаправляться на Index.php, тем самым организовывается как бы единая точка входа.
Далее откроем файл Index.php и подключим в нем файл контроллера:
Откроем файл контроллера Front_controller.php и пропишем следующее:
Обращаю ваше внимание, что в центральном контейнере div мы подключаем файл модели Articls_preview.php ( ), она будит выводить нам отрывки свежих статей из базы данных.
Далее перейдем к моделям и в файле Articls_preview.php напишем следующий код:
Теперь если пользователь нажмет на ссылку «Читать далее. » (Рисунок 3) на одной из выведенных статей, например с ID статьи 6, то в адресную строку попадет следующий код:
http://fishing_blog_procedure/index.php?r=6
Следовательно, контроллер Front_controller.php проанализировав данную информацию, увидит что параметр ‘r’, переданный по GET, теперь не пустой и содержит цифру 6. Следовательно, сработает другое условие else скрипта Front_controller.php и контроллер подключит нам файл Shablon2.php.
Внесем код в файл Shablon2.php (по сути, это копия Shablon1.php с той лишь разницей что вместо модели Articls_preview.php здесь подключается модель All_text_one_articl.php которая выводит полный текст одной статьи:
Итак остается внести код в файл модели All_text_one_articl.php которая будит делать выборку всего текста одной статьи, и на этом с кодом можно закончить:
4. Выводы: В данной статье мы рассмотрели простейшую реализацию архитектуры построения приложения по MVC. Надеюсь всем начинающим это будет в помощь. Всем удачи!
Простая реализация модели MVC с поддержкой иерархии шаблонов
Немного о MVC
Паттерн разработки MVC обсуждался многократно и подробно описывать его вряд-ли есть смысл. Для ознакомления с предметом можно почитать:
Поэтому только кратко упомянем ключевые компоненты этой системы:
Попытка собрать все данные в одном представлении может привести и к многократному дублированию кода. Например, данные профиля пользователя некого сайта могут понадобиться в рамках самых разных задач (от редактирования профиля пользователем, до указания ссылки на автора опубликованного материала. Если каждая модель будет самостоятельно запрашивать такие данные, сложность и дублирование кода будет возрастать экспоненциально.
Если представление сможет запрашивать данные порциями, определяя каждый раз кто может эти данные предоставить, жизнь программиста станет легка и безоблачна, так как можно будет сосредоточиться на решении отдельной задачи, без необходимости держать в голове весь проект в целом. Однако, это предполагает необходимость организации иерархической обработки представлений. Если мы сможем из какого-то места шаблона запросить данные другого контроллера и получить готовый фрагмент выходного кода (например уже отформатированный html) нам станет легче. Однако, для этого нам в какой-то момент потребуется приостановить обработку текущего потока и передать управление другому обработчику. Проблема в том, что с такой задачей PHP справляется, мягко говоря, не блестяще. Данные через интерпретатор проходят только однократно и конструкции типа echo(‘ ‘); работать не будут. Внутренне обращение к интерпретатору не пройдет.
Отчасти, проблему блочного построения вывода помогают решить шаблонизаторы. Их достаточно много, разных по возможностям и удобству работы. Однако, они имеют один общий недостаток — они являются надстройкой над PHP и вводят свой язык разметки, требующий изучения. В тоже время, такой функционал в рамках PHP является заведомо избыточным, так как этот язык сам по себе обеспечивает вполне неплохие возможности работы с шаблонами. Думаю, всем приходилось писать конструкции типа:
В таких конструкциях как раз и используются возможности PHP как шаблонизатора. Кстати, дизайнеры к таким вставкам относятся без испуга.
Теперь давайте перейдем к практической части, и посмотрим как в рамках шаблона страницы можно реализовать вставку целого блока, который в свою очередь может быть составлен из целого набора под-блоков. Это может быть реализовано на чистом PHP, без привлечения дополнительного языка разметки.
Практика
Главным компонентом системы и главной точкой входа является файл application.php:
Класс webApplication является базовой точкой входа в систему. Как видно из представленного кода, этот класс реализует паттерн Singleton. В рамках работы системы у нас всегда присутствует экземпляр данного класса, причем всегда только один. Такое свойство делает его крайне удобным для хранения всех глобальных данных системы. В данном случае импорт настроек системы и их использование опущены, так как их легко реализовать самостоятельно, в зависимости от своих потребностей.
Вернемся к нашему примеру. В нашем случае будет вызван контроллер welcome (welcome.php):
Этот контроллер написан сугубо в рамках примера и можно считать, что не делает вообще ничего. Только загружает некий HTML-файл. Откуда же тогда берутся данные? Можно предположить, что загружаемый файл является шаблоном и как-то их запрашивает. Так ли это? Смотрим код:
И это действительно так. Смотрим на строку handle(«hello»,«say»);?>. Вот он лев! Мы обратились к нашему классу webApplication и попросили вызвать нужный нам контроллер. Причем система обеспечит подготовку и вставку нужного нам HTML автоматически. Никаких возвратов строк. И задействовали мы ту же функцию handle, которую разбирали выше. Мы просим вызвать контроллер hello, который очевидно расположен в hello.php
В данном контроллере у нас реализован метод, отвечающий за обработку действия «say» — actionSay.
Этот метод выполняет типичную для модели MVC последовательность действий: создает модель, передает ей на обработку данные, загружает представление.
Сначала посмотрим на модель (это только пример, поэтому она крайне проста).
Как видно, данное представление — всего навсего фрагмент HTML кода, со вставкой PHP, обращающейся к данным модели. Эти данные уйдут в поток и после обработки интерпретатором PHP попадут в нужное место первого представления. Понятно, что в целом уровень вложенности и количество вызовов контроллеров не ограничено.
Все! Мы реализовали многоуровневую систему шаблонов, используя модель MVC для каждого из них. Предлагаемая система может послужить неплохим скелетом для реализации сложных приложений.
Простой, современный MVC фреймворк на PHP для разработки сайтов «с нуля»
Цель данной статьи — поделиться опытом по написанию простого ООП MVC PHP фреймворка. Так же хочу предоставить сообществу исходный код и попросить критики, одобрения, замечаний и поддержки.
Введение
По ходу эксплуатации различных современных фреймворков я понял, что недостаточно понимаю, как все устроено внутри; не осознаю, почему разработчики выбрали то или иное решение; обращаю внимание только на текущую задачу и не смотрю «выше, глубже и дальше». И, как вариант для профессионального роста, я выбрал создание собственного проекта.
Как показала дальше практика: читать, знать, слышать о чем-либо, и уметь самому это реализовать — совершенно разные вещи. Теоретизировать можно бесконечно, но только настоящее практическое задание позволяет понять, на каком уровне ты находишься. Всвязи с этим и было начато «написание собственного велосипеда». Каким он получился — судить вам.
Процесс разработки
Разработка фреймворка велась следующим образом: изначально было некое простейшее веб-приложение, которое дорабатывалось, переписывалось, меняло структуру, обрастало новыми классами и компонентами и т. д. Несколько месяцев назад у меня появилось свободное время, много энтузиазма и решительности таки доделать фреймворк «по-серьезному». На написание данной версии я потратил в совокупности 3-4 недели (работая в среднем 1-3 часа в день, 3-4 дня в неделю).
По мере разработки стандарты и требования я сознательно завышал для себя, искал оптимальные решения много раз переписывал код. Так, например, работу с конфигурацией я переделывал раз 5-6 (причем несколько раз кардинально), роутинг — 3-4 раза. В качестве примеров я брал код из статей, публикаций, руководств, фреймворков (Yii2, CodeIgniter, Zend, Phalcon, Bun) и т. п.
Анализ требований
Все начинается с анализа требований и пожеланий к итоговой системе.
Применяемые технологии
Список таких решений напрямую зависит от того, о чём знаете и что применяете в своей реальной практике. Т.е. подходим к необходимости постоянного мониторинга новинок и изменений в сфере ИТ.
Практики и технологии:
Структура папок
Приведу структуру файлов и папок в фреймворке (также можно посмотреть код на GitHub):
В приложении есть одна единственная точка входа. Привожу код файла index.php из корневой публичной папки веб-сервера.
Код метода run($config) из класса \framework\core\Application(). Производится загрузка необходимых классов приложения и производится вызов соответствующего контроллера (в методе execute()).
Код метода execute() из класса \framework\core\Application(). Нужный контроллер на данном этапе уже выбран, производим инициализацию этого контроллера, обработку хеадеров, вывод контента. В случае ошибки — бросаем 404 Not Found.
Улучшения и планы на будущее
В качестве адаптера для коннекта к БД я использовал PDO. В ходе работы PDO мне не очень понравился — сложно отлаживать запросы, хочется комфорта использования ORM. Можно установить Eloquent ORM — это современное и готовое решение (применяется в фреймворке Laravel), да и к тому же оно хорошо документировано и может быть установлено из composer за несколько минут.
Так же думал о расширении базового функционала фреймворка: хотел добавить поддержку модулей. Т.е. чтобы можно было написать например, блог как отдельный модуль (со своими контроллерами, вьюверами, моделями и т.п.). И потом подключать этот модуль в любом месте приложения.
Можно расширять и базовый «джентельменский» набор классов в ядре, усложнять систему логирования, обработки ошибок, конфигурирования, писать полноценный демо-сайт со всем функционалом и т.д.
Заключение
Буду рад услышать критику кода, архитектуры, изначальных требований и прочего. Комментарии буду активно читать, постараюсь ответить на вопросы.
Так же хотелось бы реализовать какой-либо проект на базе данного фреймворка. Так сказать опробовать инструмент в работе. Понятно, что поиск заказчиков — это совсем не к данному разделу, но хотел бы услышать, можно ли на данном решении стартовать реальный проект? Популярные фреймворки «из коробки» дают функционал в 50-100 раз качественнее и масштабнее, конкурировать с ними сложно.
Простые MVC-приложения
Теория
Если коротко, то MVC (model view controller) это такой способ написания программы, когда код отвечающий за вывод данных, пишется в одном месте, а код который эти данные формирует, пишется в другом месте. В итоге получается так, что если вам надо подправить вывод вы сразу знаете в каком месте искать. Сейчас все популярные фреймворки используют такую архитектуру.
Также стоит упомянуть тот факт, что существует два лагеря: один пишет логику в контроллерах, второй в моделях. В тех фреймворках, которые знаю я (yii, laravel) логику пишут в контроллерах, а модели являются просто экземплярами ORM. У yii кстати в мануале написано, что писать логику надо в моделях, а потом они сами в примерах пишут её в контроллерах, довольно забавно.
С бизнес-логикой определились, пишем в контроллерах. Также в методах контроллера происходит вызов моделей, которые у нас по сути экземпляры ORM, чтобы с их помощью получить данные из базы над которыми будут производить изменения. Конечный результат отправляется в виды. Виды cодержат HTML-разметку и небольшие вставки PHP-кода для обхода, форматирования и отображения данных.
Ещё можно упомянуть, что есть два вида MVC Page Controller и Front Controller. Page Controller’ом пользуются редко, его подход заключается в использовании нескольких точек входа (запросы к сайту осуществляются к нескольким файлам), и внутри каждой точки входа свой код отображения. Мы будем писать Front Controller с одной точкой входа.
Практика
Дальше в папке нашего проекта создаём папку, которую можно назвать App например. В ней будет следующее содержимое.
Наш Service Locator. Файл App.php
Сервис локатор нужен чтобы хранить в нём компоненты нашего приложения. Поскольку у нас простое mvc приложение, то мы не используем паттерн registry (как например в yii сделано). А просто сохраняем компоненты приложения в статические свойства, чтобы обращаться к ним было проще. Ещё App регистрирует автозагрузчик классов и обработчик исключений.
Роутер. Файл Router.php
Файл Db.php
Этот класс юзает файл конфига, который возврашает массив при подключении
Файл Config/Db.php
Наше ядро. Файл Kernel.php
Ядро обращается к роутеру, а потом запускает действия контроллера. Ещё ядро может кинуть исключение, если нет нужного контроллера или метода.
Файл Controller.php
Ещё нам нужно создать базовый класс для наших контроллеров, чтобы потом наследоваться от него. Наследовать методы нужно для того, чтобы вы могли рендерить (сформировать вывод) виды. Методы рендеринга поддерживают использование лэйаутов — шаблонов, которые содержат общие для всех видов компоненты, например футер и хэдер.
Файл index.php
Не забываем создать индексный файл в корне:
Создаём контроллеры и виды
Работа с нашим приложением (можно даже сказать минифреймворком) теперь сводится к созданию видов и контроллеров. Пример контроллера следующий (в папке Controllers):