Вредоносное ПО (malware) - это назойливые или опасные программы,...
Создание HTML-элементов
Итак, в предыдущей статье мы рассмотрели создание и настройку HTML-дескрипторов веб-форм. HTML-форма не имеет особого смысла до тех пор, пока не будут созданы некоторые элементы управления вводом (например, ). В таблице ниже описаны базовые вспомогательные методы, которые доступны для создания элементов , и приведены примеры генерируемой ими HTML-разметки. Во всех этих вспомогательных методах первый аргумент используется для установки значений атрибутов id и name элемента , а второй аргумент служит для установки значения атрибута value.
| Метод | Пример | Генерируемый HTML-элемент |
|---|---|---|
| Html.CheckBox() | Html.CheckBox("myCheckbox", false) | |
| Html.Hidden() | Html.Hidden("myHidden", "val") | |
| Html.RadioButton() | Html.RadioButton("myRadiobutton", "val", true) | |
| Html.Password() | Html.Password("myPassword", "val") | |
| Html.TextArea() | Html.TextArea("myTextarea", "val", 5, 20, null) | |
| Html.TextBox() | Html.TextBox("myTextbox", "val") |
Каждый из перечисленных вспомогательных методов имеет перегруженную версию. В этой таблице показаны простейшие версии, но можно также предоставить дополнительный аргумент object для указания HTML-атрибутов, как это делалось с элементом
....Генерация элемента управления вводом из свойства модели
Вспомогательные методы, используемые в предыдущем разделе, работают хорошо, но нам по-прежнему необходимо гарантировать, что значение, передаваемое в первом аргументе, соответствует значению модели, которое передается во втором аргументе. Если эти значения не согласованы, инфраструктура ASP.NET MVC Framework не сможет воссоздать объект модели из данных формы, поскольку атрибуты name и значения элементов формы не соответствуют друг другу.
Для каждого метода, перечисленного в таблице выше, доступна перегруженная версия, которая принимает единственный аргумент типа string:
@model HelperMethods.Models.User @{ ViewBag.Title = "CreateUser"; }
Создать пользователя
@using (Html.BeginRouteForm("FormRoute", null, FormMethod.Post, new { @class = "userCssClass", data_formType="user" })) {
@Html.TextBox("userId")
@Html.TextBox("firstName")
@Html.TextBox("lastName")
}
Аргумент string применяется для поиска в данных представления, в объекте ViewBag и в модели представления соответствующего элемента данных, который может использоваться в качестве основы для элемента input. Таким образом, например, если вызвать @Html.TextBox("DataValue"), то инфраструктура ASP.NET MVC Framework попытается найти элемент данных, который соответствует ключу DataValue. Будут проверяться следующие местоположения:
ViewBag.DataValue
@Model.DataValue
Первое найденное значение используется для установки атрибута value генерируемой HTML-разметки. (Последняя проверка, в @Model.DataValue, предпринимается, только если модель представления содержит свойство или поле по имени DataValue.)
Если указать строку вроде DataValue.First.Name, поиск становится более сложным. Инфраструктура ASP.NET MVC Framework опробует различные комбинации элементов, разделяемых точками, такие как перечисленные ниже:
ViewBag.DataValue.First.Name
ViewBag.DataValue["First"].Name
ViewBag.DataValue["First.Name"]
ViewBag.DataValue["First"]["Name"]
Проверяются многие перестановки. И снова будет использоваться первое найденное значение, завершая поиск. С этим приемом связана очевидная проблема производительности, однако помните, что внутри объекта ViewBag обычно содержится совсем немного элементов, так что поиск среди них не должен отнимать значительное время.
Использование строго типизированных вспомогательных методов для создания элементов управления вводом
Каждому базовому вспомогательному методу для создания элементов управления вводом, описанному в таблице выше, соответствует строго типизированный вспомогательный метод. Эти вспомогательные методы перечислены в таблице ниже вместе с примерами HTML-разметки, которую они генерируют. Такие вспомогательные методы могут применяться только со строго типизированными представлениями. (Часть вспомогательных методов генерируют атрибуты, которые помогают обеспечивать проверку достоверности данных форм на стороне клиента, но для краткости в таблице они не приведены.)
| Метод | Пример | Генерируемый HTML-элемент |
|---|---|---|
| Html.CheckBoxFor() | Html.CheckBoxFor(х => х.IsApproved) | |
| Html.HiddenFor() | Html.HiddenFor(x => x.FirstName) | |
| Html.RadioButtonFor() | Html.RadioButtonFor(x => x.IsApproved, "val") | |
| Html.PasswordFor() | Html.PasswordFor(x => x.Password) | |
| Html.TextAreaFor() | Html.TextAreaFor(x => x.Bio, 5, 20, new{}) | |
| Html.TextBoxFor() | Html.TextBoxFor(x => x.FirstName) |
Строго типизированные вспомогательные методы для создания элементов управления вводом работают с лямбда-выражениями. В такое выражение передается объект модели представления, в котором можно выбрать поле или свойство, используемое для установки атрибута value. В примере ниже показано, как этот вид вспомогательного метода применяется в представлении CreateUser.cshtml из примера приложения:
@model HelperMethods.Models.User @{ ViewBag.Title = "CreateUser"; }
Создать пользователя
@using (Html.BeginRouteForm("FormRoute", null, FormMethod.Post, new { @class = "userCssClass", data_formType="user" })) {
@Html.TextBoxFor(user => user.UserId)
@Html.TextBoxFor(user => user.FirstName)
@Html.TextBoxFor(user => user.LastName)
}
Генерируемая этими вспомогательными методами HTML-разметка ничем не отличается от приведенной ранее. Тем не менее, использовать в проектах именно строго типизированные вспомогательные методы предпочтительнее, т.к. это уменьшает вероятность внесения ошибок за счет некорректного написания имен свойств.
Создание элементов выбора
В таблице ниже описаны вспомогательные методы HTML, предназначенные для создания элементов выбора (select). Они могут применяться для выбора одиночного элемента из раскрывающегося списка или для обеспечения одновременного выбора множества элементов. Как и в случае других элементов формы, доступны слабо и строго типизированные версии этих вспомогательных методов:
| Метод | Описание | Пример | Генерируемый HTML-элемент |
|---|---|---|---|
| Html.DropDownList() | Раскрывающийся список | Html.DropDownList("myList",
new SelectList(new {"A", "B"}), "Выбрать") |
|
| Html.DropDownListFor() | Раскрывающийся список | Html.DropDownListFor(x => x.Gender, new SelectList(new {"M", "F"})) |
|
| Html.ListBox() | Html.ListBox("myList", |
||
| Html.ListBoxFor() | Список с множественным выбором | Html.ListBoxFor(x => x.Vals, new MultiSelectList(new {"A", "B"})) |
Вспомогательные методы, генерирующие элементы выбора, принимают параметры типа SelectList или MultiSelectList . Разница между этими классами заключается в том, что MultiSelectList имеет опции конструктора, которые позволяют указывать возможность выбора более одного элемента при начальной визуализации страницы.
Model-View-Controller (MVC , «Модель-Представление-Контроллер», «Модель-Вид-Контроллер») - схема разделения данных приложения, пользовательского интерфейса и управляющей логики на три отдельных компонента: модель, представление и контроллер - таким образом, что модификация каждого компонента может осуществляться независимо .
Энциклопедичный YouTube
-
1 / 5
Концепция MVC была описана Трюгве Реенскаугом в 1978 году , работавшем в научно-исследовательском центре «Xerox PARC » над языком программирования «Smalltalk ». Позже, Стив Бурбек реализовал шаблон в Smalltalk-80 .
Впоследствии, шаблон проектирования стал эволюционировать. Например, была представлена иерархическая версия HMVC ; MVA, MVVM .
После внедрения компанией Apple технологии WebObjects, реализованных на Objective-C, стало популяризировать шаблон и в вебе [ ] .
Когда WebObjects портировали на Java, шаблон стал популярен и там. Более поздние фреймворки вроде Spring (октябрь 2002 года) всё ещё имеют реализацию MVC [ ] .
Дальнейший виток популярности привнесло развитие фреймворков, ориентированных на быструю развёртку, на языках Python и Ruby, Django и Rails, соответственно [ ] . На момент 2017 года, фреймворки с MVC заняли заметные позиции по отношению к остальным фреймворкам без этого шаблона .
Различия описания концепции шаблона
С развитием объектно-ориентированного программирования и понятия о шаблонах проектирования - был создан ряд модификаций концепции MVC, которые при реализации у разных авторов могут отличаться от оригинальной. Так, например, Эриан Верми в 2004 году описал пример обобщённого MVC .
В предисловии к диссертации «Naked objects » Ричарда Поусона (Richard Pawson), - Трюгве Реенскауг упоминает свою неопубликованную наиболее раннюю версию MVC, согласно которой :
- Модель относилась к «разуму» пользователя;
- Под представлением имелся в виду редактор, позволяющий пользователю просматривать и обновлять информацию;
- Контроллер являлся инструментом для связывания представлений воедино и применялся пользователем для решения его задач.
Назначение
Основная цель применения этой концепции состоит в отделении бизнес-логики (модели ) от её визуализации (представления , вида ). За счёт такого разделения повышается возможность повторного использования кода . Наиболее полезно применение данной концепции в тех случаях, когда пользователь должен видеть те же самые данные одновременно в различных контекстах и/или с различных точек зрения. В частности, выполняются следующие задачи:
- К одной модели можно присоединить несколько видов , при этом не затрагивая реализацию модели . Например, некоторые данные могут быть одновременно представлены в виде электронной таблицы , гистограммы и круговой диаграммы ;
- Не затрагивая реализацию видов , можно изменить реакции на действия пользователя (нажатие мышью на кнопке, ввод данных) - для этого достаточно использовать другой контроллер ;
- Ряд разработчиков специализируется только в одной из областей: либо разрабатывают графический интерфейс , либо разрабатывают бизнес-логику . Поэтому возможно добиться того, что программисты, занимающиеся разработкой бизнес-логики (модели ), вообще не будут осведомлены о том, какое представление будет использоваться.
Концепция
Концепция MVC позволяет разделить модель, представление и контроллер на три отдельных компонента:
Модель
Модель предоставляет данные и методы работы с ними: запросы в базу данных, проверка на корректность. Модель не зависит от представления - не знает как данные визуализировать - и контроллера - не имеет точек взаимодействия с пользователем -, просто предоставляя доступ к данным и управлению ими.
Модель строится таким образом, чтобы отвечать на запросы, изменяя своё состояние, при этом может быть встроено уведомление «наблюдателей».
Модель, за счёт независимости от визуального представления, может иметь несколько различных представлений для одной «модели».
Представление
Представление отвечает за получение необходимых данных из модели и отправляет их пользователю. Представление не обрабатывает введённые данные пользователя [ ] .
Представление может влиять на состояние модели сообщая модели об этом.
Контроллер
Контроллер обеспечивает «связи» между пользователем и системой. Контролирует и направляет данные от пользователя к системе и наоборот. Использует модель и представление для реализации необходимого действия.
Функциональные возможности и расхождения
Поскольку MVC не имеет строгой реализации, то реализован он может быть по-разному. Нет общепринятого определения, где должна располагаться бизнес-логика. Она может находиться как в контроллере, так и в модели. В последнем случае, модель будет содержать все бизнес-объекты со всеми данными и функциями.
Некоторые фреймворки жестко задают где должна располагаться бизнес-логика, другие не имеют таких правил.
Также не указано, где должна находиться проверка введённых пользователем данных. Простая валидация может встречаться даже в представлении, но чаще они встречаются в контроллере или модели.
Интернационализация и форматирование данных также не имеет четких указаний по расположению.
Условно-обязательные модификации
Для реализации схемы «Model-View-Controller» используется достаточно большое число шаблонов проектирования (в зависимости от сложности архитектурного решения), основные из которых - «наблюдатель », «стратегия », «компоновщик » :
Наиболее типичная реализация - в которой вид отделён от модели путём установления между ними протокола взаимодействия, использующего «аппарат событий» (обозначение «событиями» определённых ситуаций, возникающих в ходе выполнения программы, - и рассылка уведомлений о них всем тем, кто подписался на получение): при каждом особом изменении внутренних данных в модели (обозначенном как «событие»), она оповещает о нём те зависящие от неё представления, которые подписаны на получение такого оповещения - и представление обновляется. Так используется шаблон «наблюдатель »;
При обработке реакции пользователя - представление выбирает, в зависимости от реакции, нужный контроллер , который обеспечит ту или иную связь с моделью. Для этого используется шаблон «стратегия », или вместо этого может быть модификация с использованием шаблона «команда »;
Для возможности однотипного обращения с подобъектами сложно-составного иерархического вида - может использоваться шаблон «компоновщик ». Кроме того, могут использоваться и другие шаблоны проектирования - например, «фабричный метод », который позволит задать по умолчанию тип контроллера для соответствующего вида.
Наиболее частые ошибки
Начинающие программисты очень часто трактуют архитектурную модель MVC как пассивную модель MVC: модель выступает исключительно совокупностью функций для доступа к данным, а контроллер содержит бизнес-логику . В результате - код моделей по факту является средством получения данных из СУБД , а контроллер - типичным модулем , наполненным бизнес-логикой (см. «скрипт » в терминологии веб-программирования). В результате такого понимания - MVC-разработчики стали писать код, который Pádraic Brady (известный в кругах сообщества «Zend Framework ») охарактеризовал как «ТТУК» («Толстые, тупые, уродливые контроллеры»; Fat Stupid Ugly Controllers):
Среднестатистический ТТУК получал данные из БД (используя уровень абстракции базы данных, делая вид, что это модель) или манипулировал, проверял, записывал, а также передавал данные в Представление. Такой подход стал очень популярен потому, что использование таких контроллеров похоже на классическую практику использования отдельного php-файла для каждой страницы приложения.
Но в объектно-ориентированном программировании используется активная модель MVC, где модель - это не только совокупность кода доступа к данным и
Последнее обновление: 31.10.2015
Контроллер является центральным компонентом в архитектуре MVC. Контроллер получает ввод пользователя, обрабатывает его и посылает обратно результат обработки, например, в виде представления.
При использовании контроллеров существуют некоторые условности. Так, по соглашениям об именовании названия контроллеров должны оканчиваться на суффикс "Controller", остальная же часть до этого суффикса считается именем контроллера.
Чтобы обратиться контроллеру из веб-браузера, нам надо в адресной строке набрать адрес_сайта/Имя_контроллера/ . Так, по запросу адрес_сайта/Home/ система маршрутизации по умолчанию вызовет метод Index контроллера HomeController для обработки входящего запроса. Если мы хотим отправить запрос к конкретному методу контроллера, то нужно указывать этот метод явно: адрес_сайта/Имя_контроллера/Метод_контроллера , например, адрес_сайта/Home/Buy - обращение к методу Buy контроллера HomeController.
Контроллер представляет обычный класс, который наследуется от базового класса System.Web.Mvc.Controller . В свою очередь класс Controller реализует абстрактный базовый класс ControllerBase, а через него и интерфейс IController . Таким образом, формально, чтобы создать свой класс контроллера, достаточно создать класс, реализующий интерфейс IController и имеющий в имени суффикс Controller .
Интерфейс IController определяет один единственный метод Execute, который отвечает за обработку контекста запроса:
Public interface IController { void Execute(RequestContext requestContext); }
Теперь создадим какой-нибудь простенький контроллер, реализующий данный интерфейс. В качестве проекта мы можем взять проект из предыдущий главы. Итак, добавим в папку Controllers проекта новый класс (именно класс, а не контроллер) со следующим содержанием:
Using System.Web.Mvc; using System.Web.Routing; namespace BookStore.Controllers { public class MyController: IController { public void Execute(RequestContext requestContext) { string ip = requestContext.HttpContext.Request.UserHostAddress; var response = requestContext.HttpContext.Response; response.Write("
Ваш IP-адрес: " + ip + "
"); } } }При обращении к любому контроллеру система передает в него контекст запроса. В этот контекст запроса включается все: куки, отправленные данные форм, строки запроса, идентификационные данные пользователя и т.д. Реализация интерфейса IController позволяет получить этот контекст запроса в методе Execute через параметр RequestContext . В нашем случае мы получаем IP-адрес пользователя через свойство requestContext.HttpContext.Request.UserHostAddress .
Кроме того, мы можем отправить пользователю ответ с помощью объекта Response и его метода Write.
Таким образом, перейдя по пути адрес_сайта/My/ , пользователь увидит свой ip-адрес.
Хотя с помощью реализации интерфейса IController очень просто создавать контроллеры, но в реальности чаще оперируют более высокоуровневыми классами, как например класс Controller, поскольку он предоставляет более мощные средства для обработки запросов. И если при реализации интерфейса IController мы имеем дело с одним методом Execute, и все запросы к этому контроллеру, будут обрабатываться только одним методом, то при наследовании класса Controller мы можем создавать множество методов действий, которые будут отвечать за обработку входящих запросов, и возвращать различные результаты действий.
Чтобы создать стандартный контроллер, мы можем также добавить в папку Controllers простой класс и унаследовать от класса Controller, например:
Using System.Web.Mvc; namespace BookStore.Controllers { public class BookShopController: Controller { public ActionResult Index() { return View(); } } }
Однако Visual Studio предлагает нам более удобные средства для создания контроллеров, предполагающие их гибкую настройку. Чтобы ими воспользоваться, нажмем на папку Controllers правой кнопкой мыши и в появившемся меню выберем Add -> Controller... . После этого нам отобразится окно создания нового контроллера:
Собственно к контроллерам MVC 5 здесь непосредственное отношение имеют первые три пункта. Остальные больше относятся к Web API 2. В этом списке выберем первый пункт - MVC 5 Controller - Empty , который подразумевает создание пустого контроллера. Остальные два пункта позволяют сгенерировать классы с CRUD-функциональностью на основе шаблонов формирования, о которых мы поговорим в разделе о моделях.
Далее нам будет предложено ввести имя, и после этого новый контроллер с единственным методом Index будет добавлен в проект. При таком добавлении в отличие от предыдущих примеров для данного контроллера будет автоматически создан каталог в папке Views, который будет хранить все представления, связанные с действиями этого контроллера.
По всему интернет-миру разбросаны миллионы веб-приложений. Есть совсем простые, есть такие, что сам «архитектор матрицы ногу сломит». Но их объединяет одно — MVC .
Самый популярный архитектурный паттерн в мире среди веб-приложений — модель-представление-контроллер (Model View Controller или просто MVC). Впервые, он был использован ещё в конце 70-х двадцатого века, в приложениях на языке Smalltalk . А затем, его приютили программисты Java и расшарили для всего мира и всех языков программирования. PHP не стал исключением. Сегодня, только малая часть программистов, коллекционирующих раритетный PHP-код может себе позволить не смотреть в сторону MVC.
Таким популярным он стал неспроста. Он просто рождён для создания гибких и масштабируемых приложений, которые легко сопровождать и достраивать.
Цель нашего тьюториала — показать на простом примере, как работает паттерн MVC.Чтобы выполнить задания, вам потребуются следующие программы:
Примечания:
- Мы предполагаем, что у вас есть базовые знания PHP.
Паттерн MVC
Теперь обо всём по порядку. Сначала раскроем великую тайну аббревиатуры, в которой, очевидно, отражается тот факт, что приложение будет представлять собой три взаимодействующие части:
- Модель отвечает за управление данными, она сохраняет и извлекает сущности, используемые приложением, как правило, из базы данных и содержит логику, реализованную в приложении.
- Представление несет ответственность за отображение данных, которые даёт контроллер. С представлением тесно связано понятие шаблона, который позволяет менять внешний вид показываемой информации. В веб-приложении представление часто реализуется в виде HTML-страницы.
- Контроллер связывает модель и представление. Он получает запрос от клиента, анализирует его параметры и обращается к модели для выполнения операций над данными запроса. От модели поступают уже скомпонованные объекты. Затем они перенаправляются в представление, которое передаёт сформированную страницу контроллеру, а он, в свою очередь, отправляет её клиенту.
Схематично потоки данных в этой модели можно представить так:
Вход в реальность
Давайте наконец сформулируем реальную задачу. Пусть нам заказали построить сайт социальной сети. В этой гигантской задаче есть маленькая подзадача: используя имеющуюся базу друзей, обеспечить просмотр их полного списка, а также детальную информацию по каждому другу.
Мы не будем сейчас рассматривать архитектуру всей социальной сети. Мы возьмём только маленькую подзадачку, представим всю её серьёзность и применим к ней паттерн MVC.
Как только мы начинаем его использовать, то сразу задумываемся — а как бы нам расположить скрипты нашего решения так, что бы всё было под рукой? Для этого, разместим каждый из трёх разделов нашей MVC-системы по отдельным папкам и, таким образом, получим простую структуру каталогов, в которой легко найти то, что нам нужно. Кроме того, эти три папки поместим в каталог lib, и вынесем его выше корневого веб-каталога www:
/lib --/controller ---- FrendCnt.php --/model ---- Frend.php ---- FrendList.php --/view ---- frendlist.php ---- frendone.php /www -- index.php -- .htaccess
Вынесение каталога lib (содержащего движок нашего сайта) из веб-каталога даёт нам бОльшую защищённость, делая нашу систему недоступной для посягательств шаловливых ручонок взломщиков.
Контроллер
Теперь обо всём по порядку. Начнём с контроллера , так как он первый из трёх компонентов паттерна встречает клиентский запрос, разбирает его на элементы, инициализирует объекты модели. После обработки данных моделью, он принимает её ответ и отправляет его на уровень представления.
В нашем простом примере, контроллер будет сконцентрирован в одном классе FrendCnt . Подробнее его опишем позже.А сейчас немного о точке входа в веб-приложение — это, конечно, будет файл index.php . В нём, мы определим точку отсчёта для подключения наших скриптов. Создадим экземпляр контроллера, и вызовем у него метод, который начнёт обрабатывать HTTP-запрос и определит что делать дальше.
Листинг №1 (файл index.php):
$baseDir = dirname(__FILE__) . "/.."; include_once($baseDir . "/lib/controller/FriendCnt.php"); $controller = new FriendCnt(); $controller->invoke();
Теперь о контроллере. У нас — это класс FriendCnt . Вы уже заметили, что экземпляр этого класса создаётся в index.php . Он имеет только один метод invoke() , который вызывается сразу после создания экземпляра. В конструкторе контроллера, создаётся объект на основе класса модели — FrendList (список друзей) для оперирования с данными.
В функции invoke() , на основе пришедшего HTTP-запроса, принимается решение: какие данные потребуются от модели. Затем происходит вызов метода извлекающего данные. Далее происходит подключение шаблонов для отображения, которым передаются данные из контроллера. Обратите внимание, что контроллер ничего не знает о базе данных или о том, как страница генерится.
Листинг №2 (файл контроллера FriendCnt.php):
Require_once($baseDir . "/lib/model/FriendList.php"); class FriendCnt { public $oFriendList; public function __construct() { $this->oFriendList = new FriendList(); } public function invoke() { global $baseDir; $oFriendList = $this->oFriendList; if(isset($_GET["key"])) { $oFriendList->setKey($_GET["key"]); $oFriend = $oFriendList->fetch(); include $baseDir . "/lib/view/friendone.php"; }else { $aFriend = $oFriendList->fetch(); include $baseDir . "/lib/view/friendlist.php"; } } }
Модель и сущности
Модель — это образ реальности, из которой взято только то, что нужно для решения задачи. Модель концентрируется на логике решения основной задачи. Многие называют это бизнес-логикой, на ней лежит большая ответственность:
- Сохранение, удаление, обновление данных приложения. Это реализуется через операции с базой данных или через вызов внешних веб-сервисов.
- Инкапсуляция всей логики приложения. Абсолютно вся логика приложения без исключений должна быть сконцентрирована в модели. Не нужно какую-то часть бизнес-логики выносить в контроллер или представление.
У нас к модели относятся два скрипта, в каждом из которых определён свой класс. Центральный класс FriendList и класс-сущность Friend . В центральном классе, происходит манипуляция с данными: получение данных от контроллера и их обработка. Класс-сущность служит контейнером для переноса данных между моделью и представлением, а также определяет их формат. При хорошей реализации паттерна MVC, классы сущности не должны упоминаться в контроллере, и они не должны содержать какую-либо бизнес-логику. Их цель - только хранение данных.
В классе FriendList , работающем со списком друзей, мы создали функцию, которая моделирует взаимодействие этого класса с базой данных. Метод getFriendList() возвращает массив из объектов, созданных на основе класса Friend . Для обеспечения удобства работы с данными, также была создана функция, индексирующая массив объектов. Контроллеру оказались доступны только два метода: setKey() — устанавливает поле ключа, по которому возвращаются детальные данные о друге; fetch() — возвращает или конкретный объект или весь список друзей.Листинг №3 (файл модели FriendList.php):
Require_once($baseDir . "/lib/model/Friend.php"); class FriendList { private $oneKey; private function getFriendList() { return array(new Friend("Александр", "1985", "[email protected]"), new Friend("Юрий", "1987", "[email protected]"), new Friend("Алексей", "1989", "[email protected]"),); } private function getIndexedList() { $list = array(); foreach($this->getFriendList() as $val) { $list[$val->getKey()] = $val; } return $list; } public function setKey($key) { $this->oneKey = $key; } public function fetch() { $aFriend = $this->getIndexedList(); return ($this->oneKey) ? $aFriend[$this->oneKey] : $aFriend; } }
В зависимости от реализации объектов Сущности, данные о ней, могут быть оформлены в виде XML-документа или JSON-объекта.
Листинг №4 (файл сущности Friend.php):
Class Friend { private $key; private $name; private $yearOfBirth; private $email; public function __construct($name, $yearOfBirth, $email) { $this->key = md5($name . $yearOfBirth . $email); $this->name = $name; $this->yearOfBirth = $yearOfBirth; $this->email = $email; } public function getKey() { return $this->key; } public function getName() { return $this->name; } public function getYearOfBirth() { return $this->yearOfBirth; } public function getEmail() { return $this->email; } }
Представление
Теперь нам нужно представить данные в наилучшем свете для пользователя.
Настал черёд поговорить о Представлении. В зависимости от задачи, данные могут быть переданы представлению в разных форматах: простые объекты, XML-документы, JSON-объекты и т.д. В нашем случае передаётся объект или массив объектов. При это мы не побеспокоились о выводе базового слоя — то, что относится к футеру и хедеру генерируемой страницы, этот код повторяется в обоих файлах представления. Но для нашего небольшого примера это не важно.
Главное здесь показать, что представление отделено от контроллера и модели. При этом контроллер занимается передачей данных от модели к представлению.
В нашем примере представление содержит только два файла: для отображения детальной информации о друге и для отображения списка друзей.
Листинг №5 (файл для вывода списка друзей friendlist.php):
Мои друзья Имя Год рождения getKey() ?>"> getName() ?> getYearOfBirth() ?> Листинг №6 (файл для вывода списка друзей friendone.php):
<?php echo $oFriend->getName() ?> : Мой друг getName() . "
"; echo "Год рождения: " . $oFriend->getYearOfBirth() . "
"; echo "Email: " . $oFriend->getEmail() . "
"; ?> СписокЕсли вы перенесёте весь этот код на веб-сервер, то в результате вы получите микро-сайт не на две страницы (если судить по количеству файлов представления), а уже на четыре. На первой будет показан список друзей, а на остальных трёх — детальная информация по каждому другу.
Мы могли бы реализовать детальный просмотр с помощью AJAX, тогда бы у нас была всего одна страница, и мы формировали бы часть представления через JSON-объекты непосредственно на компьютерах клиентов. Существует куча вариантов на этот счёт.
Это упрощённый пример веб-приложения на основе паттерна MVC. Но уже на нём можно увидеть массу возможностей. К плюсам мы уже отнесли гибкость и масштабируемость. Дополнительными плюсами будут — возможности стандартизации кодирования, лёгкость обнаружения и исправления ошибок, быстрое вхождение в проект новых разработчиков. Кроме того, вы можете в своём приложении изменять способ хранения сущностей, используя для этого сторонние веб-сервисы и облачные базы данных. Из минусов можно привести только небольшое увеличение объёма скриптов. А так, сплошные плюсы. Так-что пользуетесь на здоровье.
Здесь лежат файлы проекта, качайте сравнивайте:
Ну как? Какие мысли? Комментируем, не стесняемся.
Паттерн Model-View-Controller (MVC) , открытый в в конце 1970-х, представляет собой шаблон проектирования архитектуры программного обеспечения, основной задачей которого является отделение функций работы с данными от их представления. Теоретически, грамотно спроектированное MVC-приложение позволит фронтенд и бэкенд разработчикам в ходе работы не вмешиваться в зоны ответственности друг друга, то есть фронтенд-разработчику не понадобиться что-либо знать о «кухне» своего бэкенд-коллеги и наоборот.
Хотя изначально MVC был спроектирован для разработки десктоп-приложений, он был адаптирован для современных задач и пользуется у веб-разработчиков огромной популярностью, поскольку за счёт разделения ответственности стало возможным создавать более ясный, готовый к повторному использованию код. Паттерн MVC приводит к созданию ясных, модульных систем, что позволяет разработчикам очень быстро вносить изменения в существующий код.
В этой статье мы рассмотрим базовые принципы MVC, начав с определения паттерна и продолжив его применением в небольшом примере. Эта статья будет прежде всего полезна тем, кто ещё никогда не сталкивался с этим паттерном в жизни, а также, возможно, и тем, кто желает освежить в памяти знания об MVC.
Понимание MVC
Как уже было сказано, название паттерна происходит от аббревиатуры трёх слов: Model (модель), View (представление) и Controller (контроллер) . Вкратце принцип работы паттерна можно проиллюстрировать одной схемой ( можно найти на Википедии):
Эта схема наглядно показывает однонаправленность потока информации в паттерне, а также описывает роли каждого компонента.
Модель
Модель используется для доступа и манипулирования данными. В большинстве случаев модель — это то, что используется для доступа к хранилищу данных (например, базе данных). Модель предоставляет интерфейс для поиска данных, их создания, модификации и удаления из хранилища. В контексте паттерна MVC модель является посредником между представлением и контроллером.
Крайне важной чертой модели является то, что технически она не имеет никаких знаний ни о том, что происходит с данными в контроллере и представлении. Модель никогда не должна делать или ожидать каких-либо запросов в/из других компонентов паттерна.
Тем не менее, всегда помните, что модель — это не просто шлюз доступа к базе данных или другой системе, который только и занимается что передачей данных туда-сюда. Модель — это нечто вроде пропускного пункта к данным. Модель в большинстве случаев является самой сложной частью системы, отчасти из-за того, что сама по себе модель есть связующее звено для всех остальных частей.
Представление
Представление — это то, где данные, полученные от модели, выводятся в нужном виде. В традиционных веб-приложениях, разработанных в рамках MVC-паттерна, представление — это часть системы, где выполняется генерация HTML-кода. Представление также отвечает за получение действий от пользователя с тем чтобы отправить их контроллеру. Например, представление отображает кнопку в пользовательском интерфейсе, а после её нажатия вызывает соответствующее действие контроллера.
Существуют некоторые заблуждения относительно предназначения представления, особенно в среде веб-разработчиков, которые только начинают строить свои приложения с использованием MVC. Одним из наиболее часто нарушаемых правил является то, что представление никоим образом не должно общаться с моделью , а все данные, получаемые представлением должны поступать только от контроллера . На практике же разработчики часто игнорируют эту концепцию, стоящую в основах MVC-паттерна. В статье Fabio Cevasco наглядно показан этот сбивающий с толку подход к MVC на примере фреймворка CakePHP, одним из многих нестандартных MVC-фреймворков:
Крайне важно понимать, что для того, чтобы получить правильную MVC-архитектуру, не должно быть никаких прямых взаимодействий между представлениями и моделями. Вся логика обмена данными между ними должна быть реализована в контроллерах.
Помимо этого, существует распространённое заблуждение о том, что представление — это просто темплейт-файл. Как заметил Tom Butler, это заблуждение имеет огромный масштаб из-за того, что многие разработчики с самого начала неправильно понимают структуру MVC, после чего начинают вливать эти «знания» дальше, массы начинающих разработчиков. В действительности представление — это гораздо больше, чем просто темплейт, однако много фреймворков, построенных на базе MVC-паттерна, настолько исказили концепцию представления, что уже всем пофигу, насколько правильными являются их приложения с точки зрения MVC-паттерна.
Также важным моментом является то, что представление никогда не работает с «чистыми» данными от контроллера, то есть контроллер никогда не работает с представлением в обход модели. В процессе взаимодействия контроллера и представления модель всегда должна находиться между ними.
Контроллер
Контроллер — это последняя часть связки MVC. Задачей контроллера является получение данных от пользователя и манипуляция моделью. Именно контроллер, и только он, является той частью системы, которая взаимодействует с пользователем.
В двух словах контроллер можно описать как сборщик информации, передающий её модели для обработки и хранения. Он не должен делать ничего с данными, а только лишь уметь получать их от пользователя. Контроллер связан с одним представлением и одной моделью, организуя таким образом однонаправленный поток данных, контролируя его на каждом этапе.
Очень важно запомнить, что что контроллер начинает свою работу только в результате взаимодействия пользователя с представлением, которое вызывает соответствующую функцию контроллера. Самая распространённая ошибка среди разработчиков заключается в том, что контроллер рассматривается просто как шлюз между представлением и моделью. В результате чего контроллер наделяется теми функциями, который должны выполняться представлением (кстати, вот откуда растут ноги у идеи, что представление — это просто темплейт-файл). Вдобавок ко всему многие вообще сваливают всю логику обработки данных, забывая о том, для чего в паттерне MVC предназначена модель.
MVC в PHP
Предлагаю попробовать реализовать описанное выше в небольшом приложении. Начнём с того, что создадим классы модели, представления и контроллера:
string = "MVC + PHP = Awesome!"; } } controller = $controller; $this->
" . $this->model->string . "
"; } } model = $model; } }Основные классы готовы. Теперь давайте свяжем их вместе и запустим наше приложение:
output();
Как видите, контроллер не обладает никакой функциональностью, поскольку пользователь никак не взаимодействует с приложением. Вся функциональность помещена в представление, поскольку наше приложение предназначено исключительно для вывода данных.
Давайте немного расширим приложение, добавив немного интерактивности, чтобы увидеть, как работает контроллер:
string = “MVC + PHP = Awesome, click here!”; } } controller = $controller; $this->model = $model; } public function output() { return "
model->string . "
"; } } model = $model; } public function clicked() { $this->model->string = “Updated Data, thanks to MVC and PHP!” } }И в завершение немного модернизируем связующий код:
{$_GET["action"]}(); } echo $view->output();
Итоги
В этой небольшой статье мы рассмотрели основные концепции шаблона проектирования MVC и разработали простенькое приложение на его базе, хотя конечно, нам ещё очень далеко до того, чтобы использовать это в реальной жизни. В следующей статье мы рассмотрим основные затруднения, с которыми вы столкнётесь, если плотнее займётесь построением архитектуры приложения на базе MVC-паттерна. Stay tuned!
