Паттерны для новичков: MVC vs MVP vs MVVM. Удобный подход к веб-разработке: Модель MVC Шаблон проектирования mvc

В данной статье мы разберемся с понятием 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

firstname ?>

lastname?>

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

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

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

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

MVC пример

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

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

Фреймворк Bootstrap: быстрая адаптивная вёрстка

Пошаговый видеокурс по основам адаптивной верстки в фреймворке Bootstrap.

Научитесь верстать просто, быстро и качественно, используя мощный и практичный инструмент.

Верстайте на заказ и получайте деньги.

Бесплатный курс "Сайт на WordPress"

Хотите освоить CMS WordPress?

Получите уроки по дизайну и верстке сайта на WordPress.

Научитесь работать с темами и нарезать макет.

Бесплатный видеокурс по рисованию дизайна сайта, его верстке и установке на CMS WordPress!

*Наведите курсор мыши для приостановки прокрутки.

Назад Вперед

Удобный подход к веб-разработке: Модель MVC

Что такое MVC? Если отвечать кратко, то это подход к разработке, позволяющий добиться более структурированного кода и приложения в целом.

Расшифровывается MVC как "Модель-Вид-Контроллер" (Model-View-Controller). Давайте поговорим об этом подробнее.

На сегодняшний день можно выделить два наиболее типичных способа создания веб-приложений (сайтов).

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

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

После этого, как правило, начинается html-разметка страницы (куда же без нее?). Причем внутри html-разметки в нужных местах производятся вставки PHP-кода, которые производят управление сайтом, являются его логикой. Итого мы имеем в одном файле: SQL, (X)HTML и PHP. Это уже - сборная солянка. Не забудьте добавить сюда еще CSS и немного Javascript для полноты картины, и, в итоге мы получим такую кашу, что в этом файле сам черт ногу сломит.

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

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

Второй способ связан как раз-таки с применением схемы "Модель-Вид-Контроллер" .

В чем суть данного подхода, и как его использование может помочь вам в работе?

Основная идея данного подхода заключается в необходимости разделения однородных элементов по разным файлам . Если говорить очень упрощенно: один файл - один язык. Но это очень грубый пример. Такое встречается крайне редко.

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

Здесь мы начинаем с вами подходить к более подробному рассмотрению модели MVC.

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

1. Файлы группы "модель"
2. Файлы группы "контроллер"
3. Файлы группы "вид"

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

Итак, давайте посмотрим на сравнительную схему модели MVC и "классического" способа разработки .


В левой части вы видите как раз то, о чем мы говорили выше. Вверху страницы - SQL-запросы к базе. Затем разметка плюс вставки PHP.

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

В контроллере находится логика приложения , т.е. то, что определяет его функционал.

Вид же предназначен для показа конечному пользователю .

Двунаправленные стрелки на схеме показывают то, что в парах "Модель - Контроллер" и "Контроллер - Вид" существует взаимосвязь. Рассмотрим эту взаимосвязь подробнее на примере следующей схемы.


На этой схеме у нас добавилось два новых элемента: браузер пользователя и база данных. Рассмотрим в общих чертах весь цикл: от обращения браузера к определенному url-адресу до момента отображения страницы для пользователя:

1. Пользователь вводит адрес, и браузер обращается к контроллеру.

2. Контроллер обращается к модели.

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

4. Информация из базы попадает обратно в модель.

5. Из модели информация передается в контроллер.

6. Контроллер передает эту информацию в вид.

7. Вид выводится в браузер с помощью контроллера.

Такова общая схема работы данной модели. Как вы можете видеть, некоторым особняком на данной схеме стоят браузер и база данных. Действительно, браузер может обращаться только к контроллеру, так как контроллер является частью url-адреса . Посетитель не может обратиться к чему бы то ни было, кроме контроллера. Это важно понимать. Человек не может через адресную строку обращаться к видам или моделям. Он взаимодействует только с контроллером.

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

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

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

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

"Крайних" мы рассмотрели, а в центре схемы так и осталась наша троица, где происходят взаимодействия "Модель - Контроллер" и "Контроллер - Вид".

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

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

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

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

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

Среди других преимуществ модели MVC можно отметить разделение кода по функциональному признаку . Вам больше не нужно будет копаться в "каше" из SQL-запросов, разметки и PHP-кода. Если вам нужно что-то подправить или изменить, вы точно будете знать, какой именно файл вам надо править.

Ниже вы можете видеть часть файла, относящегося к группе "виды":


А вот кусок кода из модели:


Так может выглядеть контроллер:


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

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

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

Очевидны преимущества применения модели MVC в рамках фреймворка , например, того же CodeIgniter.

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

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

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

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

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

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

Дмитрий Науменко

P.S. Думаете, какой бы PHP-фреймворк освоить? Обратите внимание на CakePHP - он реализует рассмотренный выше паттерн MVC, и прямо сейчас вы можете получить небольшой вводный видеокурс, чтобы получить общее представление о возможностях этого фреймворка:

Понравился материал и хотите отблагодарить?
Просто поделитесь с друзьями и коллегами!


Шаблон проектирования Модель-Представление-Контроллер (MVC) — это шаблон программной архитектуры, построенный на основе сохранения представления данных отдельно от методов, которые взаимодействуют с данными.

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

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

Что такое MVC

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


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

Модель

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

При этом «Модель » не имеет никакой связи или информации о том, что происходит с данными, когда они передаются компонентам «Представление » или «Контроллер ». Единственная задача «Модели » — обработка данных в постоянном хранилище, поиск и подготовка данных, передаваемых другим составляющим MVC .

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

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

Представление — это часть системы, в которой данным, запрашиваемым у «Модели », задается окончательный вид их вывода. В веб-приложениях, созданных на основе MVC , «Представление » — это компонент, в котором генерируется и отображается HTML -код.

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

Существует несколько распространенных заблуждений относительно компонента «Представление ». Например, многие ошибочно полагают, что «Представление » не имеет никакой связи с «Моделью », а все отображаемые данные передаются от «Контроллера ». В действительности такая схема потока данных не учитывает теорию, лежащую в основе MVC архитектуры. В своей статье Фабио Чеваско описывает этот некорректный подход на примере одного из нетрадиционных MVC PHP фреймворков:

«Чтобы правильно применять архитектуру MVC, между «Моделью» и «Представлением» не должно быть никакого взаимодействия: вся логика обрабатывается «Контроллером».

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

Компоненту «Представление » никогда не передаются данные непосредственно «Контроллером ». Между «Представлением » и «Контроллером » нет прямой связи — они соединяются с помощью «Модели ».

Контроллер

Его задача заключается в обработке данных, которые пользователь вводит и обновлении «Модели ». Это единственная часть схемы, для которой необходимо взаимодействие пользователя.

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

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

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

MVC в PHP

Напишем на PHP веб-приложение, архитектура которого основана MVC . Давайте начнем с примера каркаса:

string = "MVC + PHP = Awesome!"; } } controller = $controller; $this->model = $model; } public function output(){ return "

" . $this->model->string . "

"; } } model = $model; } }

У нас есть проект с несколькими основными классами для каждой части шаблона. Теперь нужно настроить взаимосвязь между ними:

output();

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

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

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 модель дан-ных при-ло-же-ния, поль-зо-ва-тель-ский интер-фейс и вза-и-мо-дей-ствие с поль-зо-ва-те-лем раз-де-лены на три отдель-ных ком-по-нен-та, бла-го-даря чему моди-фи-ка-ция одного из них ока-зы-вает мини-маль-ное воз-дей-ствие на осталь-ные или не ока-зы-вает его вовсе.

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

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

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

Аль-тер-на-тив-ные назва-ния пат-терна MVC:

  • model-view-controller
  • модель-пред -став-ле-ние-пове -де-ние
  • модель-пред -став-ле-ние-кон -трол-лер
  • модель-вид-кон -трол-лер

Принцип 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/), но эти концепции менее распространенные.

Ios