Паттерн MVC

Моя интерпретация широко известного паттерна.

Это классический подход для построения веб-приложений, который находит применение практически везде

Он говорит от том, что есть 3 основных компонента:

  • Model – данные
  • View – предстваление
  • Controller – бизнес логика

Это такая абстракция, которая позволяет сгруппировать компоненты/классы/функции по выполняемым задачам.

Model

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

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

View

Представление – отображение полученной информации. Предствление понятия не имеет откуда взялись эти данные, и часто даже не знает что это такое. Зато представление может показывать переданные данные, т.е. оно знает как их отображать. Самый простой пример представления – это то, куда ты смотришь. Это экран, на котором написан этот текст. Представление знает как показать этот текст, но не знает откуда этот текст появился. Также представления – это шаблоны сайтов, формочки в телефоне, графики, каптчи, rss фиды.

Controller

Бизнес-логика – связующее звено. В зависимости от задачи, которая поступила контроллеру он выдёргивает нужные данные из модели и помещает их в нужное представление. Некий glue.

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

Например?

А теперь пример с температурой (нечто дающее информацию о температуре).

У нас есть модель – это может быть: сервисы яндекса, сохранёная температура в бд или термодатчик подключенный к компу. Каждая модель знает как работать со своим datasource(интернет, подключение к бд, последовательный порт)

У нас есть представление – это может быть: вывод в консоль, вывод на экран компьютера, зачитывание голосом компьютера или вывод на принтер. Опять же – на вход одни и те же данные (цифра – температура), а каждое предстваление знает “показать” то, что ему пришло.

И наконец бизнес-логка это всё объединяет – оно понимает что его спрашивают и дёргает нужную модель, подсовывая данные в нужное представление. Важно, что контроллер не знает как были полученны данные и как они будут отображаться.

Итого

Если не понятно, перечитай ещё раз, продолжая ассоциативный ряд моих примеров.

Лучше поймёшь только когда напишешь сам :) Вот только тогда наступает полное понимание.

И да, история про MVC это история о малосвязанности компонентов. Как ты понял что каждый компонент делает только то, что он знает, не лезя в чужое дело.

  • =)

  • cassej

    я считаю такое представление в корне неправильным, и придерживаюсь концепции тонкого контроллер, и считаю, что модель должна отвечать за бизнес-логику, тогда в случае изменения среды исполнения бизнес-логика всегда останется неизменной, а вот контролер сможет поменять свое поведение в зависимости от того в каком окружении он выполняется, а то что по Вашему мнению делает модель называется DS(data source) – источник данных