rockfanatics.ru → Интернет

Mvc простыми словами. Создание движка на MVC

Концепция MVC (Model-View-Controller: модель-вид-контроллер) очень часто упоминается в мире веб программирования в последние годы. Каждый, кто хоть как-то связан с разработкой веб приложений, так или иначе сталкивался с данным акронимом. Сегодня мы разберёмся, что такое - концепция MVC, и почему она стала популярной.

Древнейшая история

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

Впервые она была описана в 1979 году, конечно же, для другого окружения. Тогда не существовало концепции веб приложения. Tim Berners Lee (Тим Бернерс Ли) посеял семена World Wide Web (WWW) в начале девяностых и навсегда изменил мир. Шаблон, который мы используем сегодня, является адаптацией оригинального шаблона к веб разработке.

Бешеная популярность данной структуры в веб приложениях сложилась благодаря её включению в две среды разработки, которые стали очень популярными: Struts и Ruby on Rails. Эти две среды разработки наметили пути развития для сотен рабочих сред, созданных позже.

MVC для веб приложений

Идея, которая лежит в основе конструкционного шаблона MVC, очень проста: нужно чётко разделять ответственность за различное функционирование в наших приложениях:

Приложение разделяется на три основных компонента, каждый из которых отвечает за различные задачи. Давайте подробно разберём компоненты на примере.

Контроллер (Controller)

Контроллер управляет запросами пользователя (получаемые в виде запросов HTTP GET или POST, когда пользователь нажимает на элементы интерфейса для выполнения различных действий). Его основная функция — вызывать и координировать действие необходимых ресурсов и объектов, нужных для выполнения действий, задаваемых пользователем. Обычно контроллер вызывает соответствующую модель для задачи и выбирает подходящий вид.

Модель (Model)

Модель - это данные и правила, которые используются для работы с данными, которые представляют концепцию управления приложением. В любом приложении вся структура моделируется как данные, которые обрабатываются определённым образом. Что такое пользователь для приложения — сообщение или книга? Только данные, которые должны быть обработаны в соответствии с правилами (дата не может указывать в будущее, e-mail должен быть в определённом формате, имя не может быть длиннее Х символов, и так далее).

Модель даёт контроллеру представление данных, которые запросил пользователь (сообщение, страницу книги, фотоальбом, и тому подобное). Модель данных будет одинаковой, вне зависимости от того, как мы хотим представлять их пользователю. Поэтому мы выбираем любой доступный вид для отображения данных.

Модель содержит наиболее важную часть логики нашего приложения, логики, которая решает задачу, с которой мы имеем дело (форум, магазин, банк, и тому подобное). Контроллер содержит в основном организационную логику для самого приложения (очень похоже на ведение домашнего хозяйства).

Вид (View)

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

Веб приложение обычно состоит из набора контроллеров, моделей и видов. Контроллер может быть устроен как основной, который получает все запросы и вызывает другие контроллеры для выполнения действий в зависимости от ситуации.

Разберём пример

Предположим, нам надо разработать онлайновый книжный магазин. Пользователь может выполнять следующие действия: просматривать книги, регистрироваться, покупать, добавлять пункты к текущему заказу, создавать или удалять книги (если он администратор). Давайте посмотрим, что произойдёт, когда пользователь нажмёт на категорию фэнтези для просмотра названий книг, которые имеются в нашем магазине.

У нас есть определённый контроллер для обработки всех действий, связанных с книгами (просматривать, редактировать, создавать и так далее). Давайте назовем его books_controller.php в нашем примере. Также нам нужна модель, например, book_model.php , которая обрабатывает данные и логику, связанные с позицией в магазине. В заключение, нам нужно несколько видов для представления данных, например, список книг, страница для редактирования и так далее.

Следующий рисунок показывает, как обрабатывается запрос пользователя для просмотра списка книг по теме фэнтези :

Контроллер (books_controller.php) получает запрос пользователя (запрос HTTP GET или POST). Мы можем организовать центральный контроллер, например, index.php, который получает запрос и вызывает books_controller.php.

Контроллер проверяет запрос и параметры, а затем вызывает модель(book_model.php), запрашивая у неё список доступных книг по теме фэнтези .

Модель получает данные из базы (или из другого источника, в котором хранится информация) , применяет фильтры и необходимую логику, а затем возвращает данные, которые представляют список книг .

Контроллер использует подходящий вид для представления данных пользователю . Если запрос приходит с мобильного телефона, используется вид для мобильного телефона; если пользователь использует определённое оформление интерфейса, то выбирается соответствующий вид, и так далее.

В чем преимущества?

Самое очевидное преимущество, которое мы получаем от использования концепции MVC — это чёткое разделение логики представления (интерфейса пользователя) и логики приложения.

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

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

А зачем использовать рабочую среду?

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

Рассмотрим cakePHP в качестве примера рабочей среды MVC. После установки у вас будет три основных директории:

cake/
vendors/

Папка app является местом размещения ваших файлов. Это место для разработки вашей части приложения.

В папке cake размещаются файлы cakePHP (функциональность рабочей среды).

Папка vendors служит для хранения библиотек PHP сторонних разработчиков.

Ваше рабочее пространство (директория app) имеет следующую структуру:

app/
- config/
- controllers/
- locale/
- models/
- plugins/
- tests/
- vendors/
- views/
- webroot/

Вам нужно размещать ваши контроллеры в директории controllers , модели в директории models и виды в директории views !

Как только вы начнёте использовать рабочую среду, то сразу станет ясно, где размещается практически любая часть вашего приложения, которую надо создать или модифицировать. Такая организация сама по себе значительно упрощает процесс разработки и поддержки приложения.

Использование рабочей среды для нашего примера

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

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

Итак, как только пользователь нажимает кнопку, браузер запрашивает данный url:

Www.ourstore.com/books/list/fantasy

CakePHP форматирует URL по шаблону /controller/action/param1/param2 , где action - это функция, которая вызывается контроллером. В старом классическом виде url будет выглядеть так:

Www.ourstore.com/books_controller.php?action=list&category=fantasy

Контроллер

В рабочей среде cakePHP, наш контроллер будет выглядеть так:

class BooksController extends AppController {

Function list($category) {

$this->set("books", $this->Book->findAllByCategory($category));

Function add() { ... ... }

Function delete() { ... ... }

... ... } ?>

Просто, не так ли?. Данный контроллер будет сохранен как books_controller.php и размещён в /app/controllers . Он содержит список функций, которые выполняют действия для нашего примера, а также другие функции для выполнения связанных с книгами операций (добавить новую книгу, удалить книгу, и так далее).

Рабочая среда предоставляет нам множество готовых решений и нужно только сформировать список книг. Есть базовый класс, в котором уже определено базовое функционирование контроллера, таким образом, надо унаследовать свойства и функции этого класса (AppController является наследником Controller ).

Все что нужно сделать в списке действий — вызвать модель для получения данных и затем выбрать вид для представления их пользователю. Вот как это делается.

this->Book - это наша модель, и часть кода:

$this->Book->findAllByCategory($category)

сообщает модели, что нужно вернуть список книг по выбранной теме (мы рассмотрим модель позже).

Метод set в строке:

$this->set("books", $this->Book->findAllByCategory($category));

Контроллер передаёт данные виду. Переменная books принимает данные, возвращённые моделью, и они становятся доступными для вида.

Теперь остаётся только вывести на экран вид, но эта функция выполняется автоматически в cakePHP, если мы используем вид по умолчанию. Если мы хотим использовать другой вид, то надо явно вызвать метод render .

Модель

Модель даже ещё проще:

class Book extends AppModel {

Почему она пустая? Потому что она является наследником базового класса, который обеспечивает необходимую функциональность и нам нужно использовать соглашение об именах в CakePHP для того, чтобы рабочая среда выполняла все другие задачи автоматически. Например, cakePHP известно на основании имени, что данная модель используется в BooksController , и что она имеет доступ к таблице базы данных с именем books.

С таким определением у нас будет модель, которая может только читать, удалять или сохранять данные в базе данных.

Код сохраняем как book.php в папке /app/models .

Вид

Все, что нам нужно теперь сделать — это создать вид (по крайней мере, один) для списка действий. Вид будет иметь код HTML и несколько (как можно меньше) строк кода PHP для организации цикла по массиву книг, которые предоставляется моделью.

Название
Автор
Цена

Как можно заметить, вид создаёт не полноценную страницу, а лишь фрагмент HTML (таблицу в данном случае). Потому, что CakePHP обеспечивает другой способ для определения шаблона страницы, и вид вставляется в данный шаблон. Рабочая среда также обеспечивает нас некоторыми вспомогательными объектами для выполнения общих задач во время создания частей HTML страницы (вставка форм, ссылок, Ajax или JavaScript).

Сохраняем вид как list.ctp (list — это имя действия, а ctp означает шаблон CakePHP) в папке /app/views/books (потому, что это вид для действия контроллера).

Вот так выполняются все три компонента с помощью рабочей среды CakePHP!

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

Вы можеть быть даже слышали о шаблонах проектирования и даже листали эти прекрасные книги:

Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидесс «Приемы объектно ориентированного проектирования. Паттерны проектирования»;
М. Фаулер «Архитектура корпоративных программных приложений».

А многие, не испугавшись огромных руководств и документаций, пытались изучить какой-либо из современных фреймворков и столкнувшись со сложностью понимания (в силу наличия множества архитектруных концепций хитро увязанных между собой) отложили изучение и применение современных интсрументов в «долгий ящик».

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

Прожженные PHP-программисты вряд ли найдут в данной статье что-то новое для себя, но их замечания и комментарии к основному тексту были бы очень кстати! Т.к. без теории практика невозможна, а без практики теория бесполезна, то сначала будет чуть-чуть теории, а потом перейдем к практике. Если вы уже знакомы с концепцией MVC, можете пропустить раздел с теорией и сразу перейти к практике.

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

Рассмотрим концептуальную схему шаблона MVC (на мой взгляд - это наиболее удачная схема из тех, что я видел):

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

Типичную последовательность работы MVC-приложения можно описать следующим образом:

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

Приложение получает запрос от пользователя и определяет запрошенные контроллер и действие. В случае главной страницы, выполняется действие по умолчанию (index ).

Приложение создает экземпляр контроллера и запускает метод действия,
в котором, к примеру, содержаться вызовы модели, считывающие информацию из базы данных.

После этого, действие формирует представление с данными, полученными из модели и выводит результат пользователю.

Модель - содержит бизнес-логику приложения и включает методы выборки (это могут быть методы ORM), обработки (например, правила валидации) и предоставления конкретных данных, что зачастую делает ее очень толстой, что вполне нормально.
Модель не должна напрямую взаимодействовать с пользователем. Все переменные, относящиеся к запросу пользователя должны обрабатываться в контроллере.
Модель не должна генерировать HTML или другой код отображения, который может изменяться в зависимости от нужд пользователя. Такой код должен обрабатываться в видах.
Одна и та же модель, например: модель аутентификации пользователей может использоваться как в пользовательской, так и в административной части приложения. В таком случае можно вынести общий код в отдельный класс и наследоваться от него, определяя в наследниках специфичные для подприложений методы.

Вид - используется для задания внешнего отображения данных, полученных из контроллера и модели.
Виды cодержат HTML-разметку и небольшие вставки PHP-кода для обхода, форматирования и отображения данных.
Не должны напрямую обращаться к базе данных. Этим должны заниматься модели.
Не должны работать с данными, полученными из запроса пользователя. Эту задачу должен выполнять контроллер.
Может напрямую обращаться к свойствам и методам контроллера или моделей, для получения готовых к выводу данных.
Виды обычно разделяют на общий шаблон, содержащий разметку, общую для всех страниц (например, шапку и подвал) и части шаблона, которые используют для отображения данных выводимых из модели или отображения форм ввода данных.

Контроллер - связующее звено, соединяющее модели, виды и другие компоненты в рабочее приложение. Контроллер отвечает за обработку запросов пользователя. Контроллер не должен содержать SQL-запросов. Их лучше держать в моделях. Контроллер не должен содержать HTML и другой разметки. Её стоит выносить в виды.
В хорошо спроектированном MVC-приложении контроллеры обычно очень тонкие и содержат только несколько десятков строк кода. Чего, не скажешь о Stupid Fat Controllers (SFC) в CMS Joomla. Логика контроллера довольно типична и большая ее часть выносится в базовые классы.
Модели, наоборот, очень толстые и содержат большую часть кода, связанную с обработкой данных, т.к. структура данных и бизнес-логика, содержащаяся в них, обычно довольно специфична для конкретного приложения.

1.1. Front Controller и Page Controller В большинстве случае, взаимодействие пользователя с web-приложением проходит посредством переходов по ссылкам. Посмотрите сейчас на адресную строку браузера - по этой ссылке вы получили данный текст. По другим ссылкам, например, находящимся справа на этой странице, вы получите другое содержимое. Таким образом, ссылка представляет конкретную команду web-приложению.

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

Рассмотрим два варианта адресной строки, по которым показывается какой-то текст и профиль пользователя.

Приблизительный код обработки в таком случае:
switch($_GET["action"]) { case "about" : require_once("about.php"); // страница "О Нас" break; case "contacts" : require_once("contacts.php"); // страница "Контакты" break; case "feedback" : require_once("feedback.php"); // страница "Обратная связь" break; default: require_once("page404.php"); // страница "404" break; }
Думаю, почти все так раньше делали.

С использованием движка маршрутизации URL вы сможете для отображения той же информации настроить приложение на прием таких запросов:
http://www.example.com/contacts/feedback

Здесь contacts представляет собой контроллер, а feedback - это метод контроллера contacts, отображающий форму обратной связи и т.д. Мы еще вернемся к этому вопросу в практической части.

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

2. Практика Для начала создадим следующую структуру файлов и папок:

Забегая вперед, скажу, что в папке core будут храниться базовые классы Model, View и Controller.
Их потомки будут храниться в директориях controllers, models и views. Файл index.php это точка в хода в приложение. Файл bootstrap.php инициирует загрузку приложения, подключая все необходимые модули и пр.

Будем идти последовательно; откроем файл index.php и наполним его следующим кодом:
ini_set("display_errors", 1); require_once "application/bootstrap.php";
Тут вопросов возникнуть не должно.

Следом, сразу же перейдем к фалу bootstrap.php :
require_once "core/model.php"; require_once "core/view.php"; require_once "core/controller.php"; require_once "core/route.php"; Route::start(); // запускаем маршрутизатор
Первые три строки будут подключать пока что несуществующие файлы ядра. Последние строки подключают файл с классом маршрутизатора и запускают его на выполнение вызовом статического метода start.

2.1. Реализация маршрутизатора URL Пока что отклонимся от реализации паттерна MVC и займемся мрашрутизацией. Первый шаг, который нам нужно сделать, записать следующий код в .htaccess :
RewriteEngine On RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule .* index.php [L]
Этот код перенаправит обработку всех страниц на index.php , что нам и нужно. Помните в первой части мы говорили о Front Controller?!

Маршрутизацию мы поместим в отдельный файл route.php в директорию core. В этом файле опишем класс Route, который будет запускать методы контроллеров, которые в свою очередь будут генерировать вид страниц.

Содержимое файла route.php

class Route { static function start() { // контроллер и действие по умолчанию $controller_name = "Main"; $action_name = "index"; $routes = explode("/", $_SERVER["REQUEST_URI"]); // получаем имя контроллера if (!empty($routes)) { $controller_name = $routes; } // получаем имя экшена if (!empty($routes)) { $action_name = $routes; } // добавляем префиксы $model_name = "Model_".$controller_name; $controller_name = "Controller_".$controller_name; $action_name = "action_".$action_name; // подцепляем файл с классом модели (файла модели может и не быть) $model_file = strtolower($model_name).".php"; $model_path = "application/models/".$model_file; if(file_exists($model_path)) { include "application/models/".$model_file; } // подцепляем файл с классом контроллера $controller_file = strtolower($controller_name).".php"; $controller_path = "application/controllers/".$controller_file; if(file_exists($controller_path)) { include "application/controllers/".$controller_file; } else { /* правильно было бы кинуть здесь исключение, но для упрощения сразу сделаем редирект на страницу 404 */ Route::ErrorPage404(); } // создаем контроллер $controller = new $controller_name; $action = $action_name; if(method_exists($controller, $action)) { // вызываем действие контроллера $controller->$action(); } else { // здесь также разумнее было бы кинуть исключение Route::ErrorPage404(); } } function ErrorPage404() { $host = "http://".$_SERVER["HTTP_HOST"]."/"; header("HTTP/1.1 404 Not Found"); header("Status: 404 Not Found"); header("Location:".$host."404"); } }

Замечу, что в классе реализована очень упрощенная логика (несмотря на объемный код) и возможно даже имеет проблемы безопасности. Это было сделано намерено, т.к. написание полноценного класса маршрутизации заслуживает как минимум отдельной статьи. Рассмотрим основные моменты…

В элементе глобального массива $_SERVER["REQUEST_URI"] содержится полный адрес по которому обратился пользователь.
Например: example.ru/contacts/feedback

С помощью функции explode производится разделение адреса на составлющие. В результате мы получаем имя контроллера, для приведенного примера, это контроллер contacts и имя действия, в нашем случае - feedback .

Далее подключается файл модели (модель может отсутствовать) и файл контроллера, если таковые имеются и наконец, создается экземпляр контроллера и вызывается действие, опять же, если оно было описано в классе контроллера.

Таким образом, при переходе, к примеру, по адресу:
example.com/portfolio
или
example.com/portfolio/index
роутер выполнит следующие действия:

подключит файл model_portfolio.php из папки models, содержащий класс Model_Portfolio;

подключит файл controller_portfolio.php из папки controllers, содержащий класс Controller_Portfolio;

создаст экземпляр класса Controller_Portfolio и вызовет действие по умолчанию - action_index, описанное в нем.

Если пользователь попытается обратиться по адресу несуществующего контроллера, к примеру:
example.com/ufo
то его перебросит на страницу «404»:
example.com/404
То же самое произойдет если пользователь обратится к действию, которое не описано в контроллере.2.2. Возвращаемся к реализации MVC Перейдем в папку core и добавим к файлу route.php еще три файла: model.php, view.php и controller.php

Напомню, что они будут содержать базовые классы, к написанию которых мы сейчас и приступим.

Содержимое файла model.php
class Model { public function get_data() { } }
Класс модели содержит единственный пустой метод выборки данных, который будет перекрываться в классах потомках. Когда мы будем создавать классы потомки все станет понятней.

Содержимое файла view.php
class View { //public $template_view; // здесь можно указать общий вид по умолчанию. function generate($content_view, $template_view, $data = null) { /* if(is_array($data)) { // преобразуем элементы массива в переменные extract($data); } */ include "application/views/".$template_view; } }
Не трудно догадаться, что метод generate предназначен для формирования вида. В него передаются следующие параметры:

$content_file - виды отображающие контент страниц;

$template_file - общий для всех страниц шаблон;

$data - массив, содержащий элементы контента страницы. Обычно заполняется в модели.

Функцией include динамически подключается общий шаблон (вид), внутри которого будет встраиваться вид
для отображения контента конкретной страницы.

В нашем случае общий шаблон будет содержать header, menu, sidebar и footer, а контент страниц будет содержаться в отдельном виде. Опять же это сделано для упрощения.

Содержимое файла controller.php
class Controller { public $model; public $view; function __construct() { $this->view = new View(); } function action_index() { } }
Метод action_index - это действие, вызываемое по умолчанию, его мы перекроем при реализации классов потомков.

2.3. Реализация классов потомков Model и Controller, создание View"s Теперь начинается самое интересное! Наш сайт-визитка будет состоять из следущих страниц:

Главная

Услуги

Портфолио

Контакты

А также - страница «404»

Для каждой из страниц имеется свой контроллер из папки controllers и вид из папки views. Некоторые страницы могут использовать модель или модели из папки models.

На предыдущем рисунке отдельно выделен файл template_view.php - это шаблон, содержащий общую для всех страниц разметку. В простейшем случае он мог бы выглядеть так:
Главная
Для придания сайту презентабельного вида сверстаем CSS шаблон и интегририруем его в наш сайт путем изменения структуры HTML-разметки и подключения CSS и JavaScript файлов:

В конце статьи, в разделе «Результат», приводится ссылка на GitHub-репозиторий с проектом, в котором проделаны действия по интеграции простенького шаблона.

2.3.1. Создадаем главную страницу Начнем с контроллера controller_main.php , вот его код:
class Controller_Main extends Controller { function action_index() { $this->view->generate("main_view.php", "template_view.php"); } }
В метод generate экземпляра класса View передаются имена файлов общего шаблона и вида c контентом страницы.
Помимо индексного действия в контроллере конечно же могут содержаться и другие действия.

Файл с общим видом мы рассмотрели ранее. Рассмотрим файл контента main_view.php :
Добро пожаловать!

ОЛОЛОША TEAM - команда первоклассных специалистов в области разработки веб-сайтов с многолетним опытом коллекционирования мексиканских масок, бронзовых и каменных статуй из Индии и Цейлона, барельефов и изваяний, созданных мастерами Экваториальной Африки пять-шесть веков назад...

Здесь содержиться простая разметка без каких либо PHP-вызовов.
Для отображения главной странички можно воспользоваться одним из следующих адресов:

Пример с использованием вида, отображающего данные полученные из модели мы рассмотрим далее.

2.3.2. Создадаем страницу «Портфолио» В нашем случае, страница «Портфолио» - это единственная страница использующая модель.
Модель обычно включает методы выборки данных, например:

методы нативных библиотек pgsql или mysql;

методы библиотек, реализующих абстракицю данных. Например, методы библиотеки PEAR MDB2;

методы ORM;

методы для работы с NoSQL;

и др.

Для простоты, здесь мы не будем использовать SQL-запросы или ORM-операторы. Вместо этого мы сэмулируем реальные данные и сразу возвратим массив результатов.
Файл модели model_portfolio.php поместим в папку models. Вот его содержимое:
class Model_Portfolio extends Model { public function get_data() { return array(array("Year" => "2012", "Site" => "http://DunkelBeer.ru", "Description" => "Промо-сайт темного пива Dunkel от немецкого производителя Löwenbraü выпускаемого в России пивоваренной компанией "CАН ИнБев"."), array("Year" => "2012", "Site" => "http://ZopoMobile.ru", "Description" => "Русскоязычный каталог китайских телефонов компании Zopo на базе Android OS и аксессуаров к ним."), // todo); } }

Класс контроллера модели содержится в файле controller_portfolio.php , вот его код:
class Controller_Portfolio extends Controller { function __construct() { $this->model = new Model_Portfolio(); $this->view = new View(); } function action_index() { $data = $this->model->get_data(); $this->view->generate("portfolio_view.php", "template_view.php", $data); } }
В переменную data записывается массив, возвращаемый методом get_data , который мы рассматривали ранее.
Далее эта переменная передается в качестве параметра метода generate , в который также передаются: имя файла с общим шаблон и имя файла, содержащего вид c контентом страницы.

Вид содержащий контент страницы находится в файле portfolio_view.php .
Портфолио

Все проекты в следующей таблице являются вымышленными, поэтому даже не пытайтесь перейти по приведенным ссылкам.

Год

Проект

Описание

Здесь все просто, вид отображает данные полученные из модели.

2.3.3. Создаем остальные страницы Остальные страницы создаются аналогично. Их код досутпен в репозитории на GitHub, ссылка на который приводится в конце статьи, в разделе «Результат».3. Результат А вот что получилось в итоге:

Скриншот получившегося сайта-визитки

Ссылка на GitHub: https://github.com/vitalyswipe/tinymvc/zipball/v0.1

А вот в этой версии я набросал следующие классы (и соответствующие им виды):

Controller_Login в котором генерируется вид с формой для ввода логина и пароля, после заполнения которой производится процедура аутентификации и в случае успеха пользователь перенаправляется в админку.
Contorller_Admin с индексным действием, в котором проверяется был ли пользователь ранее авторизован на сайте как администратор (если был, то отображается вид админки) и действием logout для разлогинивания.

Аутентификация и авторизация - это другая тема, поэтому здесь она не рассматривается, а лишь приводится ссылка указанная выше, чтобы было от чего оттолкнуться.4. Заключение Шаблон MVC используется в качестве архитектурной основы во многих фреймворках и CMS, которые создавались для того, чтобы иметь возможность разрабатывать качественно более сложные решения за более короткий срок. Это стало возможным благодаря повышению уровня абстракции, поскольку есть предел сложности конструкций, которыми может оперировать человеческий мозг.

Но, использование веб-фреймворков, типа Yii или Kohana, состоящих из нескольких сотен файлов, при разработке простых веб-приложений (например, сайтов-визиткок) не всегда целесообразно. Теперь мы умеем создавать красивую MVC модель, чтобы не перемешивать Php, Html, CSS и JavaScript код в одном файле.

Данная статья является скорее отправной точкой для изучения CMF, чем примером чего-то истинно правильного, что можно взять за основу своего веб-приложения. Возможно она даже вдохновила Вас и вы уже подумываете написать свой микрофреймворк или CMS, основанные на MVC. Но, прежде чем изобретать очередной велосипед с «блекджеком и шлюхами», еще раз подумайте, может ваши усилия разумнее направить на развитие и в помощь сообществу уже существующего проекта?!

P.S.: Статья была переписана с учетом некоторых замечаний, оставленных в комментариях. Критика оказалась очень полезной. Судя по отклику: комментариям, обращениям в личку и количеству юзеров добавивших пост в избранное затея написать этот пост оказалось не такой уж плохой. К сожалению, не возможно учесть все пожелания и написать больше и подробнее по причине нехватки времени… но возможно это сделают те таинственные личности, кто минусовал первоначальный вариант. Удачи в проектах!

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

Теги:

php
framework
cmf
mvc
site

Добавить метки

Всем привет! Продолжаем строить собственное MVC приложение , и сегодня мы начнем заниматься выводом страниц.

Создадим файл View.php в папке libs .

Теперь откроем наш главный файл index.php и подключим его.

Require "libs/View.php";

Открыв страницу, мы должны увидеть надпись "Это вид".

Теперь немного изменим наш класс, отвечающий за вид, добавив метод render , который будет заниматься выводом.

Теперь создадим папки index и error в папке views . Они будут отвечать за представление index страницы и страницы ошибок. В папке error создадим новый index.php файл и пропишем следующее

Это страница ошибки!

Теперь создадим файл header.php в самой папке views с таким содержанием

Header

Перейдем в файл error.php , который находится в папке error и добавим в конструктор вызов метода render .

Теперь на странице мы увидим "Header Это страница ошибки!"

Давайте немного улучшим наш контроллер, добавив к нему перед вызовом метода render следующее:

А теперь в файле index.php , который отвечает за вид ошибки, вместо нашей надписи "Это страница ошибки!" выведим то, что хранится в свойстве msg .

Теперь нам вывелась наша надпись.

Давайте теперь создадим модель help_model.php в папке models .

Теперь откроем контроллер help.php из папки controllers и добавим вызов нашей модели

Наша модель будет работать с базой данных, но пока что закомментируем это, т.к. у нас еще нет базы данных.

Подключим нашу базовую модель в нашем главном файле index.php .

Require "libs/Bootstrap.php"; require "libs/Controller.php"; require "libs/model.php"; require "libs/View.php";

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

В данной статье мы разберемся с понятием MVC, и как, на примере, можно применить это в PHP.

Понятие MVC

MVC (Model-view-controller, «Модель-представление-поведение », «Модель-представление-контроллер ») — это шаблон проектирования приложений, при котором управляющая логика поделена на три отдельных компонента таким образом, что модифицирование одного из них дает минимальное влияние на остальные.

Шаблон MVC хорошо применять при создании сложных проектов, где необходимо отделить работу php программиста (или разделить группу программистов на отделы), дизайнера, верстальщика, и т.д.

Шаблон MVC разделяет представление, данные, и обработку действий пользователя на три отдельных компонента:

MVC Модель (Model). Модель предоставляет данные (обычно для View), а также реагирует на запросы (обычно от контроллера), изменяя своё состояние.

MVC Представление (View). Отвечает за отображение информации (пользовательский интерфейс).

MVC Поведение (Controller). Интерпретирует данные, введённые пользователем, и информирует модель и представление о необходимости соответствующей реакции.

Для наглядности схемы действия шаблона MVC, ниже предоставлена иллюстрация.

Такие компоненты как представление и поведение зависят от модели, но никак не влияют на нее. Модель может иметь несколько представлений. Может быть, концепция MVCсложная для понимания, но если ее осмыслить, она становиться незаменимой при разработке приложений на PHP.

MVC в PHP

Особенностью при использовании MVC в PHP, является то, что существует одна точка входа в php приложение, которая, например, достигается следующим образом. Создается index.php через который будут обрабатываться все запросы, для этого создаем в папке с индексом файл.htaccess и помещаем в него такой код:

RewriteEngine on RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^(.*)$ index.php?route=$1

В предоставленном коде, первой строкой, проверяется существование запрашиваемого файла, и если его нет, то идет перенаправление на index.php, иначе даже запросы картинок сайта будут перенаправляться на индекс. Последняя строка кода преобразовывает запросы вида index.php?route=chat/index у вид index.php/chat/index. Если у вас нет возможности использовать ModRewrite в своем приложении, то вам придется делать переадресацию вручную.

PHP Модель

Данные о PHP модели содержаться в ее атрибутах и могут быть изменены только через специальные функции. Модель может содержать в себе несколько представлений. Как правило, phpмодель это класс работающий с БД, конкретнее: запись, чтение, удаление. Естественно чтение информации с БД может быть реализовано несколькими представлениями (функциями). Как пример модель статей на сайте: можно получить конкретную статью из БД, список последних, популярных, какой-то категории… это все представления модели. Для наглядности ниже предоставлен пример php модели.

PHP контролер (Поведение)

PHP контролеры получают запросы пользователей, которые мы направляли через index.php, и в соответствии с ними, корректируют работу модели. Правильнее сказать контролируют работу php приложения.

PHP Представление

Представление отслеживает изменение в модели и создает или меняет интерфейс php приложения.

List of Datas

Как работает данный PHP MVC шаблон?

При обращении пользователем по нужному url выбирается соответственный контролер, который обращается к представлению и модели, и выводится информация. Другими словами контролер в mvc есть связующим звеном модели и представления.

Преимущества MVC шаблона при создании PHP приложения

Как упоминалось выше это, прежде всего дифференциация разработчиков php сайта на отделы. Также увеличивается скорость работы php приложения, если создается крупный проект. Ну и то, что касается непосредственно самого php разработчика, это правильная структуризация php кода (все на своих местах, так легче для понимания).

MVC пример

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

Еще одна схема работы MVC шаблона на PHP, она более чем доступна для понимания.

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

домашняя страница, отображающая информацию о вечеринке;

форма, которая может использоваться для ответа на приглашение (repondez s"il vous plait - RSVP);

проверка достоверности для формы RSVP, которая будет отображать страницу с выражением благодарности за внимание;

средство отправки форм RSVP по электронной почте организатору вечеринки.

В последующих разделах мы достроим проект MVC, который был создан в предыдущей статье, и добавим в него перечисленные выше средства. Первый пункт можно убрать из списка, применив то, что было показано ранее - в существующее представление можно добавить HTML-разметку с подробной информацией о вечеринке. В примере ниже приведено содержимое файла Views/Home/Index.cshtml с внесенными дополнениями.

@{ Layout = null; } Index

Мы двигаемся в верном направлении. Если запустить приложение, отобразятся подробности о вечеринке - точнее, заполнитель для подробностей, но идея должна быть понятна.

Проектирование модели данных

В аббревиатуре MVC буква "M" обозначает model (модель), и она является наиболее важной частью приложения. Модель - это представление реальных объектов, процессов и правил, которые определяют сферу приложения, известную как предметная область.

Модель, которую часто называют моделью предметной области , содержит объекты C# (или объекты предметной области), которые образуют "вселенную" приложения, и методы, позволяющие манипулировать ими. Представления и контроллеры открывают предметную область клиентам в согласованной манере, и любое корректно разработанное приложение MVC начинается с хорошо спроектированной модели, которая затем служит центральным узлом при добавлении контроллеров и представлений.

Для приложения Party Invites сложная модель не требуется, поскольку оно совсем простое, и нужно создать только один класс предметной области, который будет назван GuestResponse. Этот объект будет отвечать за хранение, проверку достоверности и подтверждение ответа на приглашение (RSVP).

Добавление класса модели

По соглашению MVC классы, которые образуют модель, помещаются в папку Models, которую Visual Studio создает во время начальной настройки проекта. Щелкните правой кнопкой мыши на папке Models в окне Solution Explorer и выберите в контекстном меню пункт Add, а затем пункт Class (Класс). В качестве имени файла укажите GuestResponse.cs и щелкните на кнопке Add, чтобы создать класс.

Отсутствие пункта Class в контекстном меню может означать, что вы оставили отладчик Visual Studio в выполняющемся состоянии. Среда Visual Studio ограничивает виды изменений, которые можно вносить в проект при функционирующем приложении.

Отредактируйте код класса, чтобы он соответствовал примеру ниже:

Namespace PartyInvites.Models { public class GuestResponse { public string Name { get; set; } public string Email { get; set; } public string Phone { get; set; } public bool? WillAttend { get; set; } } }

Вы могли заметить, что свойство WillAttend имеет тип bool, допускающий null, т.е. оно может принимать значение true, false или null. Объяснение этого будет приведено в разделе "Добавление проверки достоверности" далее.

Связывание с методами действий

Одна из целей разрабатываемого приложения состоит в подключении формы RSVP, поэтому необходимо добавить ссылку на нее из представления Index.cshtml, как показано в примере ниже:

@{ Layout = null; } Index @ViewBag.Greeting (из представления)

Мы собираемся на захватывающую вечеринку.

Html.ActionLink() - это вспомогательный метод HTML . В MVC Framework доступен набор встроенных вспомогательных методов, которые удобны при визуализации ссылок, полей ввода текста, флажков, списков выбора и другого вида HTML-содержимого. Метод ActionLink принимает два параметра: первым является текст (анкор ссылки), который должен отображаться в ссылке, а вторым - действие, которое должно выполняться, когда пользователь щелкает на ссылке.

Просмотреть то, что создал вспомогательный метод, можно, запустив проект:

Если навести курсор мыши поверх ссылки в браузере, станет видно, что ссылка указывает на http://ваш-сервер/Home/RsvpForm. Метод Html.ActionLink() исследовал конфигурацию маршрутизации URL приложения и определил, что /Home/RsvpForm представляет собой URL действия по имени RsvpForm в контроллере HomeController.

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

Создание метода действия

Щелчок на ссылке приводит к выдаче ошибки 404 Not Found (не найдено). Она объясняется тем, что пока еще не создан метод действия, соответствующий URL вида /Home/RsvpForm. Это делается добавлением метода RsvpForm в класс HomeController, как показано в примере ниже:

Using System; using System.Collections.Generic; using System.Linq; using System.Web; using System.Web.Mvc; namespace PartyInvites.Controllers { public class HomeController: Controller { public ViewResult Index() { int hour = DateTime.Now.Hour; ViewBag.Greeting = hour < 12 ? "Доброе утро" : "Доброго дня"; return View(); } public ViewResult RsvpForm() { return View(); } } }

Добавление строго типизированного представления

Мы собираемся добавить представление для метода действия RsvpForm, но несколько другим способом - мы создадим строго типизированное представление. Строго типизированное представление предназначено для визуализации определенного типа предметной области, и если указать тип, с которым нужно работать (GuestResponse в этом случае), то MVC может создать ряд полезных сокращений, облегчающих решение задачи.

Прежде чем продолжать, удостоверьтесь, что проект MVC скомпилирован. Если код класса GuestResponse был написан, но не скомпилирован, инфраструктура MVC не сможет создать строго типизированное представление для этого типа. Чтобы скомпилировать приложение, выберите пункт Build Solution в меню Build среды Visual Studio.

Щелкните правой кнопкой мыши внутри метода RsvpForm в редакторе кода и выберите в контекстном меню пункт Add View (Добавить представление), чтобы открыть диалоговое окно Add View. Удостоверьтесь, что в поле View Name (Имя представления) указано имя RsvpForm, выберите в списке Template (Шаблон) вариант Empty (Пустой), а в списке Model Class (Класс модели) - вариант GuestResponse. Оставьте все флажки в разделе View Options (Параметры представления) неотмеченными:

Щелкните на кнопке Add, среда Visual Studio создаст новый файл по имени RvspForm.cshtml в папке Views/Home и откроет его для редактирования. В примере ниже приведено первоначальное содержимое этого файла. Это еще один скелетный HTML-файл, но в нем присутствует Razor-выражение @model . Как вы вскоре убедитесь, этот файл служит ключом к созданию строго типизированного представления и к получению предлагаемых им удобств.

RsvpForm

Опции, которые выбираются и отмечаются при создании представления, определяют начальное содержимое файла представления, и на этом все. Например, чтобы изменить обычное представление на строго типизированное, можно просто добавить или удалить директиву @model в редакторе кода.

Построение формы

Теперь, когда строго типизированное представление создано, можно дополнить содержимое файла RsvpForm.cshtml, чтобы превратить его в HTML-форму для редактирования объектов GuestResponse, как показано в примере ниже:

@model PartyInvites.Models.GuestResponse @{ Layout = null; } RsvpForm

Ваше имя: @Html.TextBoxFor(x => x.Name)

Ваш email: @Html.TextBoxFor(x => x.Email)

Ваш телефон: @Html.TextBoxFor(x => x.Phone)

Вы придете? @Html.DropDownListFor(x =>

}

Для каждого свойства класса модели GuestResponse мы используем вспомогательный метод HTML, чтобы визуализировать подходящий элемент управления HTML типа input. Эти методы позволяют с помощью лямбда-выражения выбрать свойство, с которым связан элемент input, как показано в следующей строке:

@Html.TextBoxFor(x => x.Email)

Вспомогательный метод HTML по имени TextBoxFor генерирует HTML-разметку для элемента input, устанавливает параметр type в text, а атрибуты id и name - в Email (имя выбранного свойства класса предметной области):

Это удобное средство работает, потому что представление RsvpForm является строго типизированным, а инфраструктуре MVC было указано, что GuestResponse - тип, который нужно визуализировать с помощью этого представления. Это снабжает вспомогательные методы HTML информацией, которая им необходима для выяснения того, из какого типа данных должны быть прочитаны свойства через выражение @model.

Альтернативой применению лямбда-выражений является ссылка на имя свойства типа модели как на строку:

@Html.TextBox("Email")

Подход с использованием лямбда-выражения предотвращает неправильный ввод имени свойства типа модели, т.к. среда Visual Studio активизирует средство IntelliSense, позволяя выбрать свойство автоматически:

Еще одним удобным вспомогательным методом является Html.BeginForm() , который генерирует HTML-элемент form, сконфигурированный на выполнение обратной отправки методу действия. Поскольку никакие аргументы вспомогательному методу не передаются, он предполагает, что требуется выполнить обратную отправку по тому же самому URL, из которого запрашивался HTML-документ. Изящный трюк заключается в том, чтобы поместить этот метод внутрь C#-оператора using, как показано ниже:

@using (Html.BeginForm()) { // сюда помещается содержимое формы... }

Обычно при таком применении оператор using гарантирует освобождение объекта, когда он покидает область действия. Такое использование распространено, например, для подключений к базам данных, чтобы гарантировать их закрытие немедленно по завершении запроса. (Это применение ключевого слова using отличается от той его разновидности, которая включает классы из пространства имен в область действия какого-то класса.)

Вместо освобождения объекта вспомогательный метод Html.BeginForm закрывает HTML-элемент form, когда тот покидает область действия. Это означает, что вспомогательный метод Html.BeginForm создает обе части элемента формы:

// ... содержимое формы

Не беспокойтесь, если не знакомы с удалением объектов C#. В данном случае задача заключается в том, чтобы продемонстрировать создание формы с помощью вспомогательного метода HTML.

Стремясь быть полезной, среда Visual Studio будет выполнять запрос в браузере URL-адреса, основываясь на представлении, которое редактируется в текущий момент. Это ненадежная возможность, поскольку она не работает при редактировании файлов других видов, к тому же в сложных веб-приложениях нельзя просто переходить в произвольные точки.

Чтобы установить фиксированный URL-адрес для запроса в браузере, выберите в меню Project (Проект) среды Visual Studio пункт PartyInvites Properties (Свойства PartyInvites), перейдите в раздел Web и отметьте переключатель Specific Page (Определенная страница) в категории Start Action (Начальное действие), как показано на рисунке ниже:

Вводить значение в поле рядом с переключателем вовсе не обязательно - Visual Studio будет запрашивать стандартный URL-адрес для проекта, который указывает на метод действия Index контроллера Home.

Форму в представлении RsvpForm можно увидеть, запустив приложение и щелкнув на ссылке "Форма RSVP". Результат показан на рисунке ниже:

Обработка форм

Инфраструктуре MVC пока еще не указано, что должно быть сделано, когда форма отправляется серверу. В нынешнем состоянии приложения щелчок на кнопке "Отправить форму RSVP" лишь очищает любые значения, введенные в форму. Причина в том, что форма осуществляет обратную отправку методу действия RsvpForm из контроллера Home, который только сообщает MVC о необходимости повторной визуализации представления.

Факт утери введенных данных при повторной визуализации представления может вас удивить. Если это так, то вам, скорее всего, приходилось разрабатывать приложения с помощью инфраструктуры ASP.NET Web Forms, которая в такой ситуации автоматически сохраняет данные. Вскоре будет показано, как добиться аналогичного эффекта в MVC.

Чтобы получить и обработать данные отправленной формы, мы собираемся воспользоваться одной интересной возможностью. Мы добавим второй метод действия RsvpForm, чтобы обеспечить перечисленные ниже аспекты.

Метод, который отвечает на HTTP-запросы GET. Каждый раз, когда кто-то щелкает на ссылке, браузер обычно выдает именно запрос GET. Эта версия действия будет отвечать за отображение изначально пустой формы, когда кто-нибудь впервые посещает /Home/RsvpForm.

Метод, который отвечает на HTTP-запросы POST. По умолчанию формы, визуализированные с помощью Html.BeginForm, отправляются браузером в виде запросов POST. Эта версия действия будет отвечать за получение отправленных данных и принятие решения о том, что с ними делать.

Обработка запросов GET и POST в отдельных методах C# способствует обеспечению аккуратности кода контроллера, т.к. ответственность у этих двух методов разная. Оба метода действий вызываются через один и тот же URL, но MVC вызывает соответствующий метод в зависимости от вида запроса - GET или POST. В примере ниже показаны изменения, которые необходимо внести в класс HomeController.

Using System; using System.Collections.Generic; using System.Linq; using System.Web; using System.Web.Mvc; using PartyInvites.Models; namespace PartyInvites.Controllers { public class HomeController: Controller { public ViewResult Index() { int hour = DateTime.Now.Hour; ViewBag.Greeting = hour < 12 ? "Доброе утро" : "Доброго дня"; return View(); } public ViewResult RsvpForm() { return View(); } public ViewResult RsvpForm(GuestResponse guest) { // Нужно отправить данные нового гостя no электронной почте // организатору вечеринки. return View("Thanks", guest); } } }

К существующему методу действия RsvpForm был добавлен атрибут HttpGet . Это указывает MVC, что данный метод должен использоваться только для запросов GET.

Затем была добавлена перегруженная версия метода RsvpForm, принимающая параметр GuestResponse, к которой применен атрибут HttpPost. Этот атрибут указывает MVC, что новый метод будет иметь дело только с запросами POST. Обратите внимание, что также было импортировано пространство имен PartyInvites.Models. Это сделано для того, чтобы на тип модели GuestResponse можно было ссылаться без необходимости в указании полностью определенного имени класса. Работа всех этих добавлений к коду объясняется в последующих разделах.

Использование привязки модели

Первая перегруженная версия метода действия RsvpForm визуализирует то же самое представление, что и ранее (файл RsvpForm.cshtml), для генерации формы, показанной на рисунке выше.

Вторая перегруженная версия более интересна из-за наличия параметра. Но с учетом того, что этот метод действия будет вызываться в ответ на HTTP-запрос POST, а тип GuestResponse является классом C#, каким образом они соединяются между собой?

Секрет кроется в привязке модели - чрезвычайно полезной функциональной возможности MVC, согласно которой входящие данные анализируются, а пары "ключ/значение" в HTTP-запросе используются для заполнения свойств в типах модели предметной области. Этот процесс противоположен применению вспомогательных методов HTML; т.е. при создании данных формы для отправки клиенту мы генерируем HTML-элементы input, в которых значения атрибутов id и name производятся из имен свойств класса модели.

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

Привязка модели - мощное и настраиваемое средство, которое избавляет от кропотливого и тяжелого труда по взаимодействию с HTTP-запросами напрямую и позволяет работать с объектами C#, а не иметь дело со значениями Request.Form и Request.QueryString. Объект GuestResponse, который передается в качестве параметра этому методу действия, автоматически заполняется данными из полей формы.

Визуализация других представлений

Вторая перегруженная версия метода действия RsvpForm также демонстрирует, как можно указать MVC, что в ответ на запрос должно визуализироваться специфическое представление, отличное от стандартного. Ниже приведен соответствующий оператор:

return View("Thanks", guestResponse);

Этот вызов метода View сообщает MVC, что нужно найти и визуализировать представление Thanks и передать ему объект GuestResponse. Чтобы создать указанное представление, щелкните правой кнопкой мыши на любом из методов класса HomeController и выберите в контекстном меню пункт Add View (Добавить представление). С помощью открывшегося диалогового окна Add View создайте строго типизированное представление по имени Thanks, в котором применяется класс модели GuestResponse и которое основано на шаблоне Empty. Среда Visual Studio создаст представление в виде файла Views/Home/Thanks.cshtml.

Отредактируйте код представления так, чтобы он соответствовал коду, приведенному в примере ниже:

@model PartyInvites.Models.GuestResponse @{ Layout = null; } Thanks Спасибо, @Model.Name! @if (Model.WillAttend == true) { @:Здорово что вы придете, напитки уже в холодильнике;) } else { @:Жаль что вы не придете, но спасибо что дали об этом знать. }

Представление Thanks использует механизм визуализации Razor, чтобы отображать содержимое в зависимости от значения свойства GuestResponse, переданного вызову View в методе действия RsvpForm. Выражение @model синтаксиса Razor указывает тип модели предметной области, для которого представление строго типизировано.

Для получения доступа к значению свойства в объекте предметной области применяется конструкция Model.ИмяСвойства. Например, для получения значения свойства Name используется Model.Name.

Теперь, когда создано представление Thanks, появился работающий базовый пример обработки формы с помощью MVC. Запустите приложение в Visual Studio, щелкните на ссылке "Форма RSVP", введите какие-нибудь данные внутри формы и щелкните на кнопке "Отправить форму RSVP". Отобразится результат, показанный на рисунке ниже (он может отличаться, если введено другое имя и было указано о невозможности посетить вечеринку).

Добавление проверки достоверности

Теперь пора добавить в приложение проверку достоверности вводимых данных. В отсутствие проверки достоверности пользователи смогут вводить бессмысленные данные или даже отправлять пустую форму.

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

Инфраструктура ASP.NET MVC поддерживает декларативные правила проверки достоверности, определенные с помощью атрибутов из пространства имен System.ComponentModel.DataAnnotations , а это значит, что ограничения проверки достоверности выражаются с помощью стандартных атрибутов C#. В примере ниже показано, как применить эти атрибуты к классу модели GuestResponse:

Using System.ComponentModel.DataAnnotations; namespace PartyInvites.Models { public class GuestResponse { public string Name { get; set; } public string Email { get; set; } public string Phone { get; set; } public bool? WillAttend { get; set; } } }

Инфраструктура MVC обнаруживает атрибуты проверки достоверности и использует их для проверки данных во время процесса приписки модели. Обратите внимание, что мы импортировали пространство имен, которое содержит средства проверки достоверности, так что к ним можно обращаться, не указывая полные имена.

Как уже отмечалось ранее, для свойства WillAttend был выбран булевский тип, допускающий значение null. Это было сделано для того, чтобы можно было применить атрибут проверки Required. В случае использования обычного булевского типа значением, получаемым посредством привязки модели, могло бы быть только true или false, и не было бы возможности определить, выбрал ли пользователь значение. Булевский тип, допускающий null, имеет три разрешенных значения: true, false и null. Значение null будет применяться, если пользователь не выбрал значение, и это вынудит атрибут Required сообщить об ошибке проверки достоверности. Это хороший пример того, насколько элегантно инфраструктура MVC Framework сочетает средства C# с HTML и HTTP.

Проверку на наличие проблемы с достоверностью данных можно выполнить с использованием свойства ModelState.IsValid в классе контроллера. В примере ниже показано, как это реализовано в методе действия RsvpForm, поддерживающем запросы POST, внутри класса контроллера Home:

// ... public ViewResult RsvpForm(GuestResponse guest) { if (ModelState.IsValid) // Нужно отправить данные нового гостя по электронной почте // организатору вечеринки. return View("Thanks", guest); else // Обнаружена ошибка проверки достоверности return View(); }

Если ошибки проверки достоверности отсутствуют, мы указываем MVC, что нужно визуализировать представление Thanks, как это делалось ранее. В случае обнаружения ошибок проверки достоверности мы повторно визуализируем представление RsvpForm вызывая метод View() без параметров.

Простое отображение формы в ситуации, когда имеется ошибка, не особенно полезно - мы должны также предоставить пользователю информацию, в чем заключается проблема, и почему принять отправку формы невозможно. Это делается с применением вспомогательного метода Html.ValidationSummary() в представлении RsvpForm, как показано в примере ниже:

@model PartyInvites.Models.GuestResponse @{ Layout = null; } RsvpForm @using (Html.BeginForm()) { @Html.ValidationSummary()

Ваше имя: @Html.TextBoxFor(x => x.Name)

Ваш email: @Html.TextBoxFor(x => x.Email)

Ваш телефон: @Html.TextBoxFor(x => x.Phone)

Вы придете? @Html.DropDownListFor(x => x.WillAttend, new { new SelectListItem() { Text = "Да, конечно я буду", Value = Boolean.TrueString}, new SelectListItem() { Text = "Нет, я не смогу", Value = Boolean.FalseString} })

}

В отсутствие ошибок метод Html.ValidationSummary() создает скрытый элемент списка в виде заполнителя внутри формы. Инфраструктура MVC делает заполнитель видимым и добавляет сообщения об ошибках, определенные атрибутами проверки достоверности. Результирующее окно показано на рисунке:

Пользователь не увидит представление Thanks до тех пор, пока не будут удовлетворены все ограничения проверки достоверности, примененные к классу GuestResponse. Обратите внимание, что введенные в форму данные были сохранены и отображены снова при визуализации представления со сводкой проверки достоверности. Это еще одно преимущество, обеспечиваемое средством привязки модели, и оно упрощает работу с данными формы.

Если вам приходилось иметь дело с ASP.NET Web Forms, то вы знаете, что в Web Forms имеется концепция серверных элементов управления , которые сохраняют состояние, сериализуя значения в скрытое поле формы по имени _VIEWSTATE. Привязка модели ASP.NET MVC не имеет никакого отношения к концепциям серверных элементов управления, обратным отправкам или средству View State, характерным для Web Forms. Инфраструктура ASP.NET MVC не внедряет скрытое поле _VIEWSTATE в визуализированные HTML-страницы.

Подсветка полей с недопустимыми значениями

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

Если свойство класса модели не пройдет проверку достоверности, вспомогательные методы HTML будут генерировать несколько иную HTML-разметку. В качестве примера ниже приведена HTML-разметка, генерируемая в результате вызова Html.TextBoxFor(х => x.Name) при отсутствии ошибок проверки достоверности:

А вот HTML-разметка, генерируемая этим же вызовом, когда пользователь не вводит значение (что является ошибкой проверки достоверности, поскольку мы применили атрибут Required к свойству Name в классе модели GuestResponse):

Этот вспомогательный метод добавил к элементу input класс по имени input-validation-error. Мы можем воспользоваться этой возможностью, создав таблицу стилей, которая содержит стили CSS для этого класса и другие стили, применяемые различными вспомогательными методами HTML.

Соглашение, принятое в проектах MVC, предусматривает помещение статического содержимого, такого как таблицы стилей CSS, в папку по имени Content. Создайте эту папку, щелкнув правой кнопкой мыши на элементе PartyInvites в окне Solution Explorer, выбрав в контекстном меню пункт Add --> New Folder (Добавить --> Новая папка) и указав Content в качестве имени папки.

Чтобы создать файл CSS, щелкните правой кнопкой мыши на только что созданной папке Content, выберите в контекстном меню пункт Add --> New Item (Добавить --> Новый элемент) и выберите Style Sheet (Таблица стилей) из набора шаблонов элементов. Установите имя нового файла Styles.css, как показано на рисунке ниже:

Щелкните на кнопке Add и Visual Studio создаст файл Content/Styles.css. Приведите содержимое этого файла в соответствие со следующим кодом:

Field-validation-error { color: #f00; } .field-validation-valid { display: none; } .input-validation-error { border: 1px solid #f00; background-color: #fee; } .validation-summary-errors { font-weight: bold; color: #f00; } .validation-summary-valid { display: none; }

Для использования этой таблицы стилей добавляется новая ссылка в раздел head представления RsvpForm, как показано в примере ниже. Элементы link добавляются к представлениям точно так же, как к обычным статическим файлам HTML, хотя позже будет продемонстрировано средство пакетов, которое позволяет объединять сценарии JavaScript и таблицы стилей CSS и доставлять их в браузеры с помощью единственного HTTP-запроса.

@model PartyInvites.Models.GuestResponse @{ Layout = null; } RsvpForm

Файлы JavaScript и CSS можно перетаскивать из окна Solution Explorer в редактор кода. Среда Visual Studio создаст элементы script и link для выбранных файлов.

Если вы перешли на MVC 5 непосредственно с MVC 3, то могли ожидать, что файл CSS добавляется к представлению за счет указания атрибута href в виде @Href("~/Content/Site.css") или @Url.Content("~/Content/Site.css"). Начиная с MVC 4, механизм Razor обнаруживает атрибуты, начинающиеся с ~/ и автоматически вставляет вызов @Href или @Url.

После применения таблицы стилей при отправке данных, которые вызывают ошибку проверки достоверности, отображается визуально очевидное указание на причины проблем:

Стилизация содержимого

Базовая функциональность приложения на месте (кроме отправки электронной почты, к которой мы вскоре приступим), однако его внешний вид в целом довольно-таки непривлекателен. Несмотря на то что это руководство по MVC сосредоточено на разработке серверной стороны, полезно рассмотреть несколько библиотек с открытым кодом, которые приняты Microsoft и включены в ряд шаблонов проектов Visual Studio.

Я не являюсь большим поклонником упомянутых шаблонов, но мне нравятся некоторые из используемых ими библиотек, и одним таким примером из числа задействованных в MVC 5 является Bootstrap , которая представляет собой удобную библиотеку CSS, первоначально разработанную в Twitter и получившую широкое применение.

Разумеется, вы не обязаны применять шаблоны проектов Visual Studio, чтобы пользоваться библиотеками вроде Bootstrap. Можно загрузить файлы напрямую из веб-сайтов с нужными библиотеками или воспользоваться инструментом NuGet , интегрированным в Visual Studio и предоставляющим доступ к каталогу заранее упакованного программного обеспечения, которое может быть загружено и установлено автоматически.

Одной из лучших характеристик NuGet является то, что данный инструмент управляет зависимостями между пакетами, так что во время установки, к примеру, библиотеки Bootstrap инструмент NuGet также загрузит и установит библиотеку jQuery, от которой зависит Bootstrap.

Использование NuGet для установки Bootstrap

Чтобы установить пакет Bootstrap, выберите пункт Library Package Manager --> Package Manager Console в меню Tools среды Visual Studio. Откроется окно командной строки NuGet. Введите следующую команду и нажмите клавишу :

Install-Package -version 3.0.0 bootstrap

Команда Install-Package сообщает NuGet о необходимости загрузки пакета вместе с его зависимостями и затем добавления всего этого в проект. Нужный пакет называется bootstrap. Имена пакетов можно либо искать на веб-сайте NuGet (http://www.nuget.org), либо прибегнуть к услугам пользовательского интерфейса NuGet в Visual Studio (выберите пункт меню Tools --> Library Package Manager --> Manage NuGet Packages for Solution.

Ключ командной строки -version использовался для указания на то, что требуется версия 3 библиотеки Bootstrap, которая является последней доступной стабильной версией. Без ключа -version инструмент NuGet загрузил бы последнюю версию пакета, но для гарантии того, что вы в точности воссоздадите примеры, приведенные ниже, необходимо установить эту конкретную версию.

Инструмент NuGet загрузит все файлы, требующиеся для библиотеки Bootstrap, а также для библиотеки jQuery, на которую опирается Bootstrap. Файлы CSS помещаются в папку Content. Кроме того, создается папка Scripts (которая в MVC является стандартным местоположением для файлов JavaScript) и заполняется файлами Bootstrap и jQuery. (Также создается папка fonts - это индивидуальная особенность библиотеки Bootstrap, которая ожидает наличия файлов в определенных местах.)

Причина рассмотрения Bootstrap в этой статье - иллюстрация того, насколько легко HTML-разметка, генерируемая MVC Framework, может применяться с популярными библиотеками CSS и JavaScript. Тем не менее, основное внимание в настоящем руководстве уделяется разработке серверной стороны.

Стилизация представления index

Базовые средства Bootstrap работают путем применения классов к элементам, которые соответствуют селекторам CSS, определенным внутри добавленных в папку Content файлов. Подробную информацию о классах, определенных в библиотеке Bootstrap, можно получить на веб-сайте Bootstrap , а в примере ниже демонстрируется использование ряда базовых стилей в представлении Index.cshtml:

@{ Layout = null; } Index .btn a { color: white; text-decoration: none; } body { background-color: #F1F1F1; } Мы собираемся на захватывающую вечеринку. И вы приглашены, нужно только заполнить форму
@Html.ActionLink("Форма RSVP", "RsvpForm")

В разметку были добавлены элементы link для файлов bootstrap.css и bootstrap-theme.css из папки Content. Они являются файлами Bootstrap, требуемыми для базовой стилизации CSS, обеспечиваемой этой библиотекой. Вдобавок в папке Scripts имеется соответствующий файл JavaScript, но в данной статье он не нужен. Кроме того, определен также элемент style, который устанавливает цвет фона для элемента body и стили текста для элементов .

Вы заметите, что для каждого файла Bootstrap в папке Content имеется двойник с суффиксом min - например, есть файлы bootstrap.css и bootstrap.min.css. Это распространенная практика минимизации файлов JavaScript и CSS при развертывании приложений в производственной среде, которая представляет собой процесс удаления всех пробельных символов, а также в случае файлов JavaScript замену имен функций и переменных более короткими метками. Целью минимизации является сокращение объема передаваемых данных, необходимых для доставки содержимого в браузер.

После импортирования стилей Bootstrap и определения пары собственных стилей осталось стилизовать элементы. Рассматриваемый пример прост, поэтому необходимо использовать только три класса CSS из Bootstrap: text-center, btn и btn-success.

Класс text-center центрирует содержимое элемента и его дочерних элементов. Класс btn стилизует элемент button, input или в виде симпатичной кнопки, а класс btn-success указывает диапазон цветов для этой кнопки. Цвет кнопки зависит от применяемой темы - в примере используется стандартная тема (как определено в файле bootstrap-theme.css), но в Интернете доступно буквально бесконечное количество других тем.

Полученные в итоге результаты показаны на рисунке ниже:

Стилизация представления RsvpForm

В библиотеке Bootstrap определены классы, которые могут использоваться для стилизации форм. Я не планирую вдаваться в особые детали, но в примере ниже показано, как были применены эти классы:

@model PartyInvites.Models.GuestResponse @{ Layout = null; } RsvpForm Форма RSVP @using (Html.BeginForm()) { @Html.ValidationSummary() Ваше имя: @Html.TextBoxFor(x => x.Name, new { @class = "form-control" }) Ваш email: @Html.TextBoxFor(x => x.Email, new { @class = "form-control" }) Ваш телефон: @Html.TextBoxFor(x => x.Phone, new { @class = "form-control" }) Вы придете? @Html.DropDownListFor(x => x.WillAttend, new { new SelectListItem() { Text = "Да, конечно я буду", Value = Boolean.TrueString}, new SelectListItem() { Text = "Нет, я не смогу", Value = Boolean.FalseString} }, "Выберите вариант", new { @class = "form-control" }) }

Классы Bootstrap в этом примере создают панель с заголовком, просто чтобы придать компоновке структурированность. Для стилизации формы используется класс form-group , который стилизует элемент, содержащий label и связанный элемент input или select.

Эти элементы созданы посредством вспомогательных методов HTML, что означает отсутствие статически определенных элементов, к которым можно было бы применить требуемый класс form-control. К счастью, вспомогательные методы принимают в качестве необязательного аргумента объект, который позволяет указывать атрибуты создаваемого элемента, например:

@Html.TextBoxFor(x => x.Email, new { @class = "form-control" })

Объект для атрибутов создается с использованием анонимных типов C# и указывает, что в элементе, генерируемом вспомогательным методом TextBoxFor, атрибут class должен быть установлен в form-control. Свойства, определяемые этим объектом, применяются для имени атрибута, добавляемого к HTML-элементу, а поскольку class является зарезервированным словом в языке C#, оно предваряется символом @. Это стандартная возможность C#, которая позволяет использовать ключевые слова в выражениях.

Результаты стилизации можно видеть на рисунке ниже:

Стилизация представления Thanks

Последним представлением, подлежащим стилизации, является Thanks.cshtml, в примере ниже показано, как это делается. Вы заметите, что добавленная разметка похожа на таковую из представления Index.cshtml. Чтобы упростить управление приложением, имеет смысл избегать дублирования кода и разметки везде, где это возможно. Позже будут рассмотрены компоновки Razor и описаны частичные представления, которые способствуют сокращению дублирования разметки.

@model PartyInvites.Models.GuestResponse @{ Layout = null; } Thanks Спасибо, @Model.Name!

Класс lead применяет один из типографских стилей Bootstrap. Результаты можно видеть на рисунке ниже:

Завершение примера

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

Однако вместо этого мы намерены воспользоваться вспомогательным классом WebMail. Он не является частью инфраструктуры MVC, но позволяет завершить пример, не вникая в нюансы настройки средств для отправки электронной почты. Нам требуется, чтобы электронное письмо отправлялось при визуализации представления Thanks. Необходимые изменения показаны в примере ниже:

@model PartyInvites.Models.GuestResponse @{ Layout = null; } Thanks body { background: #f1f1f1; } @{ try { WebMail.SmtpServer = "smtp.example.com"; WebMail.SmtpPort = 587; WebMail.EnableSsl = true; WebMail.UserName = "mySmtpUsername"; WebMail.Password = "mySmtpPassword"; WebMail.From = "[email protected]"; WebMail.Send("[email protected]", "RSVP Приглашение", Model.Name + ((Model.WillAttend ?? false) ? " " : "не") + "придет"); } catch (Exception) { @:К сожалению при отправке письма возникла ошибка. } } Спасибо, @Model.Name! @if (Model.WillAttend == true) { @:Здорово что вы придете, напитки уже в холодильнике;) } else { @:Жаль что вы не придете, но спасибо что дали об этом знать. }

Вспомогательный класс WebMail использовался потому, что он позволяет продемонстрировать отправку электронного письма с минимальными усилиями. Тем не менее, обычно подобную функциональность предпочтительнее помещать в метод действия.

Мы добавили выражение Razor, которое применяет вспомогательный класс WebMail для настройки параметров нашего почтового сервера, в том числе имени сервера, обязательности использования безопасных подключений (SSL) и сведений об учетной записи. Как только все эти детали сконфигурированы, с помощью метода WebMail.Send() отправляется сообщение по электронной почте.

Весь код отправки сообщения помещен внутрь блока try...catch, что позволяет предупредить пользователя, если сообщение не отправлено. Это осуществляется путем добавления текстового блока в вывод представления Thanks. Более рациональным подходом было бы отображение отдельного представления ошибки в случае невозможности отправки электронного сообщения, но мы хотели максимально упростить это первое приложение MVC.