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

Теория
Вот где MVC приходит на помощь. Это в целом попытка структурировать веб-приложение в три компонента:

• Модель в целом понимается как компонент администрирования данных. В большинстве веб-проектов это участие данных в реляционных системах баз данных, но оно может включать другие устойчивые бизнес-объекты, например, Enterprise Java Beans. Модель пассивна и ничего не запускает. Данные вызываются независимо от их вида (view); модель не знает ничего о представлении данных. Модель может работать с одним (отношения 1:1) или несколькими Видами и Контроллерами (отношения типа 1:n).


• Вид описывает визуальное представление Модели. В случае многих динамических веб-сайтов, вы можете представить один или два Вида в одной и той же Модели: в случае с этой статьей, одним Видом будет публичный – тот, в котором вы видите статью сейчас, и другим будет тот, в котором я могу ее создавать и редактировать. Конечно, есть много других возможностей: пользователи разных уровней, каждый с определенным набором прав; разные отображения одного и того же сайта для обычных пользователей; высокая контрастность для удобства чтения; Вид для печати без навигации и шапки, и так далее.


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

Чем дальше, тем лучше. Теперь, когда теория понятна, мы можем посмотреть, как это используется в процессе веб-разработки.
Действительно ли мне это нужно? Это довольно чувствительная тема. При ее исследовании я нашел несколько подходов, большинство из которых где-то в треугольнике из решительных, сердитых и невежественных. Я хочу отметить самые очевидные причины использовать его, надеюсь, что не наступлю никому на мозоль:

• Соотнесите мыслительный паттерн: внести свой код в программный паттерн довольно сложно, когда вы пытаетесь делать это во время программирования, но идея состоит в том, чтобы сначала структурировать код в голове или на листе бумаги или, для более масштабных проектов – с помощью инструментов CASE. С документированной структурой, ваш код становится более управляемым, и количество людей, которые хотят видеть вас горящим в аду (возможно, даже вы сами раз в 1-2 года), уменьшается. Каждый разработчик, который понимает MVC, быстро найдет путь в вашем коде, и вы оба будете работать на одной волне, потому что вы следуете одному образцу, в коде и мыслях.


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

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

Практика
Я обнаружил, что Jakarta Struts – это действительно хорошее Java-решение, и недавно журнал PHP Architect предложил бесплатно скачать их майский выпуск 2003 года, который содержит хорошую вступительную статью с решением, основанном на шаблонах Smarty. На сайте Tony Marston'а среди тонн информации и образцов дизайна можно найти расширенное решение, которое включает трехуровневую архитектуру, тоже основанную на PHP.
Я мог бы остановить на этом и оставить вас с одним из примеров, но позвольте мне сказать следующее: я считаю, что размер проекта и возможность смены или обновления отдельных компонентов должно играть такую же важную роль, как и возможность повторного использования кода.
С течением времени мы с Паскалем достигли слабенького фреймворка из PHP классов, который сохранил кучу времени во время создания проектов средней масштабности, благодаря возможности повторного использования их подкомпонентов.
Виды установлены с помощью CSS и (Х)HTML, сгенерированных шаблонами стилей XSL.
Во внутреннем (backend) PHP, классы структурированы по их функциональности. Класс db управляет работой всех баз данных на самых низких уровнях: для смены базы данных замените его или измените конфигурацию. Этот класс представляет Модель. Ваш сервер был взломан и вам требуется ссылаться на резервный db-сервер? Это делается за 10 секунд.
Базовый класс, тем временем, несет в себе все вспомогательные функции, которые используется в большинстве проектов, к примеру, как строка и операции с датой. Это расширение класса page, которое следует добавлять в проект в первую очередь. Мы позаботились о структуре сайта (обычно рытье базы данных тем или иным способ, как дерево или плоскую модель страницы), функции для breadcrumbs и навигации получают данные и возвращают XML, глобальные элементы сайта получают свои данные. Но не только это: здесь также можно найти все, что в общем называется бизнес логика, вычисления, автоматизация работы и тому подобное. Класс может быть расширен для страниц специального назначения, чтобы сохранять их красивыми и аккуратными. Я их группирую как Контроллер. Они получают все запросы, приписывают значение Модели (класс db) чтобы доставить XML, чтобы видоизмениться Видом (View) с помощью XSL.
Но это не совсем точно подходит к MVC паттерну: ни один SQL не будет найден в классе страницы. Обычный прием в этом случае – установить класс для каждой таблицы, которая содержит все запросы. В таком случае, вы знаете, где найти ваши SQL и к каким классам обращаться, чтобы сделать изменения в db-сервере. В качестве альтернативы, вы можете расширить db-класс и озаглавить его функциями более высокого уровня, которые составят для вас SQL. С одной стороны, вам необходимо изменять только один файл (в отличии от того, когда у нас файл для каждой таблицы); с другой стороны – решения развиваются довольно сложно, тем самым усложняя работу следующему разработчику. К тому же, он может быть слишком специфичным для одного сайта, и таким образом, не очень портативным.
Установив эти классы как стартовый пакет, вы получите невероятно быстрые результаты – и работа в frontend/backend команде станет удовольствием. Просто заполните абстрактный файл XML всеми данными, которые вам необходимы, и его можно будет обрабатывать в двух направлениях: xsl/html/css с одной стороны и php/db – с другой.
Для некоторых случаев я оставляю табличные классы как набор для проектов среднего размера. В других случаях я или либо использую реляционные базы данных (обычно эффективно) и спрограммированный в чистом SQL-92 – хотя это становится неудобным, и я не уверен, следуют ли обычные базы данных этому стандарту – или же я убеждаюсь, что приложение базы данных оставалось без изменений на протяжении всего существования сайта.
Как и с большинством вещей в современном цифровом мире, сайты постоянно изменяются, но код едва ли выдерживает более трех лет. Ваш бюджет, временные рамки и назначение сайта, будут определять насколько вы хотите использовать MVC. Но это всегда достойно размышлений.

Оригинал: MVC in smaller web applications