Веб-фреймворки — обзор и классификация

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

При разработке веб-приложений программисты обычно прибегают к веб-фреймворкам. Но что такое фреймворк? И что делает фреймворк специфичным для веб-приложений?

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

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

• Не повторяйся (DRY): девиз «Не повторяйся» направлен на то, чтобы избежать избыточности в контексте разработки программного обеспечения. Избыточной информации, такой как дублирование кода, следует избегать, поскольку она оказывает негативное влияние на сопровождение программного обеспечения: если дублирующие участки кода необходимо адаптировать, изменения должны быть внесены в разные точки программного кода.

• Keep it short and simple (KISS): одна проблема — одно решение. Это основной принцип идеи KISS. Он основан на принципе парсимонии (принцип экономии): если существует несколько подходов к решению, следует выбрать решение с наименьшим количеством допущений и переменных. Чтобы использовать фреймворк или решить конкретную проблему, следует использовать как можно меньше кода.

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

Если принять во внимание эти принципы проектирования, то использование веб-фреймворков при разработке программного обеспечения дает множество преимуществ. Спецификации фреймворков также ограничивают разработчиков. Эти структурные ограничения иногда рассматриваются как недостаток.

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

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

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

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

Поскольку исходный код большинства веб-фреймворков находится в свободном доступе, у каждого есть возможность ознакомиться с ним. Если приложения разрабатываются для корпоративного использования на основе общедоступных компонентов кода, они могут быть более прозрачными для хакеров, чем приложения, исходный код которых не является публичным.

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

Центральные базовые компоненты программного каркаса представляют собой взаимодействующие классы с ассоциированными методами. Это блоки кода, которые описывают свойства программных объектов и их поведение. Некоторые из этих компонентов статичны и поэтому неизменны. Другие могут быть адаптированы пользователем, например, путем перезаписи методов. Это позволяет адаптировать структуру программы под конкретную задачу. Термин «горячие точки» был создан для обозначения гибких компонентов фреймворка. Статические компоненты называются «замороженными точками».

Веб-фреймворки обычно следуют концепции инверсии контроля (IoC). Это абстрактный принцип, описывающий аспект некоторых архитектурных конструкций программного обеспечения, в которых поток управления системами инвертирован, в отличие от процедурного программирования.

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

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

В разработке программного обеспечения IoC имеет статус общей концепции проектирования. Она применяется в таких паттернах проектирования, как Dependency Injection (DI) и Dependency Lookup.

Большинство всех фреймворков для веб-приложений основаны на архитектурном паттерне под названием Model View Controller (MVC). Это строгое разделение логики приложения и презентационного слоя и деление программного обеспечения на три области: модель (модель данных), представление (презентация) и контроллер (программное управление).

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

• Представление: основной задачей представления является отображение данных, предоставляемых моделью. Для этого представление делает запросы о состоянии модели с помощью различных методов и получает информацию о любых изменениях. Другая задача представления получать пользовательский ввод (нажатия на клавиатуру, щелчки мыши) и затем пересылать их контроллеру.

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

Целью архитектурного паттерна MVC является достижение гибкого дизайна программы. Разделение логики приложения и уровня представления должно означать, что впоследствии будет легче вносить изменения, а также добавлять расширения и повторно использовать отдельные компоненты. Это уменьшает объем программирования, необходимого для адаптации программного обеспечения к различным платформам (Windows, Mac, Linux) или в качестве веб-приложения, поскольку только контроллер и представление должны быть соответствующим образом адаптированы.

В виде модели 2 JSP (Java Script Pages) модель проектирования, основанная на MVC, также используется в веб-фреймворках на базе Java. JSP-страница соответствует представлению, сервлеты — контроллеру, а Java Bean — модели.

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

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

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

• Клиент-ориентированное: если весь пользовательский интерфейс HTML (включая логику приложения) загружается на клиент при запуске компьютера, это называется клиент-ориентированным приложением. Изменения интерфейса под воздействием пользовательского ввода в этом случае осуществляются с помощью языков программирования на стороне клиента, таких как JavaScript. Такой подход к проектированию рекомендуется для приложений, в которых пользователи работают с одним и тем же представлением в течение длительного периода времени, поскольку сервер перезагружает только данные, отображаемые на пользовательском интерфейсе. Подход на стороне клиента используется в основном при разработке одностраничных приложений и поддерживается такими JavaScript-фреймворками, как Angular JS или EmberJS.

• Сервер-центричный: в сервер-центричных приложениях логика приложения остается на сервере, который создает пользовательский интерфейс и передает его клиентам для представления. Для внесения изменений в пользовательский интерфейс доступны языки программирования на стороне сервера, и разработка в значительной степени не зависит от неопределенностей на стороне клиента. Этот подход обычно используется в многостраничных приложениях, где различные представления извлекаются с сервера. Такой дизайн программного обеспечения связан с более длительным временем загрузки, но снижает вычислительные усилия на клиентском устройстве. Некоторые приложения избегают замены логики управления по соображениям безопасности. Реализацию серверно-ориентированного подхода можно найти, например, в фреймворках Django, Zend и Ruby on Rails.

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

Клиент-ориентированные веб-приложения иногда называют Rich Clients или Rich Internet Applications (RIA). Пользовательский интерфейс реализует этот вид приложений на клиенте. Обычно они загружаются при запуске компьютера. В отличие от классических веб-приложений, клиент-ориентированный подход может быть использован для реализации таких функций, как управление перетаскиванием, автономная доступность и доступ к жесткому диску, которые более привычны для настольных приложений.

На уровне управления приложениями веб-фреймворки можно разделить на два класса. В то время как веб-фреймворки, основанные на действиях, постоянно демонстрируют связанную с HTTP схему «запрос-ответ», в веб-фреймворках, основанных на компонентах, она абстрагирована.

Веб-фреймворки на основе действий: когда речь идет о фреймворках на основе действий, контроллер выступает в качестве центрального экземпляра, который принимает запросы клиента, проверяет их и запускает соответствующее действие. Для каждого возможного действия разработчик приложения должен сначала создать программный объект, содержащий соответствующую логику приложения. Обычно он может быть получен из абстрактных классов. Если действие было выполнено, контроллер обновляет модель данных и передает результат представлению, которое, в свою очередь, создает ответ и отправляет его обратно клиенту.

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

• Django

• Ruby on Rails

• Symfony

• Spring MVC

• CodeIgniter

Поскольку возможные действия веб-фреймворка, основанного на действиях, подробно определяются разработчиком приложения, его называют подходом «белого ящика». Это дает разработчикам большую свободу, но требует более глубокого понимания веб-фреймворка, поскольку разработчики отвечают за создание HTML, CSS и JavaScript.

Компонентно-ориентированные веб-фреймворки: в отличие от подхода, ориентированного на действия, компонентно-ориентированные веб-фреймворки абстрагируют связанную с HTTP схему «запрос-ответ», рассматривая пользовательский интерфейс веб-приложения как набор компонентов. Для каждого из этих компонентов, которые связаны с программными объектами на стороне сервера, во время разработки веб-приложения определяются конкретные реакции. Они следуют за событиями, вызванными взаимодействием пользователя с компонентом. Именно поэтому упоминаются управляемые событиями веб-фреймворки. Классическими представителями являются:

• Lift

• Apache Tapestry

• JavaServer Faces

• Apache Wicket

Основная идея компонентного подхода заключается в объединении связанных действий. Например, компонент AccountController представляет такие действия, как вход в систему, выход из системы или getAccount. Таким образом, программный объект может отвечать за несколько действий. Основанные на компонентах веб-фреймворки обычно предоставляют большой выбор многократно используемых компонентов, которые скрывают от разработчика приложений детали базовой схемы «запрос-ответ». В данном контексте это известно как «черный ящик». Поэтому веб-фреймворки такого типа подходят для разработчиков, которые в первую очередь хотят полагаться на предопределенные компоненты. Тем, кто хочет получить больше свободы в отношении HTTP, HTML, CSS и JavaScript, лучше выбрать веб-фреймворк, основанный на действиях.

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

Ключевые вопросы касаются типа приложения и желаемой архитектуры (сервер-центричная, клиент-центричная). Оба аспекта оказывают непосредственное влияние на работу и удобство веб-приложений.

Прежде чем приступить к поиску подходящего веб-фреймворка, полезно владеть языками кодирования и иметь необходимую инфраструктуру. Существует широкий выбор хорошо документированных веб-фреймворков, особенно для известных языков программирования, таких как PHP (например, Zend, Symfony, CakePHP и CodeIgniter), Java (например, JavaServer Faces или Apache Wicket) или Python (например, Django). Популярность Ruby в веб-разработке в основном связана с популярным веб-фреймворком Ruby on Rails. Клиент-ориентированные веб-фреймворки обычно опираются на язык сценариев JavaScript.

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