Моя интерпретация широко известного паттерна.
Это классический подход для построения веб-приложений, который находит применение практически везде
Он говорит от том, что есть 3 основных компонента:
- Model - данные
- View - предстваление
- Controller - бизнес логика
Это такая абстракция, которая позволяет сгруппировать компоненты/классы/функции по выполняемым задачам.
Model
Так, например, модель хранит и получает данные. Не важно откуда. Это может быть база данных, текстовый файл, сервисы гугла или даже термометр на подоконнике. Важно что модель позволяет работать с определённым типом данных.
Важно понимать, что модель не имеет представления зачем кому то нужны эти данные. Ей об этом знать не нужно.
View
Представление - отображение полученной информации. Предствление понятия не имеет откуда взялись эти данные, и часто даже не знает что это такое. Зато представление может показывать переданные данные, т.е. оно знает как их отображать. Самый простой пример представления - это то, куда ты смотришь. Это экран, на котором написан этот текст. Представление знает как показать этот текст, но не знает откуда этот текст появился. Также представления - это шаблоны сайтов, формочки в телефоне, графики, каптчи, rss фиды.
Controller
Бизнес-логика - связующее звено. В зависимости от задачи, которая поступила контроллеру он выдёргивает нужные данные из модели и помещает их в нужное представление. Некий glue.
Контроллер не знает как получаются данные и каким образом будет отображать предствление, но знает какую модель и какое представление нужно использовать для конкретного запроса. Как менеджер :)
Например?
А теперь пример с температурой (нечто дающее информацию о температуре).
У нас есть модель - это может быть: сервисы яндекса, сохранёная температура в бд или термодатчик подключенный к компу. Каждая модель знает как работать со своим datasource(интернет, подключение к бд, последовательный порт)
У нас есть представление - это может быть: вывод в консоль, вывод на экран компьютера, зачитывание голосом компьютера или вывод на принтер. Опять же - на вход одни и те же данные (цифра - температура), а каждое предстваление знает "показать" то, что ему пришло.
И наконец бизнес-логка это всё объединяет - оно понимает что его спрашивают и дёргает нужную модель, подсовывая данные в нужное представление. Важно, что контроллер не знает как были полученны данные и как они будут отображаться.
Итого
Если не понятно, перечитай ещё раз, продолжая ассоциативный ряд моих примеров.
Лучше поймёшь только когда напишешь сам :) Вот только тогда наступает полное понимание.
И да, история про MVC это история о малосвязанности компонентов. Как ты понял что каждый компонент делает только то, что он знает, не лезя в чужое дело.
