MVC, модель — как много в этом слове

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

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

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

…

Модели можно описать по-разному. На самом деле только об этом можно написать целую книгу, многие именно так и поступали! Как правило описываются две роли модели:

1. Модель отвечает за сохранения состояния между HTTP-запросами

2. Модель включает в себя все правила и ограничения, управляет поведением и использованием данной информации.

…

Все станет предельно ясно, как только вы задумаетесь над смыслом слова «модель». В климатологии есть модели климата, описывающие данные, процессы, предполагаемое поведение и позволяющие рассчитать возможные результаты. М в MVC называется моделью не просто так. Модель представляет не только данные, она представляет всю систему, в которой полезны эти данные.

…

Многие считают модель красивым словом для обозначения доступа к базе данных, другие приравнивают ее к разным шаблонам для доступа к базе данных, вроде Active Record, Data Mapper и Table Data Gateway. Фреймворки очень часто продвигают это заблуждение, ненамеренно, я уверен, но энергично. Не полностью понимая, что такое модель, почему это столь великолепная идея, и как ее надо разрабатывать и развертывать, разработчики непреднамеренно вступают на темный путь, ведущий к таким методикам разработки, которые иначе чем убогими и не назовешь.

…

Небольшое мысленное упражнение даст вам почву для размышлений. Представьте, что вы только что написали самое замечательное в мире веб-приложение с использованием Zend Framework. Клиент поражен, его восторги (и деньги) крайне приятны. К несчастью они забыли упомянуть, что их новый технический директор требует использовать Symfony во всех новых приложениях и предлагает крайне интересную сумму за преобразование вашего приложения. Вопрос: насколько это будет просто? Задумайтесь об этом на секунду…

Если логика вашего приложения завязана на модель — вы на коне! Symfony, подобно многим (но не всем) фреймворкам, принимает модели вне зависимости от того, поверх чего они написаны. Вы можете перенести вашу модель, ее юнит-тесты и вспомогательные классы на Symfony ничего или почти ничего не меняя. Если вы связали все это с контроллерами, у вас проблемы. Вы действительно считаете, что Symfony сможет использовать контроллеры Zend Framework? Что каким-то волшебным образом заработают функциональные тесты, использующие PHPUnit-расширение Zend Framework? Оба-на. Вот почему контроллеры не способны заменить модели. Их практически невозможно использовать повторно.

…

Так как разработчики очень часто занижают роль модели, ограничивая ее доступом к базе данных, как это по умолчанию делается в 99,9% фреймворков, нет ничего удивительного, что их не впечатляют связанные с ней теоретические идеалы. Сосредотачиваясь на доступе к данным разработчики полностью пускают один очень важный момент: классы моделей не связаны с текущим фреймворком. Им не требуется сложная установка, вы просто создаете и используете их объекты.

…

Так как разработчики почти ничего не знали о моделях, они изобрели новое понятие: толстые тупые уродливые контроллеры (ТТУК). Столь яркое определение я придумал не просто так, оно кажется очень забавным в 10 вечера, после нескольких кружек пива. И все равно вежливее того, что я о них на самом деле думаю. (Fat Stupid Ugly Controllers — FSUC — FUC). Их изобрели потому, что модели были непривычными, чуждыми и похожими на террористов сущностями, которым никто не решался доверить хоть что-то выходящее за пределы доступа к данным.

Типичный ТТУК читает данные с базы (используя уровень абстракции данных, который разработчики называют моделью), обрабатывает их, проверяет, пишет и передает в представление для вывода на экран. Он невероятно популярен. Я бы сказал, что большинство пользователей фреймворков создают их так же естественно, как раньше создавали контроллеры страницы (Page Controllers). Они популярны, потому что разработчики осознали, что они могут обращаться с контроллерами почти так же, как с контроллерами страницы — это практически не отличается от древней методики использования отдельных php-файлов для каждой «страницы» приложения.

http://habrahabr.ru/post/175465/

К сожалению, оригинальная статья не открывается.

Статья содержит еще много пламенных призывов и понятных разьяснений. Наслаждайтесь.

original post http://vasnake.blogspot.com/2013/07/mvc.html