Повышаем свою стоимость: MVC

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

Обычно начинающие разработчики не задумываются об архитектуре, потому что им и без этого хлопот хватает. Но со временем жаждущий узнавать новое мозх обязательно скажет: "Эу, бро, а че ваще творится в этом приложении в целом? Откуда прилетают вот эти данные? А это как работает? Че вон там за магия творится? Хочу все знать, дай мне информацию".

Разумеется, как и в случае с объектами, для архитектуры существуют свои паттерны, причем есть как натуральные ветераны (MVC, MVP, MVVM), так и наглые молодые выскочки (микросервисная архитектура). Давайте начнем разбираться с "классикой".

Паттерн MVC

Ну-с, по традиции, дербанем википедию, а то лежит она там, чилится:

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

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

Про MVC только ленивый не писал (хотя, может и ленивые раскочегарились), на том же Хабре статей тьма тьмущая. Потому саму структуру краем хватану. Основной посыл будет таков - а на кой хрен вообще в этом нужно разбираться?

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

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

Почему именно MVC часто объясняется и приводится в пример? Да потому что у него довольно простая концепция, которую легко объяснить в теории. Однако, на практике не всегда получается сделать гладко, но это детали реализации.

Зачем вообще это все навыдумывали?

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

Представим, что UI вообще нет. От слова совсем. Но у нас есть хранилище данных и инструмент для манипулирования ими - БД и СУБД. Чтобы добавлять, изменять и удалять данные, используется язык структурированных запросов - SQL. Прикиньте, если пользователям вот так внаглую сказать: "Бро, вот тебе БД, вот инструкция по SQL - действуй, я свою работу выполнил - замутил тебе схемку". И будет тот самый пользователь, который кнопочку найти не может, хреначить SQL запросы прямо в БД, ага. Да никто не будет этим пользоваться, скажут вам подтереться вашей инструкцией.

Чтобы пользователей не разносило в щепки от атомных реакций внизу спины, нужно инкапсулировать от него всю работу с данными за UI, или за View в терминологии MVC. Пользователю начхать, что происходит после нажатия кнопки "Зарегистрироваться", "Отправить сообщение" или "Купить анорексия печень вожака 500/12 индиго самоварный". Он лишь знает, что произойдет какая-то магия и его пустят на сайт, его сообщение получит собеседник и ему пришлют товар с Китая.

То бишь, получаем такую картину: у нас есть уровень работы с данными - Model - в котором происходит взаимодействие с БД посредством SQL, и есть уровень представления - View - которое видит пользователь. Пользователь тыкает кнопку на View, View отправляет запрос напрямую в Model, Model совершает операцию с данными и возвращает ответ View. Вроде складно получается. Или нет?

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

В MVC роль посредника берет на себя Controller. Именно он предоставляет API для View, ждет вызова методов со стороны View, обрабатывает запросы, получает данные из модели и обновляет View. Всю логику, не связанную с данными, реализуют в контроллерах. Например, если контроллер принимает запрос от пользователя, у которого истек срок действия токена, он его сразу развернет обратно, не трогая модель. Контроллер может возвращать разные представления одних и тех же данных в зависимости от прав доступа.

Таким образом, можно обособленно разрабатывать Model и View, потому что Model начхать, как View будет отображать данные, а View начхать, как Model работает с данными. Собственно, как мы спрятали от пользователя БД за UI, так и от View спрятали Model за Controller. Инкапсуляций, мать её, благодать всех программистов.

Итого

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

Деталей вы до жопы найдете на Хабре, можно еще заглянуть сюда. Мы поговорим еще о нескольких паттернах, дабы сложилась общая картина и вы могли спокойно делать выбор в пользу той или другой архитектуры. Всем добра и бабла.