• На основе аннотаций
• Соблюдает принципы проектирования SOLID:
• S – принцип единой ответственности
• O – принцип открыт-закрыт.
• L - принцип замены Лискова
• I – принцип разделения интерфейса.
• D – принцип инверсии зависимостей
• На основе событий
• Гибкая основа
Аннотации являются основной частью Athena, поскольку они, помимо прочего, являются основным способом определения и настройки маршрутов. Например, они используются для указания того, какой HTTP-метод и путь обрабатывает действие контроллера, какие параметры запроса следует читать и любую пользовательскую логику, которую вы хотите, с помощью определяемых пользователем аннотаций. При таком подходе вся логика, связанная с действием, централизована в самом действии, а не в одном файле, а логика маршрутизации — в другом. Хотя Athena широко использует аннотации, мы не собираемся углубляться в них, поскольку они будут рассмотрены более подробно в Главе 11 «Введение в аннотации».
Поскольку Crystal является объектно-ориентированным (ОО) языком, Athena рекомендует следовать лучшим практикам объектно-ориентированного программирования, таким как SOLID. Эти принципы, особенно принцип инверсии зависимостей, весьма полезны при разработке приложения, которое легко поддерживать, тестировать и настраивать за счет интеграции сервисного контейнера внедрения внешних зависимостей (DI). Каждый запрос имеет собственный контейнер со своим набором сервисов, что позволяет обмениваться состоянием, не беспокоясь о потере состояния между запросами. Использование контейнера службы DI за пределами самой Athena возможно при использовании этого компонента отдельно, однако то, как лучше всего реализовать/использовать его в проекте, немного выходит за рамки этой главы.
Athena — это платформа, основанная на событиях. Вместо использования цепочки HTTP::Handler в течение жизненного цикла запроса создаются различные события. Эти события и связанные с ними прослушиватели используются для реализации самой платформы, но пользовательские прослушиватели также могут использовать те же события. В конечном итоге это приводит к очень гибкой основе. Поток запроса изображен на следующем рисунке:
Рисунок 9.1 - Схема жизненного цикла запроса
Прослушиватели этих событий можно использовать для чего угодно: от обработки CORS, возврата ответов об ошибках, преобразования объектов в ответ посредством согласования содержимого или чего-либо еще, что может понадобиться вашему приложению. Пользовательские события также могут быть зарегистрированы. См. https://athenaframework.org/comComponents/ для более подробного изучения каждого события и того, как они используются.
Хотя это может показаться очевидным, важно отметить, что Athena Framework — это платформа. Другими словами, его основная цель — предоставить вам строительные блоки, используемые для создания вашего приложения. Фреймворк также использует эти строительные блоки внутри себя для построения основной логики фреймворка. Athena старается быть максимально гибкой, позволяя вам использовать только те функции/компоненты, которые вам нужны. Это позволяет вашему приложению быть настолько простым или сложным, насколько это необходимо.
У Athena также есть несколько других компонентов, которые выходят за рамки этой главы, чтобы их более подробно изучить. К ним относятся следующие, ссылки на которые приведены в разделе «Дополнительная литература» в конце главы:
• EventDispatcher — обеспечивает работу прослушивателей и основанную на событиях природу Athena.
• Console — позволяет создавать команды на основе CLI, аналогичные задачам rake.
• Routing. Эффективная и надежная маршрутизация HTTP.
Кроме того, посетите https://athenaframework.org/, чтобы узнать больше о платформе и ее функциях. Не стесняйтесь зайти на сервер Athena Discord, чтобы задать любые вопросы, сообщить о любых проблемах или обсудить возможные улучшения платформы.
Но хватит разговоров. Давайте приступим к написанию кода и посмотрим, как все происходит на практике. В этой главе мы рассмотрим создание простого приложения для блога.
Начало работы с Афиной
Подобно тому, что мы делали при создании нашего приложения CLI в Главе 4 «Изучение Crystal посредством написания интерфейса командной строки», мы собираемся использовать команду crystal init для формирования каркаса нашего приложения. Однако, в отличие от прошлого раза, когда мы создавали библиотеку, мы собираемся инициализировать приложение. Основная причина этого в том, что мы также получаем файл shard.lock, позволяющий воспроизводить установку, как мы узнали в предыдущей главе. Полная команда в конечном итоге будет выглядеть как блог приложения crystal init.