Catalyst — Perl веб-фреймворк в лучших традициях MVC
Когда я подыскивал себе MVC веб-фреймворк для небольшого внутрикорпоративного проекта, у меня абсолютно не было опыта работы с паттерном MVC. Я знал лишь то, что данные, их представление и логику работы обязательно нужно разделять. Страшный опыт смешивания этих ингредиентов с получением серо-буро-малинового зелья из перлового кода, HTML и SQL у меня был. Тогда я хотел быстренько найти что-то похожее на Rails, потому что читал про него, но чтобы было на Perl или PHP и чтобы было все просто и красиво. Тогда я собственно и не знал чего толком я хочу, именно поэтому я остановил свой выбор на CakePHP: просто, красиво, была русскоязычная документация и на Руби на Рельсах похоже. Поначалу все было очень хорошо: быстро понял, что к чему, быстро разобрался, куда там код писать... но, потом хлебнул бочку дёгтя из ложки меда.
Я не хочу сейчас писать о том, куда же все-таки девается оперативная память при запросе к БД, почему реализация ActiveRecord в CakePHP настолько неуклюжа, по сравнению с Ruby-аналогом, почему мне легче написать тег элемента формы в ручную, чем использовать HtmlHelper и многое другое.
Простота! = гибкость.
Должен признать, что при всех своих недостатках, CakePHP дал мне понять очень важную вещь, а именно — что же я хочу получить от MVC веб-фреймворка. Я не хочу сказать, что CakePHP — это плохой и абсолютно непригодный для работы фреймворк. Нет. Он очень прост и понятен — и это его огромный плюс, но вместе с этим его возможности ограничены. Простые вещи делаются на CakePHP очень просто, но сложные вещи требуют затратить немалые усилия и по-прежнему остаются очень сложными.
Простота! = гибкость.
Простота CakePHP заключается в том, что все, что вам нужно, находится в одном фреймворке. Библиотечный код для упрощения работы с БД, роутеры для работы с URL, средства для обработки веб-форм и помощники для генерации HTML-элементов стандартны для фреймворка. С другой стороны, вы не можете заменить какой либо элемент фреймворка на тот, что более удобен вам, либо использовать элемент отдельно от фреймворка (модели, например). Все уже сделано за вас. Хотите писать на CakePHP — живите по нашим правилам.
Я глубоко уверен в том, что в фреймворке не должно быть навязанного библиотечного кода, который невозможно, либо очень сложно заменить. Сам MVC фреймворк должен быть клеем между Моделями, Контроллерами и Представлениями. Фреймворк должен предоставлять свободу прикручивать и использовать те компоненты системы, которые наилучшим образом подходят для конкретного проекта. И если фреймворк не будет навязывать свой библиотечный код, то эта задача вполне выполнима.
Catalyst — это элегантный веб-фреймворк
Я не знаю, почему Catalyst называют элегантным веб-фреймворком, но, очень большая доля правды в этом есть. Я бы банально назвал его гибким, мощным и удобным фреймворком. Но, фреймворков с такими эпитетами очень много, а вот элегантный пока только Catalyst.;) В чем же его элегантность гибкость и удобство? Ну, во-первых Catalyst делает только то, что должен делать веб-фреймворк — быть клеем между какими-то Моделями, какими-то Контроллерами и какими-то Представлениями.Какие-то Модели
Модели служат для отделения логики работы с базой данных от прочего кода в веб приложении. Стоп... Кто сказал, что Модель должна работать только с БД?! Нет... модель служит для того, чтобы предоставлять данные из какого угодно источника. Именно так, вроде бы сказано в определении роли Модели в MVC. Источником данных для Модели может быть все что угодно, начиная плоскими файлами иМодели в Catalyst не содержат огромных кусков библиотечного кода — они предназначены для адаптации существующих Perl-модулей для работы с Catalyst. Коме того, модели могут использоваться отдельно от фреймворка, это очень важный момент, если, к примеру, вы пишите отдельный от фреймворка модуль для импорта/экспорта информации, и хотите чтобы он использовал все те полезные функции, предоставляемые Моделью.
Особого внимания заслуживает вопрос работы с базой данных. Конечно же, вы всегда можете использовать чистый SQL для получения данных из БД. Но, на самом деле намного удобнее использовать ORM’ы — специальные модули, которые помогут вам упростить работу с БД путем замены ваших запросов на чистом SQL на работу с классами, которые возьмут на себя всю черную работу по формированию SQL-запросов и избавят вас от необходимости смотреть на листочек с дизайном вашей БД, каждый раз, когда вы создаете новый запрос, использующий больше чем одну таблицу. Использование ORM сделает ваш код для взаимодействия с БД чище и понятней как вам, так и вашим коллегам. Кроме того, ORM’ы делают ваш код переносимым между разными СУБД, и побочным эффектом использования этой технологии будет избавление от опасности SQL-инъекций. Уж поверьте, качественные ORM’ы следят за правильным формированием генерируемых ими SQL-запросов. Самым популярным ORM для Perl и Catalyst является DBIx: Class. Для него есть хороший мануал и многие другие модули поддерживают DBIx: Class (DBIC), работая с ним, как с родным. Кроме того, в официальных мануалах к Catalyst и других источниках информации вы найдете много примеров с использованием именно DBIC. Но, ваш выбор не ограничивается одним лишь DBIC. На CPAN можно найти еще парочку качественных ORM’ов. Лично я сейчас использую Rose: DB: Object из-за его гибкости и легкости в настройке. Так что, как работать с источником данных можно выбрать, и выбор этот зависит только от вас. Прикрутить Модель к Catalyst можно какую угодно. Вот почему этот блок текста я назвал «Какие-то Модели».
Контроллеры
Вы, наверное, не поверите, но контроллеры также можно прикручивать и откручивать. Сейчас можно упомянуть о том, что Catalyst — это полностью объектно-ориентированный веб-фреймворк. Все базовые классы Моделей, Контроллеров и Представлений наследуется от базового класса Компонент. Это дает вам возможность из Контроллера запросить Модель и настроить Представление. Ваши же Контроллеры наследуются от класса Catalyst: Controller, который реализует несколько базовых функций. Хотите больше? Поменяйте базовый класс! Вот, например, Catalyst: Controller: CRUD реализует код для основных функций чтения/записи в БД. А вот, к примеру, Catalyst: Controller: View делегирует запрос пользователя непосредственно в Представление. Таким образом, всю бизнес-логику можно реализовать в Представлении. Но, это уже, немного, извращение. Хотя, вполне реальное:)Представления
Я думаю, что уже даже не стоит говорить о том, что представление будет таким, какое вы захотите прикрутить. Чаще всего, функциональность представлений реализуют шаблонизаторы. Их много. Выбирайте на любой вкус и цвет. Самый популярный, мощный и гибкий — это, конечно же, старый добрый Template-Toolkit. К слову, если вы Python-разработчик, то вам будет интересен проект Template-Python, я писал как-то об этой разработке в своем блоге.Плагины
Есть вещи, которые сложно отнести непосредственно только к Модели, Контроллеру либо Представлению. Вот, скажем, разграничение прав доступа пользователей: в Контроллере вы будете проверять, не запросил ли текущий пользователь запрещенные данные, в Представлении будете решать какие элементы управления показывать пользователю, а в Модели можно вести журнал того, какой пользователь что изменял или удалял. Система разграничения прав доступа это одна сущность, к которой нужно иметь доступ из любой точки проекта. Это всего лишь пример одного плагина, но есть еще целая куча вариантов готовых для работы плагинов на CPAN, которые помогут в решении самых разнообразных задач.Генераторы кода
Наверно самое сложное для меня — это создать новый файл и с чистого листа начать писать новый модуль. Генераторы кода решают эту проблему. Теперь, чтобы создать новый Контроллер мне достаточно воспользоваться$ perl myapp_create.pl controller MyControllerName
И в новый контроллер будет помещен стандартный шаблонный код, который позволит сразу же проверить новый контроллер на работоспособность. Опять же есть очень много готовых генераторов кода и ничто не мешает вам создать свой.
Catalyst для Perl
Говорят, что Perl — это старый язык. Конечно же, много воды утекло после выпускаСкажем, к примеру, в Perl нет поддержки свойств (property) и их наследования — нет проблем: эту поддержку можно реализовать запросто, использовав модули Class: Accessor: Fast или Class: Data: Inheritable. Не понравилось, как работает алгоритм множественного наследования? — Реализуем свой в Class: C3.
Все эти вещи, и многое другое, активно используются в Catalyst, что позволяет вести комфортную разработку приложений, не отказывая себе в новомодных новшествах в мире ООП.
Полезные ссылки
В этой заметке я не приводил примеров кода, и еще много чего осталось за кадром. Моя цель — обратить внимание сообщества на то, что Perl не пасет задних в области веб программирования, и если вы хотите разработать что-то свое, что-то такое чего еще нет в достаточной мере в популярных CMS’ках — то обратите внимание на Catalyst. Это фреймворк, который избавит вас от необходимости искать «что-то лучшее» или «что-то более гибкое». Catalyst и есть то самое гибкое и... элегантное.;)В изучении веб-фреймворка вам поможет официальное вики, официальное руководство.
И замечательная книга Джонатана Роквея «Catalyst» . Конечно, эта книга не бесплатна, но, для человека, умеющего пользоваться Гуглом — это не проблема:)
93 коментарі
Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.