Разделение кода. Модель MVC. Создание HTML-элементов

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, согласно которой :
- Модель относилась к «разуму» пользователя;
- Под представлением имелся в виду редактор, позволяющий пользователю просматривать и обновлять информацию;
- Контроллер являлся инструментом для связывания представлений воедино и применялся пользователем для решения его задач.
Назначение

Основная цель применения этой концепции состоит в отделении бизнес-логики (модели ) от её визуализации (представления , вида ). За счёт такого разделения повышается возможность повторного использования кода . Наиболее полезно применение данной концепции в тех случаях, когда пользователь должен видеть те же самые данные одновременно в различных контекстах и/или с различных точек зрения. В частности, выполняются следующие задачи:
1. К одной модели можно присоединить несколько видов , при этом не затрагивая реализацию модели . Например, некоторые данные могут быть одновременно представлены в виде электронной таблицы , гистограммы и круговой диаграммы ;
2. Не затрагивая реализацию видов , можно изменить реакции на действия пользователя (нажатие мышью на кнопке, ввод данных) - для этого достаточно использовать другой контроллер ;
3. Ряд разработчиков специализируется только в одной из областей: либо разрабатывают графический интерфейс , либо разрабатывают бизнес-логику . Поэтому возможно добиться того, что программисты, занимающиеся разработкой бизнес-логики (модели ), вообще не будут осведомлены о том, какое представление будет использоваться.
Концепция

Концепция MVC позволяет разделить модель, представление и контроллер на три отдельных компонента:

Модель

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

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

Представление отвечает за получение необходимых данных из модели и отправляет их пользователю. Представление не обрабатывает введённые данные пользователя [ ] .
Представление может влиять на состояние модели сообщая модели об этом.

Контроллер

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

Функциональные возможности и расхождения

Поскольку MVC не имеет строгой реализации, то реализован он может быть по-разному. Нет общепринятого определения, где должна располагаться бизнес-логика. Она может находиться как в контроллере, так и в модели. В последнем случае, модель будет содержать все бизнес-объекты со всеми данными и функциями.
Некоторые фреймворки жестко задают где должна располагаться бизнес-логика, другие не имеют таких правил.
Также не указано, где должна находиться проверка введённых пользователем данных. Простая валидация может встречаться даже в представлении, но чаще они встречаются в контроллере или модели.
Интернационализация и форматирование данных также не имеет четких указаний по расположению.

Условно-обязательные модификации

Для реализации схемы «Model-View-Controller» используется достаточно большое число шаблонов проектирования (в зависимости от сложности архитектурного решения), основные из которых - «наблюдатель », «стратегия », «компоновщик » :
Наиболее типичная реализация - в которой вид отделён от модели путём установления между ними протокола взаимодействия, использующего «аппарат событий» (обозначение «событиями» определённых ситуаций, возникающих в ходе выполнения программы, - и рассылка уведомлений о них всем тем, кто подписался на получение): при каждом особом изменении внутренних данных в модели (обозначенном как «событие»), она оповещает о нём те зависящие от неё представления, которые подписаны на получение такого оповещения - и представление обновляется. Так используется шаблон «наблюдатель »;
При обработке реакции пользователя - представление выбирает, в зависимости от реакции, нужный контроллер , который обеспечит ту или иную связь с моделью. Для этого используется шаблон «стратегия », или вместо этого может быть модификация с использованием шаблона «команда »;
Для возможности однотипного обращения с подобъектами сложно-составного иерархического вида - может использоваться шаблон «компоновщик ». Кроме того, могут использоваться и другие шаблоны проектирования - например, «фабричный метод », который позволит задать по умолчанию тип контроллера для соответствующего вида.

Наиболее частые ошибки

Начинающие программисты очень часто трактуют архитектурную модель MVC как пассивную модель MVC: модель выступает исключительно совокупностью функций для доступа к данным, а контроллер содержит бизнес-логику . В результате - код моделей по факту является средством получения данных из СУБД , а контроллер - типичным модулем , наполненным бизнес-логикой (см. «скрипт » в терминологии веб-программирования). В результате такого понимания - MVC-разработчики стали писать код, который Pádraic Brady (известный в кругах сообщества «Zend Framework ») охарактеризовал как «ТТУК» («Толстые, тупые, уродливые контроллеры»; Fat Stupid Ugly Controllers):

Среднестатистический ТТУК получал данные из БД (используя уровень абстракции базы данных, делая вид, что это модель) или манипулировал, проверял, записывал, а также передавал данные в Представление. Такой подход стал очень популярен потому, что использование таких контроллеров похоже на классическую практику использования отдельного php-файла для каждой страницы приложения.

Но в объектно-ориентированном программировании используется активная модель MVC, где модель - это не только совокупность кода доступа к данным и

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

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

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

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

Принцип MVC используют практически все современные фреймворки.

Рассмотрим подробнее компоненты.

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

View (Вид, Представление) описывает внешний вид приложения.

Controller (Контроллер) - связующее звено между моделлю и видом, получает данные от пользователя, передает их модели, получает обработанный результат и передает его в представление.
Взаимосвязь можно посмотреть на диаграмме:
Источник изображения: http://www.wikipedia.org Требования к компонентам:

Модели:
- должны содержать свойства, представляющие конкретные данные;
- должны включать в себя бизнес-логику (например, правила валидации), чтобы убедиться в том, что данные соответствуют предъявленным требованиям;
- могут содержать код для работы с данными.
Представления:
- должны, главным образом, содержать разметку, такую как HTML, и простой PHP код, используемый для обхода, форматирования и отображения данных;
- не должны напрямую обращаться к базе данных. Этим должны заниматься модели;
- не должны напрямую обращаться к $_GET , $_POST и другим переменным, получаемым из запроса пользователя. Эту задачу должен выполнять контроллер. Представления должны использоваться только для оформления данных, полученных от контроллера и модели;
- могут напрямую обращаться к свойствам и методам контроллера или моделей. Однако это должно делаться только в целях отображения данных.
Контроллеры:
- могут обращаться к $_GET , $_POST и другим переменным PHP, получаемым из запроса пользователя;
- могут создавать экземпляры моделей и управлять ими. К примеру, в типичном действии обновления модели контроллер может сначала создать экземпляр модели, затем заполнить его данными из $_POST и, в случае успешного сохранения модели, перенаправить браузер пользователя на страницу созданной модели. Стоит отметить, что само сохранение модели должно быть реализовано в классе модели, а не в контроллере;
- не должны содержать SQL-запросы. Их лучше держать в моделях;
- не должны содержать HTML и другую разметку. Её стоит вынести в представления.
(Требования позаимствованы отсюда: http://yiiframework.ru/doc/guide/ru/basics.best-practices)
Кроме концепции MVC существуют и многие другие, например MOVE ( M odels, O perations, V iews и E vents) - вроде, как эволюция MVC (взято отсюда: http://habrahabr.ru/post/147038/), но эти концепции менее распространенные.
В номере
Просто проверить, сложно повторить
В последние годы Гознак активно разрабатывает и продвигает на рынок наиболее эффективные защитные технологии. Среди них выделяются два направления: по созданию элементов, видимых на просвет, и признаков, полученных за счет сочетания офсетной и металлограф
Сегодня в банкнотной отрасли как никогда востребованы эффективные технологические и защитные решения. Гознак в последние годы уделяет особое внимание разработке и продвижению на рынок таких решений, концепцию которых можно сформулировать так: разработка простых для идентификации, но сложных в воспроизведении защитных признаков, получаемых на стандартном оборудовании. Этот подход к разработке эффективных защитных технологий проиллюстрируем на примере развития двух направлений: получения оптически-переменных признаков, видимых на просвет, и признаков, полученных за счет сочетания офсетной и металлографской печати.
Просветленные технологии
Водяной знак, наблюдаемый в бумаге в проходящем свете, остается наиболее популярным защитным признаком у населения. При этом он технологичен, а опыт производства бумаги с водяными знаками исчисляется более чем семью столетиями. Именно поэтому за последние годы благодаря появлению новых технологий изготовления формных изделий этот защитный признак получил новое развитие. Многотоновые водяные знаки практически во всех модернизированных банкнотах уступили свое место водяным знакам, полученным за счет комбинирования многотоновых и филигранных знаков. А в настоящее время активно внедряется технология получения водяных знаков за счет сложных многоуровневых филиграней. Журнал «Водяной знак» неоднократно рассказывал об этих водяных знаках. Эта технология дает возможность получить не только контрастные светлые участки знака, но и изображения с высокой, нетипичной для водяных знаков линиатурой.
Защитные нити, как и контролируемые на просвет водяные знаки, имеют, в отличие от последних, не столь давнюю историю – чуть больше полутора веков. Однако они прочно обосновались на верхнем уровне защитных технологий. Это связано как с хорошей технологичностью изготовления бумаги с защитными нитями, так и с их широчайшими возможностями выступать в качестве носителя различных защитных признаков и эффектов. При кажущихся неоспоримых преимуществах по сравнению с водяными знаками значительно более высокая стоимость самих защитных нитей снижает эффективность их использования, особенно на низких номиналах, где, как правило, применяются наиболее простые и, соответственно, более дешевые варианты нитей. Именно поэтому одним из направлений развития защитных нитей на Гознаке стало получение в бумаге прозрачного окна большой площади за счет введения при отливе бумаги широкой прозрачной полимерной ленты с последующим использованием стандартных печатных технологий для получения защитных эффектов в области окна. Поскольку полимерная пленка, из которой изготавливается лента, относится к массово выпускаемой продукции и не содержит эксклюзивных защитных признаков, ее стоимость существенно ниже стоимости нитей, имеющих цветопеременные, оптически-переменные и другие высокотехнологичные признаки. При этом аналогичные высокозащищенные оптически-переменные признаки можно получить с использованием традиционных печатных технологий, что делает это техническое решение более эффективным.
Именно такой подход был реализован в памятной банкноте «Сочи 2014». В прозрачном окне, полученном за счет введения широкой полимерной ленты в бумагу во время отлива, выполнен металлографским способом оптически-переменный защитный элемент «Зебра». При рассматривании на просвет и плавном повороте банкноты можно увидеть, как изображение снежинки в окне меняется с негативного на позитивное.
А что, если не вводить полимерную ленту для получения оптически-переменного признака, контролируемого на просвет? Или, по-другому, как получить в бумаге оптически-переменный элемент, контролируемый на просвет, с использованием традиционных банкнотных технологий? Именно такая задача была поставлена перед сотрудниками Дирекции по защитным технологиям и специалистами НИИ Гознака в 2014 году. Цель очевидна: избавиться от «дополнительного» элемента – широкой полимерной ленты и сложной технологии ее введения в бумагу, т. е. сделать защитное решение еще более эффективным.
Задача оказалась очень сложной, поскольку, с одной стороны, на конечный результат влияло большое количество факторов, а, с другой стороны, основные факторы оказались не только тесно связаны друг с другом, но и находились в противоречии друг с другом. Пришлось искать нестандартные решения. К концу 2014 года после проведенной научно-исследовательской работы была доказана принципиальная возможность получения таких защитных элементов. В 2015 году ФГУП «Гознак» выпущена рекламная банкнота «Русский Авангард», представленная заместителем генерального директора по науке и развитию А. Б. Курятниковым во втором номере журнала «Водяной знак» за 2015 год. В рекламной банкноте реализован защитный элемент «Силуэт» – оптически переменный элемент, видимый в проходящем свете и выполненный с использованием традиционных полиграфических банкнотных технологий в полупрозрачном окне, полученном с использованием традиционной технологии изготовления банкнотной бумаги. В настоящее время проводится работа так как по совершенствованию технологии получения полупрозрачного окна, и по оптимизации дизайна печатных элементов.
Игра в кубики
MVC, MVC+, HMC… Эти аббревиатуры названий защитных признаков, разработанных во ФГУП «Гознак», регулярно появляются на страницах журнала начиная с 2004 года. И если собрать все статьи, написанные на эту тему, получится целая история рождения, становления и развития одного из самых эффективных, на наш взгляд, защитных направлений. Особенность этого направления заключается в том, что для воспроизведения защитных элементов используется комбинация в виде согласованных по геометрическим параметрам линий, отпечатанных офсетным и металлографским способами печати.
Появившийся в модернизированных банкнотах Банка России защитный признак MVC Moire Variable Color – был предназначен, в первую очередь, для защиты от копирования. Напомним, как работает признак: на изначально однородном поле при наклоне банкноты появляются муаровые цветные полосы. На копии этот оптически-переменный эффект отсутствует, т. е. или цветные муаровые полосы не появляются, или обнаруживаются сразу, и картина остается без изменений при любых наклонах и поворотах банкноты. Потенциал этого признака оказался гораздо выше первоначально предполагаемого благодаря высокой стойкости к имитациям, технологичности, износостойкости и возможностям его дальнейшей модернизации. Простота его реализации в банкнотах городской серии модернизации 2004 г. и ожидаемые специалистами Гознака в связи с этим скорые имитации заставили модернизировать этот защитный признак в направлении создания более сложной для воспроизведения фальшивомонетчиками муаровой картины, обусловленной применением нелинейной структуры линий и применением комбинации бескрасочного тиснения и красочной металлографской печати. Так появилась следующая генерация оптически-переменного признака MVC+. Этот защитный элемент имеет две согласованные между собой области. В нижней области рисунок муара виден под любым углом, а в верхней области, как и в случае MVC, он появляется только под определенным углом. Очень важно знать, что при наклоне банкноты рисунок муара верхней и нижней частей должен образовать одну неразрывную картину без смещения муаровых линий на границе этих двух областей. Кроме того, этот защитный признак усилен кассовым уровнем защиты. При рассматривании элемента MVC+ под воздействием УФ-излучения можно наблюдать точно такой же муарообразующий эффект, как и при дневном свете. Защитный элемент MVC+ применен в банкнотах Банка России номиналом 1000 и 5000 рублей модернизации 2010 года.
Параллельно с MVC+ велись разработки нового защитного элемента, обладающего большим визуальным эффектом. И к 2010 году был создан новый защитный признак HMC (Hidden Multi Color), который стал еще более эффективным защитным элементом в этой серии признаков. Благодаря изменению геометрических параметров офсетных и металлографских линий при наклоне банкноты изначально однородное поле разбивается на отдельные фрагменты, окрашенные в разные цвета. В качестве цветных фрагментов используются цифры, текстовые символы, геометрические фигуры, любые произвольные области. Обычно применяется не более 2–3 цветов. Важной особенностью этого защитного признака является возможность дополнительной проверки его подлинности. Если запомнить цвета, видимые при наклоне банкноты, а потом развернуть банкноту в ее плоскости на 180 градусов, то можно увидеть совершенно другие цвета фрагментов. Этот эффект получен благодаря специальной форме линий и использованию уникального оборудования для изготовления металлографских форм. Как и у элемента MVC+, у защитного элемента HMC существует дополнительный кассовый уровень проверки подлинности: под воздействием УФ-излучения можно увидеть точно такие же оптически-переменные эффекты, как и при дневном свете. Защитный элемент HMC был внедрен в защитный комплекс банкноты Банка России номиналом 500 рублей модификации 2010 года.
Для получения защитных элементов серии MVC – HMC используются металлографские линии с достаточно большой глубиной рельефа. В условиях очень высокого давления при металлографской печати бумага деформируется, принимая форму профиля металлографских линий. Образующийся при этом рельеф возникает и на лицевой, и на оборотной стороне печатного листа. Если рельеф лицевой стороны «работает» в защитных признаках серии MVC – HMC, то оборотный рельеф до недавнего времени не использовался. Специалисты Гознака предложили интересное решение – создание оптически-переменных элементов и на лицевой, и на оборотной стороне банкноты при металлографской печати только с лицевой стороны. Такой элемент был разработан и реализован на рекламной банкноте «195 лет Гознака». Подробное описание этого элемента, получившего название CHMC (Сombined HMC) приведено в журнале «Водяной знак» №3 за 2013 г. Кроме получения оптически-переменных признаков на двух сторонах банкноты за счет использования важной технологической особенности офсетной печатной машины – обеспечения точной приводки печати лицевой и оборотной сторон, – получен элемент для контроля совмещения лицевой и оборотной сторон. Таким образом, CHMC – это «три в одном», т. е. оптические признаки с обеих сторон банкноты и элемент для контроля совмещения лицевой и оборотной сторон. Важной особенностью этого элемента является то, что на лицевой и оборотной сторонах банкноты можно получать независимо как MVC, так и HMC или их комбинации. Так, на рекламной банкноте «Русский Авангард» на лицевой стороне применен элемент HMC, а на оборотной – комбинация MVC и HMC.
Для получения наилучшего визуального эффекта при создании признаков серии MVC – HMC, особенно HMC, необходимо использовать при печати офсетных линий яркие контрастные цвета. Идеальный случай – применять цвета CMY. Однако часто при модернизации банкнот заказчик не разрешает менять цвета или использовать такие яркие цвета для офсетной печати. Поэтому приходится идти на компромисс между дизайном и визуальным эффектом. Особенно это актуально для элемента HMC. Именно для таких «сложных» в цветовом отношении банкнот были разработаны двух- и даже однокрасочные оптически-переменные элементы HMC. При этом однокрасочный элемент формально является двухкрасочным, поскольку в качестве второй краски используется пробел, т. е. цвет бумаги. Поэтому при наклоне банкноты цвет не меняется, появляется позитивное или негативное изображение.
Кроме того, любой из элементов серии MVC – HMC может быть дополнен скрытым или латентным изображением.
Таким образом, сегодня создана серия эффективных оптически-переменных защитных элементов, получаемых комбинацией офсетной и металлографской печати. Это своеобразный набор из кубиков, который можно использовать для построения уникального защитного комплекса для различных банкнот.
Развитие оптически-переменных защитных элементов серии MVC – HMC продолжается. Есть новые идеи. И вполне возможно, что в новой рекламной банкноте или каком-либо тиражном изделии в скором времени появится новая реализация защитного признака, основанного на комбинации офсетной и металлографской печати.

Концепция 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!