Модульным php приложением не являющимся mvc
У меня есть некоторые (возможно, базовые) знания шаблона Model-View-Controller, и я хочу создать сайт, используя это. Но я нахожу это немного запутанным, как на самом деле реализовать это. Я увязаю в деталях.
говорят, что у меня есть сайт, где каждый пользователь поддерживает несколько списков todo. Как бы вы подошли к этому? Какие классы вы бы создали? Какой класс будет выводить HTML, какой класс будет сервером в качестве контроллера и как он будет взаимодействовать с представлением для создания выход? так далее.
Извините, если это кажется глупым, и я думаю, что это должно быть несколько легко, но я застрял.
Это очень возможно сделать без существующей структуры, и просто создать свой собственный. В любом случае, это не очень сложная задача.
не будучи специфичным для приложения, ваша платформа MVC должна была бы сделать следующее:
существует несколько способов реализации представлений, вы можете эмулировать ASPMVC и действие каждого контроллера возвращает ActionResult , который имеет один метод execute. Затем перегрузка этого, ViewResult позаботится о загрузке правильный вид и включение его с правильным ModelData .
вот точный ответ на ваш вопрос от самого Расмуса ЛЕРДОРФА. прочитать.
это не так сложно сделать MVC в PHP, его больше связано с дисциплиной, а не с задачей сложности.
A) модель (ы) (необязательно, вы можете использовать массив в PHP)
b) маршрут (индекс.РНР?)
a) вид должен быть максимально чистым. Подумайте, что представление может быть создано web дизайнер, который не заботится о PHP.
b) представление всегда является последним шагом процесса. Просмотр веб всегда ничего не возвращает.
хотя ваш вопрос слишком широк, я думаю, что могу оказать некоторую помощь.
вопрос номер один, который у меня был, когда я начинал с фреймворков: какую фреймворк, если таковой имеется, я должен использовать? В вашем случае я бы не пытался создать веб-сайт MVC без предварительно созданной структуры. Большая часть архитектуры, которую вы в конечном итоге напишете, уже была сделана десятки раз.
такие вещи, как абстракция БД, системы входа в систему и т. д. скучно писать. Могли бы также использовать рамки, которые уже имеют эти вещи.
альтернативно, если вы как написать свой собственный фреймворк, чтобы вы могли узнать, как это делается, я бы рекомендовал ответ TJHeuvel. Другой вариант-прочитать исходный код существующей структуры, чтобы вы могли видеть, как другие ее реализовали.
комментарий Kheldar смысл. Учебник фактически охватывает создание микро-фреймворка с использованием шаблона MVC.
хотя вам нужно было бы добавить к нему-с точки зрения добавления пользовательских маршрутов и какого-то механизма маршрутизации, но кроме этого это очень хороший шаг ребенка в разработку собственной структуры MVC..
Также стоит упомянуть тот факт, что существует два лагеря: один пишет логику в контроллерах, второй в моделях. В тех фреймворках, которые знаю я (yii, laravel) логику пишут в контроллерах, а модели являются просто экземплярами ORM. У yii кстати в мануале написано, что писать логику надо в моделях, а потом они сами в примерах пишут её в контроллерах, довольно забавно.
С бизнес-логикой определились, пишем в контроллерах. Также в методах контроллера происходит вызов моделей, которые у нас по сути экземпляры ORM, чтобы с их помощью получить данные из базы над которыми будут производить изменения. Конечный результат отправляется в виды. Виды cодержат HTML-разметку и небольшие вставки PHP-кода для обхода, форматирования и отображения данных.
Ещё можно упомянуть, что есть два вида MVC Page Controller и Front Controller. Page Controller'ом пользуются редко, его подход заключается в использовании нескольких точек входа (запросы к сайту осуществляются к нескольким файлам), и внутри каждой точки входа свой код отображения. Мы будем писать Front Controller с одной точкой входа.
Практика
Начать надо с настройки сервера для переадресации на нашу единую точку входа. Если у нас apache, то в файле .htaccess пишем следующее
Дальше в папке нашего проекта создаём папку, которую можно назвать App например. В ней будет следующее содержимое.
Наш Service Locator. Файл App.php
Сервис локатор нужен чтобы хранить в нём компоненты нашего приложения. Поскольку у нас простое mvc приложение, то мы не используем паттерн registry (как например в yii сделано). А просто сохраняем компоненты приложения в статические свойства, чтобы обращаться к ним было проще. Ещё App регистрирует автозагрузчик классов и обработчик исключений.
Роутер. Файл Router.php
Файл Db.php
Этот класс юзает файл конфига, который возврашает массив при подключении
Файл Config/Db.php
Наше ядро. Файл Kernel.php
Ядро обращается к роутеру, а потом запускает действия контроллера. Ещё ядро может кинуть исключение, если нет нужного контроллера или метода.
Файл Controller.php
Ещё нам нужно создать базовый класс для наших контроллеров, чтобы потом наследоваться от него. Наследовать методы нужно для того, чтобы вы могли рендерить (сформировать вывод) виды. Методы рендеринга поддерживают использование лэйаутов — шаблонов, которые содержат общие для всех видов компоненты, например футер и хэдер.
Файл index.php
Не забываем создать индексный файл в корне:
Создаём контроллеры и виды
Работа с нашим приложением (можно даже сказать минифреймворком) теперь сводится к созданию видов и контроллеров. Пример контроллера следующий (в папке Controllers):
Каковы альтернативные "методы проектирования" для Model View Controller? MVC кажется популярным (SO был построен с ним, я знаю это много), но является ли он единственным используемым методом?
ОТВЕТЫ
Ответ 1
Есть много других:
- Это часто встречается в приложениях WPF (хотя Prism использует шаблон MVP (обычно))
Ответ 2
Одна из лучших записей нескольких различных шаблонов интерактивной архитектуры приложения - этот очень подробный и хорошо изученный блог-пост, Он охватывает Model-View-Controller, три разных вкуса Model-View-Presenter, несколько различных вариантов представления-Абстракция-контроль, Контролирующий контроллер, Пассивный просмотр и Иерархический MVC.
Еще одна интересная модель - это шаблон Presenter First от Atomic Objects. Это не только шаблон дизайна, но и шаблон процесса. IOW: имя "Presenter First" не является произвольным, оно фактически описывает процесс разработки, в котором Presenter записывается первым, управляя дизайном остальной системы.
Ответ 3
MVC - это архитектурный шаблон. Это другие архитектурные образцы, которые вы можете попробовать (из Википедии):
- Слои
- Многоуровневая архитектура
- Управление абстракцией презентации (PAC)
- Модель View Presenter (MVP)
- Model View ViewModel (MVVM)
- Трубопроводный
- Неявный вызов
- Система Blackboard
- одноранговая сеть
- Сервис-ориентированная архитектура (SOA)
- Голые объекты
Ответ 4
DCI - "Данные, связь и взаимодействие"
Ответ 5
Я также нашел Объект данных Factory. Вы должны оглядываться на некоторые ресурсы на вашем любимом языке.
Ответ 6
Мы используем не столько альтернативу, сколько гибрид, называемый MVC-ARS.
Ответ 7
Prof. Kowarschick использовал этот подход для разработки VCLSD -Pattern (вики, написанные на немецком языке! Возможно, у кого-то есть время, чтобы перевести его - как для себя, я только начинаю программировать)
MVCS: служба управления просмотром модели
VCLSD: просмотр данных логической службы контроля
Ответ 8
Некоторые связанные архитектурные шаблоны, о которых ранее не упоминалось, включают
Концепция MVC (Model-View-Controller: модель-вид-контроллер) очень часто упоминается в мире веб программирования в последние годы. Каждый, кто хоть как-то связан с разработкой веб приложений, так или иначе сталкивался с данным акронимом. Сегодня мы разберёмся, что такое - концепция MVC, и почему она стала популярной.
Древнейшая история
MVC — это не шаблон проекта, это конструкционный шаблон, который описывает способ построения структуры нашего приложения, сферы ответственности и взаимодействие каждой из частей в данной структуре.
Впервые она была описана в 1979 году, конечно же, для другого окружения. Тогда не существовало концепции веб приложения. Tim Berners Lee (Тим Бернерс Ли) посеял семена World Wide Web (WWW) в начале девяностых и навсегда изменил мир. Шаблон, который мы используем сегодня, является адаптацией оригинального шаблона к веб разработке.
Бешеная популярность данной структуры в веб приложениях сложилась благодаря её включению в две среды разработки, которые стали очень популярными: Struts и Ruby on Rails. Эти две среды разработки наметили пути развития для сотен рабочих сред, созданных позже.
MVC для веб приложений
Идея, которая лежит в основе конструкционного шаблона MVC, очень проста: нужно чётко разделять ответственность за различное функционирование в наших приложениях:
Приложение разделяется на три основных компонента, каждый из которых отвечает за различные задачи. Давайте подробно разберём компоненты на примере.
Контроллер (Controller)
Модель (Model)
Модель содержит наиболее важную часть логики нашего приложения, логики, которая решает задачу, с которой мы имеем дело (форум, магазин, банк, и тому подобное). Контроллер содержит в основном организационную логику для самого приложения (очень похоже на ведение домашнего хозяйства).
Вид (View)
Вид обеспечивает различные способы представления данных, которые получены из модели. Он может быть шаблоном, который заполняется данными. Может быть несколько различных видов, и контроллер выбирает, какой подходит наилучшим образом для текущей ситуации.
Веб приложение обычно состоит из набора контроллеров, моделей и видов. Контроллер может быть устроен как основной, который получает все запросы и вызывает другие контроллеры для выполнения действий в зависимости от ситуации.
Разберём пример
Предположим, нам надо разработать онлайновый книжный магазин. Пользователь может выполнять следующие действия: просматривать книги, регистрироваться, покупать, добавлять пункты к текущему заказу, создавать или удалять книги (если он администратор). Давайте посмотрим, что произойдёт, когда пользователь нажмёт на категорию фэнтези для просмотра названий книг, которые имеются в нашем магазине.
У нас есть определённый контроллер для обработки всех действий, связанных с книгами (просматривать, редактировать, создавать и так далее). Давайте назовем его books_controller.php в нашем примере. Также нам нужна модель, например, book_model.php, которая обрабатывает данные и логику, связанные с позицией в магазине. В заключение, нам нужно несколько видов для представления данных, например, список книг, страница для редактирования и так далее.
Следующий рисунок показывает, как обрабатывается запрос пользователя для просмотра списка книг по теме фэнтези:
Контроллер проверяет запрос и параметры, а затем вызывает модель(book_model.php), запрашивая у неё список доступных книг по теме фэнтези [2].
Модель получает данные из базы (или из другого источника, в котором хранится информация) [3], применяет фильтры и необходимую логику, а затем возвращает данные, которые представляют список книг [4].
Контроллер использует подходящий вид [5] для представления данных пользователю 7. Если запрос приходит с мобильного телефона, используется вид для мобильного телефона; если пользователь использует определённое оформление интерфейса, то выбирается соответствующий вид, и так далее.
В чем преимущества?
Самое очевидное преимущество, которое мы получаем от использования концепции MVC — это чёткое разделение логики представления (интерфейса пользователя) и логики приложения.
Поддержка различных типов пользователей, которые используют различные типы устройств является общей проблемой наших дней. Предоставляемый интерфейс должен различаться, если запрос приходит с персонального компьютера или с мобильного телефона. Модель возвращает одинаковые данные, единственное различие заключается в том, что контроллер выбирает различные виды для вывода данных.
Помимо изолирования видов от логики приложения, концепция MVC существенно уменьшает сложность больших приложений. Код получается гораздо более структурированным, и, тем самым, облегчается поддержка, тестирование и повторное использование решений.
А зачем использовать рабочую среду?
Когда вы используете рабочую среду, базовая структура MVC уже подготовлена, и вам остаётся только расширить структуру, размещая ваши файлы в соответствующих директориях для соответствия шаблону MVC. Кроме того, у вас будет набор функций, которые уже написаны и хорошо протестированы.
Рассмотрим cakePHP в качестве примера рабочей среды MVC. После установки у вас будет три основных директории:
Папка app является местом размещения ваших файлов. Это место для разработки вашей части приложения.
В папке cake размещаются файлы cakePHP (функциональность рабочей среды).
Папка vendors служит для хранения библиотек PHP сторонних разработчиков.
Ваше рабочее пространство (директория app) имеет следующую структуру:
- app/
- config/
- controllers/
- locale/
- models/
- plugins/
- tests/
- tmp/
- vendors/
- views/
- webroot/
Вам нужно размещать ваши контроллеры в директории controllers, модели в директории models и виды в директории views!
Как только вы начнёте использовать рабочую среду, то сразу станет ясно, где размещается практически любая часть вашего приложения, которую надо создать или модифицировать. Такая организация сама по себе значительно упрощает процесс разработки и поддержки приложения.
Использование рабочей среды для нашего примера
Так как данный урок не имеет целью показать процесс создания приложения с помощью cakePHP, то мы покажем только код для модели, контроллера и вида с комментариями о преимуществах использования рабочей среды MVC. Код специально упрощён и непригоден для использования в реальном приложении.
Помните, мы рассматривали книжный магазин и любопытного пользователя, который хотел увидеть полный список книг по теме фэнтези. Контроллер получал запрос пользователя и координировал необходимые действия.
Итак, как только пользователь нажимает кнопку, браузер запрашивает данный url:
CakePHP форматирует URL по шаблону /controller/action/param1/param2 , где action - это функция, которая вызывается контроллером. В старом классическом виде url будет выглядеть так:
Контроллер
В рабочей среде cakePHP, наш контроллер будет выглядеть так:
Просто, не так ли?. Данный контроллер будет сохранен как books_controller.php и размещён в /app/controllers. Он содержит список функций, которые выполняют действия для нашего примера, а также другие функции для выполнения связанных с книгами операций (добавить новую книгу, удалить книгу, и так далее).
Рабочая среда предоставляет нам множество готовых решений и нужно только сформировать список книг. Есть базовый класс, в котором уже определено базовое функционирование контроллера, таким образом, надо унаследовать свойства и функции этого класса (AppController является наследником Controller).
Все что нужно сделать в списке действий — вызвать модель для получения данных и затем выбрать вид для представления их пользователю. Вот как это делается.
this->Book - это наша модель, и часть кода:
сообщает модели, что нужно вернуть список книг по выбранной теме (мы рассмотрим модель позже).
Метод set в строке:
Контроллер передаёт данные виду. Переменная books принимает данные, возвращённые моделью, и они становятся доступными для вида.
Теперь остаётся только вывести на экран вид, но эта функция выполняется автоматически в cakePHP, если мы используем вид по умолчанию. Если мы хотим использовать другой вид, то надо явно вызвать метод render.
Модель
Модель даже ещё проще:
Почему она пустая? Потому что она является наследником базового класса, который обеспечивает необходимую функциональность и нам нужно использовать соглашение об именах в CakePHP для того, чтобы рабочая среда выполняла все другие задачи автоматически. Например, cakePHP известно на основании имени, что данная модель используется в BooksController, и что она имеет доступ к таблице базы данных с именем books.
С таким определением у нас будет модель, которая может только читать, удалять или сохранять данные в базе данных.
Код сохраняем как book.php в папке /app/models.
Все, что нам нужно теперь сделать — это создать вид (по крайней мере, один) для списка действий. Вид будет иметь код HTML и несколько (как можно меньше) строк кода PHP для организации цикла по массиву книг, которые предоставляется моделью.
Как можно заметить, вид создаёт не полноценную страницу, а лишь фрагмент HTML (таблицу в данном случае). Потому, что CakePHP обеспечивает другой способ для определения шаблона страницы, и вид вставляется в данный шаблон. Рабочая среда также обеспечивает нас некоторыми вспомогательными объектами для выполнения общих задач во время создания частей HTML страницы (вставка форм, ссылок, Ajax или JavaScript).
Сохраняем вид как list.ctp ( list — это имя действия, а ctp означает шаблон CakePHP) в папке /app/views/books (потому, что это вид для действия контроллера).
Вот так выполняются все три компонента с помощью рабочей среды CakePHP!
5 последних уроков рубрики "PHP"
Фильтрация данных с помощью zend-filter
Когда речь идёт о безопасности веб-сайта, то фраза "фильтруйте всё, экранируйте всё" всегда будет актуальна. Сегодня поговорим о фильтрации данных.
Контекстное экранирование с помощью zend-escaper
Обеспечение безопасности веб-сайта — это не только защита от SQL инъекций, но и протекция от межсайтового скриптинга (XSS), межсайтовой подделки запросов (CSRF) и от других видов атак. В частности, вам нужно очень осторожно подходить к формированию HTML, CSS и JavaScript кода.
Подключение Zend модулей к Expressive
Expressive 2 поддерживает возможность подключения других ZF компонент по специальной схеме. Не всем нравится данное решение. В этой статье мы расскажем как улучшили процесс подключение нескольких модулей.
Совет: отправка информации в Google Analytics через API
Подборка PHP песочниц
Подборка из нескольких видов PHP песочниц. На некоторых вы в режиме online сможете потестить свой код, но есть так же решения, которые можно внедрить на свой сайт.
Принцип Модель-Представление-Контроллер ( Model-View-Controller, MVC ) был сформулирован еще в конце 70-х годов XX века. Это архитектура построения программного обеспечения, при которой данные независимы от методов, которые с ними работают.
Несмотря на то, что изначально MVC был разработан для локальных приложений, позже он был адаптирован и широко распространился среди веб-разработчиков из-за акцента на разделение функций, и возможностей повторного использования кода.
MVC поощряет разработку модульных систем, позволяя быстро модифицировать проект, добавлять и удалять функционал.
В этой статье будут рассмотрены базовые принципы подхода MVC, дано определение этому понятию и разобраны небольшие примеры на PHP.
Целевая аудитория – все те, кто раньше никогда не создавал MVC-программы, а также те, кто хочет укрепить свои знания по этой теме.
Понятие MVC
В название принципа входит три основополагающих компонента: модель ( Model ), представление ( View ) и контроллер ( Controller ).
Визуальное представление завершенного и корректного MVC-приложения выглядит так, как показано ниже:
![Понятие MVC]()
Изображение демонстрирует прохождение одиночного потока данных через все компоненты и их взаимное отношение друг к другу.
Модель
Название « модель » обозначает хранилище данных, используемых во всей конструкции. Оно должно предоставлять доступ к данным для их просмотра и изменения. Модель является своего рода мостом между представлением и контроллером.
Одним из важных аспектов модели является то, что технически она « слепа » и не имеет представления о том, что происходит с данными, когда они проходят через представление или контроллер.
Модель не вызывает и не ожидает ответа от других компонентов, а просто обрабатывает данные в своем хранилище и готовит их к отправлению другим компонентам.
Модель, тем не менее, не может быть названа базой данных или шлюзом другой системы, которая управляет процессом обработки данных. Модель должна работать как сторож данных, не задавая вопросов и отвечая на все приходящие запросы.
Представление
Этот компонент отображает данные, полученные из модели, в определенном виде. Традиционно, в веб-приложениях использующих MVC, представление является набором HTML-файлов, которые и формируют облик выводимых данных.
Представление также определяет реакцию пользователя, который затем взаимодействует с контроллером. Простейшим примером этого может служить кнопка, сгенерированная представлением, по которой кликает пользователь, тем самым запуская взаимодействие с контроллером.
Среди веб-разработчиков, использующих MVC, существуют некоторые заблуждения относительно компонента представления.
Например, о том, что представление не имеет никакой связи с моделью, а все данные, отображаемые представлением, проходят через контроллер. В действительности, описанное выше, полностью идет в разрез с концепцией MVC.
«Важно заметить, что для корректного воплощения архитектуры MVC, не должно быть взаимодействия между моделью и представлением: вся логика реализована в контроллере.»
Более того, описание представления как файла шаблона неверно. Однако, как заметил Tom Butler , это не ошибка какого-то одного человека, а совокупность заблуждений многих разработчиков, неверно усвоивших теорию MVC. А затем они передают свой опыт другим, что сами понимаете к чему ведет.Представление, на самом деле, это нечто большее, чем просто шаблон. Но современное понимание, породившее множество фреймворков, настолько исказило изначальный смысл, что разработчики уже не особо заботятся о соблюдении принципов MVC.
Также стоит заметить, что представление никогда не получает данные из контроллера. Как было замечено при обсуждении модели, прямой связи между представлением и контроллером, минуя модель, нет.
Контроллер
Завершает триаду компонентов контроллер. Его функция заключается в управлении данными, вводимыми и отправляемыми пользователем, а также соответствующее обновление модели.
Источником, приводящим в движение контроллер, является пользователь; без взаимодействия с ним, существование контроллера не имеет смысла. Это единственная часть MVC, с которой напрямую имеет дело пользователь.
Контроллер можно описать как сборщик информации, который передает её на хранение модели, и не содержит других логических компонентов, кроме тех, которые нужны для приема вводимых данных.
Также, контроллер подключен только к одной модели и одному представлению, что делает его единственным каналом прохождения данных в системе, который поддерживает механизмы обеспечения безопасности передачи.
Контроллер активен только тогда, когда пользователь взаимодействует с представлением. Иными словами, пользователь, работая с представлением, по принципу триггера запускает контроллер.
Распространенной среди разработчиков ошибкой является присвоение контроллеру функций, которые должно иметь представление.
Это результат того, что некоторые разработчики считают представление просто шаблоном. В дополнение ко всему, ошибкой является придавать контроллеру функции, делающие его единственным ответственным за передачу и обработку данных от модели к представлению, в то время как в MVC эта ответственность должна распределяться между моделью и представлением.
MVC в PHP
Давайте напишем веб-приложение на PHP, которое будет использовать MVC.
Начнем с простейших примеров:
Для начала, мы создали несколько базовых классов для каждой части нашей реализации MVC.
Теперь настроим отношения между ними:
Как можно было заметить в примере выше, мы не создавали специфического функционала контроллера, потому что отсутствует взаимодействие пользователя с нашим приложением.
Представление хранит все функции, что сделано исключительно в демонстрационных целях.
Давайте теперь расширим наш пример, чтобы показать как добавить функциональность в контроллер и придать интерактивности нашему приложению:
Мы расширили наше приложение.
Отношения между нашими компонентами теперь выглядят так:
После запуска кода, кликните по ссылке, и вы сможете увидеть строку с измененными данными.
Заключение
Мы рассмотрели основы MVC и создали простейшее приложение на основе этой архитектуры, но впереди еще долгий путь, прежде чем мы получим желаемый результат.
Читайте также:
