что такое mvc фреймворк
ASP.NET MVC Framework – ставим точки
Точка первая ставится в вопросе “Нужно ли переходить на MVC Framework и почему?”
Этой статьей я хотел бы открыть цикл статей про MVC Framework. Последнее время я очень плотно работаю с ним и с его внутренностями и у меня накопилось несколько мыслей, интересных наблюдений и знаний которыми хотелось бы поделиться. Если вы программист ASP.NET и не знакомы или знакомы не очень хорошо с MVC Framework, то, хотелось бы верить, мои статьи помогут вам понять этот инструмент лучше. В любом случае, даже если вы очень хорошо знаете предмет, я думаю, нам с вами будет что обсудить в комментариях на каждую поднятую тему.
Итак, первая вводная заметка посвящена вопросу необходимости использования или перехода на MVC Framework с классического ASP.NET. Вопрос этот непростой и ответ который я дам не будет повторять шаблонные рекомендации и сравнения, которые вы можете найти в интернет. Напротив, я хотел бы перевернуть точку зрения так, чтобы вы посмотрели на проблему с другой стороны.
Почему вам не нужен MVC Framework
Рассмотрим сначала почему вам не нужен MVC Framework:
* вам не нужен MVC Framework, если вы считаете, что он лучше классического ASP.NET. Если вы так думаете, значит вы плохо знаете ASP.NET, вам есть еще куда расти и что изучать. Если вы думаете, что MVC Framework лучше ASP.NET, значит вы не полюбили ASP.NET и не поняли всей прелести его идеологии. В таком случае вам рано переходить на MVC Framework. Переходить на новый фреймворк просто неоткуда, если у вас нет должного понимания и любви к базовому механизму. Изучить ASP.NET, поймите почему и как там все устроено. MVC Framework вам не нужен;
* вам не нужен MVC Framework для того, чтобы использовать паттерн MVC. В самом деле MVC не имеет никакого отношения к конкретной библиотеке. MVC Framework – это всего лишь реализация паттерна, которую никто не мешает вам создать и использовать самому в классическом ASP.NET. Попробуйте, это не трудно. MVC Framework вам не нужен, если причина только в том, что он MVC;
* вам не нужен MVC Framework, если вы хотите избавиться от viewstate. MVC Framework не предназначен для цели “избавления от viewstate”. Если вы хотите избавиться от viewstate, то изучите, как работает этот механизм. Почему он есть и для чего служит. Уверяю вас, viewstate в умелых руках очень полезен. А большие и тяжелые viewstate-страницы – это результат плохого дизайна или недостаточности знаний у разработчика;
* вам не нужен MVC Framework, если вы хотите избавиться от автоматической генерации идентификаторов. История повторяется. Все что касается viewstate применимо и к автогенерации id для элементов html-разметки. Если вы понимаете как и зачем генерируются идентификаторы у вас отпадет желание от них избавляться. Кроме того, в ASP.NET 4.0 у вас появляется возможность более гибко управлять генерацией и это еще одна причина того, почему MVC Framework вам не нужен;
* вам не нужен MVC Framework, если вы хотите “получить полный контроль над разметкой“. В классическом ASP.NET разработчик так же имеет полный контроль над разметкой и желание получить что-то еще явный признак того, что разработчик плохо понимает ASP.NET. Только поняв как работает ASP.NET с разметкой и как он обрабатывает запросы, можно сравнивать классическую модель с моделью MVC Framework. Если вы хорошо себе представляете как работают оба эти механизма, то требование этого абзаца отпадет само собой. MVC Framework для управления разметкой вам не понадобится;
* вам не нужен MVC Framework, если вы хотите получить удобочитаемые URL. Механизм маршрутизации, который позволяет представлять удобочитаемые URL является частью ASP.NET, но не внутренней частью MVC Framework, поэтому использовать маршрутизацию и создавать удобочитаемые URL-ы вы можете и в классическом ASP.NET, MVC Framework для этого вам не нужен.
Надеюсь, что вы не согласны с некоторыми из этих пунктов. Это хорошо, возможно мои тезисы заставят вам по-другому взглянуть на вопрос.
Почему вам нужен MVC Framework
Рассмотрим же причины, по которым вам нужен MVC Framework:
* MVC Framework вам нужен потому что вы хотите покрыть юнит-тестами значительную или всю часть кода. Это достойная причина перехода на MVC Framework, его модель предполагает, что тестированию может быть подвержена любая часть фреймворка на любом этапе. Тогда как в классическом ASP.NET механизм обратных вызовов “postback” часто затруднял написание тестов;
* вам нужен MVC Framework, если большая часть вашего кода не является частью ASP.NET. Таким кодом является клиентский javascript и частично AJAX. Когда закладывался фундамент ASP.NET клиентской оптимизации и коду на стороне клиента уделялось очень мало внимания, в то время не было понятия AJAX или Web 2.0. Времена поменялись, меняется и классический ASP.NET, в нем есть множество инструментов по поддержке AJAX-функционала, но все же создание мощного клиентского кода остается трудной задачей. Если у вас большое количество кода на стороне клиента, может быть даже столько же сколько на стороне сервера, то MVC Framework вам нужен, он облегчит вашу работу;
* и основная и главная причина, по которой вам нужен MVC Framework – это абсолютная расширяемость. В этом плане MVC Framework – это действительно каркас, который может быть заполнен так, как нужно вам. Можно провести следующее сравнение: классический ASP.NET – это картина, нарисованная мастером, тогда как MVC Framework – это набросок, эскиз, который зарисовать, доделать предоставляют вам самому. В MVC Framework вы способны переопределить действие механизма на любом этапе от обработки запроса, до отправки результата.
Переход на MVC Framework не должен стать для вас поиском избавления от “проблем”. Посмотрите на проблемы пристальнее и вы увидите, что все они решаются в рамках классической модели ASP.NET. Многие не понимают, что основная сила и мощь, то почему следует использовать MVC Framework – это не “недостатки” классической модели ASP.NET, которые в большинстве случаев проистекают из плохого понимания предмета. Сила MVC Framework в его возможностях и потенциале к расширяемости. MVC Framework – это тот конструктор, который вы должны пожелать после того, как полностью насытились проверенными инструментами. Если вы встали перед проблемой, когда механизмов ASP.NET вам недостаточно, когда вас стесняют рамки предложенной модели, которую нельзя расширить или видоизменить, вот только тогда вам по-настоящему нужен MVC Framework. Любые другие случаи, попытки избавиться от “недостатков” или “переход на паттерн MVC” – это недостаточные причины необходимости в переходе на MVC и большей частью являются ошибочной точкой зрения на вопрос.
Это все, что я хотел бы сказать по вопросу “Нужно ли переходить на MVC Framework и почему?”. Надеюсь, что точку, которую я поставил в этой заметке заинтересует вас и заставит задуматься или взглянуть на вопрос под другим углом. В следующей части я постараюсь поставить точку в вопросе “Как работает механизм MVC Framework?”.
Концепция MVC для чайников
Древнейшая история
MVC — это не шаблон проекта, это конструкционный шаблон, который описывает способ построения структуры нашего приложения, сферы ответственности и взаимодействие каждой из частей в данной структуре.
Впервые она была описана в 1979 году, конечно же, для другого окружения. Тогда не существовало концепции веб приложения. Tim Berners Lee (Тим Бернерс Ли) посеял семена World Wide Web (WWW) в начале девяностых и навсегда изменил мир. Шаблон, который мы используем сегодня, является адаптацией оригинального шаблона к веб разработке.
Бешеная популярность данной структуры в веб приложениях сложилась благодаря её включению в две среды разработки, которые стали очень популярными: Struts и Ruby on Rails. Эти две среды разработки наметили пути развития для сотен рабочих сред, созданных позже.
MVC для веб приложений
Идея, которая лежит в основе конструкционного шаблона MVC, очень проста: нужно чётко разделять ответственность за различное функционирование в наших приложениях:
Приложение разделяется на три основных компонента, каждый из которых отвечает за различные задачи. Давайте подробно разберём компоненты на примере.
Контроллер (Controller)
Контроллер управляет запросами пользователя (получаемые в виде запросов HTTP GET или POST, когда пользователь нажимает на элементы интерфейса для выполнения различных действий). Его основная функция — вызывать и координировать действие необходимых ресурсов и объектов, нужных для выполнения действий, задаваемых пользователем. Обычно контроллер вызывает соответствующую модель для задачи и выбирает подходящий вид.
Модель (Model)
Модель даёт контроллеру представление данных, которые запросил пользователь (сообщение, страницу книги, фотоальбом, и тому подобное). Модель данных будет одинаковой, вне зависимости от того, как мы хотим представлять их пользователю. Поэтому мы выбираем любой доступный вид для отображения данных.
Модель содержит наиболее важную часть логики нашего приложения, логики, которая решает задачу, с которой мы имеем дело (форум, магазин, банк, и тому подобное). Контроллер содержит в основном организационную логику для самого приложения (очень похоже на ведение домашнего хозяйства).
Вид (View)
Вид обеспечивает различные способы представления данных, которые получены из модели. Он может быть шаблоном, который заполняется данными. Может быть несколько различных видов, и контроллер выбирает, какой подходит наилучшим образом для текущей ситуации.
Веб приложение обычно состоит из набора контроллеров, моделей и видов. Контроллер может быть устроен как основной, который получает все запросы и вызывает другие контроллеры для выполнения действий в зависимости от ситуации.
Разберём пример
Предположим, нам надо разработать онлайновый книжный магазин. Пользователь может выполнять следующие действия: просматривать книги, регистрироваться, покупать, добавлять пункты к текущему заказу, создавать или удалять книги (если он администратор). Давайте посмотрим, что произойдёт, когда пользователь нажмёт на категорию фэнтези для просмотра названий книг, которые имеются в нашем магазине.
У нас есть определённый контроллер для обработки всех действий, связанных с книгами (просматривать, редактировать, создавать и так далее). Давайте назовем его books_controller.php в нашем примере. Также нам нужна модель, например, book_model.php, которая обрабатывает данные и логику, связанные с позицией в магазине. В заключение, нам нужно несколько видов для представления данных, например, список книг, страница для редактирования и так далее.
Следующий рисунок показывает, как обрабатывается запрос пользователя для просмотра списка книг по теме фэнтези:
Контроллер (books_controller.php) получает запрос пользователя [1] (запрос HTTP GET или POST). Мы можем организовать центральный контроллер, например, index.php, который получает запрос и вызывает books_controller.php.
Контроллер проверяет запрос и параметры, а затем вызывает модель(book_model.php), запрашивая у неё список доступных книг по теме фэнтези [2].
Модель получает данные из базы (или из другого источника, в котором хранится информация) [3], применяет фильтры и необходимую логику, а затем возвращает данные, которые представляют список книг [4].
Контроллер использует подходящий вид [5] для представления данных пользователю 6. Если запрос приходит с мобильного телефона, используется вид для мобильного телефона; если пользователь использует определённое оформление интерфейса, то выбирается соответствующий вид, и так далее.
В чем преимущества?
Самое очевидное преимущество, которое мы получаем от использования концепции MVC — это чёткое разделение логики представления (интерфейса пользователя) и логики приложения.
Поддержка различных типов пользователей, которые используют различные типы устройств является общей проблемой наших дней. Предоставляемый интерфейс должен различаться, если запрос приходит с персонального компьютера или с мобильного телефона. Модель возвращает одинаковые данные, единственное различие заключается в том, что контроллер выбирает различные виды для вывода данных.
Помимо изолирования видов от логики приложения, концепция MVC существенно уменьшает сложность больших приложений. Код получается гораздо более структурированным, и, тем самым, облегчается поддержка, тестирование и повторное использование решений.
А зачем использовать рабочую среду?
Когда вы используете рабочую среду, базовая структура MVC уже подготовлена, и вам остаётся только расширить структуру, размещая ваши файлы в соответствующих директориях для соответствия шаблону MVC. Кроме того, у вас будет набор функций, которые уже написаны и хорошо протестированы.
Рассмотрим cakePHP в качестве примера рабочей среды MVC. После установки у вас будет три основных директории:
Папка app является местом размещения ваших файлов. Это место для разработки вашей части приложения.
В папке cake размещаются файлы cakePHP (функциональность рабочей среды).
Папка vendors служит для хранения библиотек PHP сторонних разработчиков.
Ваше рабочее пространство (директория app) имеет следующую структуру:
Вам нужно размещать ваши контроллеры в директории controllers, модели в директории models и виды в директории views!
Как только вы начнёте использовать рабочую среду, то сразу станет ясно, где размещается практически любая часть вашего приложения, которую надо создать или модифицировать. Такая организация сама по себе значительно упрощает процесс разработки и поддержки приложения.
Использование рабочей среды для нашего примера
Так как данный урок не имеет целью показать процесс создания приложения с помощью cakePHP, то мы покажем только код для модели, контроллера и вида с комментариями о преимуществах использования рабочей среды MVC. Код специально упрощён и непригоден для использования в реальном приложении.
Помните, мы рассматривали книжный магазин и любопытного пользователя, который хотел увидеть полный список книг по теме фэнтези. Контроллер получал запрос пользователя и координировал необходимые действия.
Итак, как только пользователь нажимает кнопку, браузер запрашивает данный url:
Контроллер
В рабочей среде cakePHP, наш контроллер будет выглядеть так:
Просто, не так ли?. Данный контроллер будет сохранен как books_controller.php и размещён в /app/controllers. Он содержит список функций, которые выполняют действия для нашего примера, а также другие функции для выполнения связанных с книгами операций (добавить новую книгу, удалить книгу, и так далее).
Рабочая среда предоставляет нам множество готовых решений и нужно только сформировать список книг. Есть базовый класс, в котором уже определено базовое функционирование контроллера, таким образом, надо унаследовать свойства и функции этого класса (AppController является наследником Controller).
Все что нужно сделать в списке действий — вызвать модель для получения данных и затем выбрать вид для представления их пользователю. Вот как это делается.
сообщает модели, что нужно вернуть список книг по выбранной теме (мы рассмотрим модель позже).
Метод 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!
Данный урок подготовлен для вас командой сайта ruseller.com
Источник урока: net.tutsplus.com/tutorials/other/mvc-for-noobs/
Перевел: Сергей Фастунов
Урок создан: 4 Августа 2010
Просмотров: 374392
Правила перепечатки
5 последних уроков рубрики «PHP»
Фильтрация данных с помощью zend-filter
Когда речь идёт о безопасности веб-сайта, то фраза «фильтруйте всё, экранируйте всё» всегда будет актуальна. Сегодня поговорим о фильтрации данных.
Контекстное экранирование с помощью zend-escaper
Обеспечение безопасности веб-сайта — это не только защита от SQL инъекций, но и протекция от межсайтового скриптинга (XSS), межсайтовой подделки запросов (CSRF) и от других видов атак. В частности, вам нужно очень осторожно подходить к формированию HTML, CSS и JavaScript кода.
Подключение Zend модулей к Expressive
Expressive 2 поддерживает возможность подключения других ZF компонент по специальной схеме. Не всем нравится данное решение. В этой статье мы расскажем как улучшили процесс подключение нескольких модулей.
Совет: отправка информации в Google Analytics через API
Предположим, что вам необходимо отправить какую-то информацию в Google Analytics из серверного скрипта. Как это сделать. Ответ в этой заметке.
Подборка PHP песочниц
Подборка из нескольких видов PHP песочниц. На некоторых вы в режиме online сможете потестить свой код, но есть так же решения, которые можно внедрить на свой сайт.
Что такое MVC: рассказываем простыми словами
Современные сайты интерактивные и динамичные, то есть они реагируют на действия пользователя, обрабатывают его запросы и выдают результат. Так работают онлайн-сервисы, например, интернет-банкинг или онлайн-кинотеатр. Для создания интерактивных и динамичных сайтов обычно используется архитектурный паттерн MVC. В этой статье простыми словами объясняется суть этой модели.
Что такое модель MVC: теория
Статическая страница на HTML не умеет реагировать на действия пользователя. Для двухстороннего взаимодействия нужны динамические веб-страницы. MVC — ключ к пониманию разработки динамических веб-приложений, поэтому разработчику нужно знать эту модель.
MVC расшифровывается как модель-представление-контроллер (от англ. model-view-controller). Это способ организации кода, который предполагает выделение блоков, отвечающих за решение разных задач. Один блок отвечает за данные приложения, другой отвечает за внешний вид, а третий контролирует работу приложения. Компоненты MVC:
Чтобы лучше понять теоретическую информацию, используем абстрактное описание.
Разбираем MVC на примере магазина сэндвичей
Мы уже рассматривали работу с вложенными коллбэками на примере приготовления гамбургеров. Продолжаем традицию: разберем паттерн MVC на примере магазина сэндвичей.
Представьте, что вы пришли в магазин или кафе, где можно заказать сэндвич. В меню есть бутерброды с тунцом, индейкой и ветчиной. Вы заказываете сэндвич с индейкой.
Продавец или бармен с полуслова понимает вас. Он поворачивается в сторону кухни и говорит поварам, чтобы они приготовили сэндвич с индейкой.
У поваров под рукой есть разные продукты: тунец, индейка, ветчина, сыр, листья салата и другие ингредиенты, которые добавляют в бутерброды. Они выбирают только то, что нужно для вашего сэндвича с индейкой. Вы получаете свой заказ.
Покупку бутерброда можно описать через MVC:
Вы уже представляли готовый сэндвич с индейкой, когда заказывали его бармену. Это представление или view.
Справка: иногда модель MVC расшифровывают как модель-вид-контроллер. Это не ошибка, но всё-таки корректнее переводить view как представление.
Точно так же можно представить взаимодействие с сайтом. Когда вы заходите в «Фейсбук» и переходите по ссылке «Друзья», то заранее представляете результат перехода по ссылке. Это список ваших друзей.
Когда вы нажимаете на ссылку «Друзья», на сервер «Фейсбука» уходит запрос. В нём содержится просьба показать вам список друзей. Это очень похоже на просьбу продать вам бутерброд с индейкой. Это контроллер.
На сервере «Фейсбука» ваш запрос обрабатывается. Программа достаёт из базы данных всех ваших друзей, чтобы показать список. Это можно сравнить с кухней и поварами из примера с сэндвичем. Это модель.
«Фейсбук» берёт нужные ингредиенты из базы данных и готовит ваш заказ: список друзей. Тем же занимались повара на кухне магазина сэндвичей. Это снова представление или view.
Изучайте фронтенд- и бэкенд-разработку на JavaScript На Хекслете есть профессии «Фронтенд-программист» и «Node.js-программист». В процессе обучения на этих профессиях вы научитесь программировать на JavaScript, изучите современные инструменты для разработки фронтенд- и бэкенд-приложений, включая React, Redux, Express.js, Koa, PostgreSQL. Первые курсы в профессиях доступны бесплатно.
Паттерн MVC в реальной веб-разработке: простые примеры
Ниже представлены простые примеры MVC, которые используются в веб-фреймворках.
Контроллер
Контроллер обрабатывает входящие запросы. В фреймворке это может заключаться в определении конкретных URL, на которые попадает пользователь при переходе по ссылке или при нажатии кнопки.
Модель
Модель отвечает за данные, которые хранятся и обрабатываются на сервере.
Представление
Это HTML-шаблон, который возвращает сервер после обработки запроса. Если запрос корректно обрабатывается, вы получаете веб-страницу со списком друзей. Если запрос некорректный, вы попадаете на страницу ошибки 404.
Заключение
MVC — подход к проектированию приложения, который предполагает выделение кода в блоки модель, представление и контроллер. Контроллер обрабатывает входящие запросы. Модель достаёт из базы данных информацию, нужную для выполнения конкретных запросов. Представление определяет результат запроса, который получает пользователь.
Если у вас остались вопросы по MVC, задавайте их в комментариях.
Никогда не останавливайтесь: В программировании говорят, что нужно постоянно учиться даже для того, чтобы просто находиться на месте. Развивайтесь с нами — на Хекслете есть сотни курсов по разработке на разных языках и технологиях
С нуля до разработчика. Возвращаем деньги, если не удалось найти работу.
23) PHP MVC Framework
Что такое PHP MVC Framework?
PHP MVC — это шаблон проектирования приложения, который отделяет данные приложения и бизнес-логику (модель) от представления (представления). MVC расшифровывается как Model, View & Controller.
Контроллер является посредником между моделями и видами.
Думайте о модели проектирования MVC как о машине и водителе.
У автомобиля есть ветровые стекла (вид), которые водитель (диспетчер) использует для мониторинга движения вперед, затем скорости или тормоза (модель) в зависимости от того, что он видит впереди.
Зачем использовать PHP MVC Framework?
В этом уроке вы узнаете
PHP MVC Design Pattern
Давайте теперь кратко обсудим каждый компонент шаблона проектирования MVC.
Модель — эта часть связана с бизнес-логикой и данными приложения. Он может использоваться для проверки данных, обработки данных и их хранения. Данные могут поступать из;
Контроллер — эта часть занимается запросами пользователей на ресурсы с сервера.
В двух словах, контроллер связывает модели и представления вместе в зависимости от запрашиваемых ресурсов.
Представления — эта часть посвящена представлению данных пользователю. Обычно это в виде HTML-страниц.
Типы PHP MVC фреймворка
Выбор лучшего фреймворка PHP — это сложная задача.
Вам не нужно писать свой собственный фреймворк, чтобы воспользоваться преимуществами MVC.
Вам следует только попытаться создать свой собственный проект приложения, связанный с MVC, чтобы понять, как работают инфраструктуры MVC.
Когда вы освоитесь с тем, как работают фреймворки MVC, вам следует перейти к зрелым и уже протестированным фреймворкам.
В таблице ниже кратко описаны некоторые популярные фреймворки php и функции, которые предлагает каждая фреймворк.
