О веб-фреймворках

Некоторое время назад мне пришлось освоить Django, при чём его возможности я использовал довольно интенсивно. Кроме того, я немного знаком с веб-фреймворком Dancer, на котором написал небольшое веб-приложение, и с Flask, с которым я немного экспериментировал. Суммируя приобретённый опыт, хочется озвучить несколько мыслей о веб-фреймворках вообще.

Что нравится в веб-фреймворках:

1. Система маршрутизации запросов. Позволяет легко создавать приятно выглядящие URL, легко их переделывать, определять, какой код будет запущен для обработки определённого URL.

2. Средства для доступа к данным запроса и ответа. Тут без комментариев. PHP сам по себе по этому критерию уже можно считать мини-фреймворком, потому что он позволяет избавиться от необходимости ручного парсинга данных протокола CGI и реализует удобный доступ к POST, GET, COOKIE и SESSION. Возможно именно этим и была обусловлена его популярность.

3. Система шаблонизации. Позволяет отделить данные от их оформления. На мой взгляд, ни один HTML-тег не должен формироваться внутри кода программы. HTML-теги, сформированные внутри кода программы, сразу же ставят под вопрос возможность использования шаблонизатора для формирования обычных текстовых файлов или возможность изменить вид страницы без погружения в дебри кода.

Что не нравится в фреймворках (на примере Django):

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

А может случиться так, что шаблонизатор вообще будет работать в отдельном процессе и поэтому лишь комбинирует шаблоны с JSON-структурами или двоичными данными. В качестве простейшего примера можно привести рендеринг шаблона средствами JavaScript на стороне браузера, из JSON-структуры, полученной от веб-приложения.

2. Библиотеки для работы с HTML-формами. На мой взгляд, в подобных библиотеках есть два самостоятельных функционала - генерация HTML-кода и валидация данных. Первое, на мой взгляд, гораздо удобнее делать при помощи шаблонизатора. При этом весь дизайн находится в коде шаблона и дизайнерам не нужно будет лезть в код приложения лишь для того, чтобы поправить дизайн форм. Со вторым может справиться какая-нибудь библиотека валидации форм.

3. ORM. Особенно в сочетании с предыдущими двумя пунктами. SQL-запросы к базе данных, формируемые на этапе отрисовки шаблона очень затрудняют отладку работы программы, оптимизацию запросов к базе данных и разработку дизайна.

ORM способствует увеличению количества неоптимальных запросов. Чтобы от ORM был толк, нужно не только знать SQL, но и знать тонкости работы ORM, чтобы понимать, какой запрос в каждом конкретном случае будет реально выполнен. Большинство же веб-программистов, использующих ORM, используют его лишь потому, что не понимают/не умеют/не хотят знать SQL. Не все, но большинство, увы.

Критика ORM - вообще обширная тема. Многие считают, что одна из задач ORM заключается в предоставлении удобной абстракции над разными СУБД. Но не многие знают, что для этой задачи существует нечто под названием DBAL. На мой взгляд, если задача абстракции от СУБД действительно встала, то стоит пользоваться DBAL, а не ORM. ORM в Django плох ещё и тем, что ограничен в возможностях и противопоставляет себя гораздо более достойной альтернативе - SQLAlchemy.

Таким образом, я считаю, что оптимальный веб-фреймворк должен включать в себя следующие компоненты:

1. Система маршрутизации запросов.
2. Средства для доступа к данным запроса и ответа.
3. Шаблонизатор без возможности вызова кода приложения.
4. Библиотека валидации данных.
5. При необходимости, если нужно обеспечить работу приложения над несколькими разными СУБД, - DBAL.