Framework-технологии разработки программного обеспечения

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

Среди классических примеров этого типа приложений - это веб-браузеры или браузерные игры. Модель лицензии «Программное обеспечение как услуга» подтверждена в контексте компании: существуют веб-приложения для процессов управления CRM (Customer Relationship Management), для систем управления товарами, для информационных бюллетеней, для планирования проектов, для записи рабочего времени сотрудника или для учета.

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

Для разработки веб-приложений программисты обычно используют фреймворки. Что это такое и что делают фреймворки настолько особенного для веб-приложений?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Фреймворки обычно следуют за шаблоном инверсии управления (IoC). Его можно охарактеризовать как приложение, основанное на голливудском принципе объектно-ориентированного программирования: «Не звоните нам, мы вам звоним!»

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

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

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

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

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

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

• Взаимодействие с пользователем: контроллер работает как интерфейс между Model и View. Таким образом, он управляет одним или несколькими видами, оценивает входные данные пользователя и соответственно реагирует, например, путем доставки данных в Модель или внесения изменений в представление.

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

Также есть Java Server Pages (JSP), который основан на шаблоне MVC и используется для веб-программирования на Java. Таким образом, страница JSP соответствует представлению, сервлету для контроллера и Java-компонента для модели.

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

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

Модель программирования классического веб-приложения соответствует модели World Wide Web, архитектура которой основана на протоколе гипертекстовой передачи (HTTP, Hypertext Transfer Protocol) . Если веб-приложение вызывается пользователем, в каждом случае задействован один или несколько серверов или клиентов, например браузер. В зависимости от того, как создается связь между сервером и клиентом, это называется серверными или клиентскими приложениями.

• Приложения на стороне клиента: если при запуске приложения загружается весь пользовательский интерфейс HTML, включающий логику приложения в клиенте, это называется клиентскими приложениями. В этом случае изменения интерфейса, связанные с пользовательским вводом, задаются на клиентских языках программирования, таких как JavaScript. Мы рекомендуем использовать такой подход к дизайну для приложений, где пользователи работают в течение более длительного периода времени на одном и том же представлении, поскольку только данные, отображаемые в пользовательском интерфейсе, перезагружаются с сервера. Клиентский подход используется в основном для разработки одностраничных приложений и используется инфраструктурами JavaScript, такими как AngularJS или EmberJS .

• Приложения на стороне сервера:в серверных приложениях логика приложения остается на сервере, что создает пользовательский интерфейс и отправляет данные для просмотра клиенту. Для изменений пользовательского интерфейса доступны серверные языки программирования, и разработка полностью не зависит от возможных уязвимостей клиента. Этот подход обычно используется в приложениях с несколькими страницами, где при необходимости извлекаются различные просмотры страниц, если это необходимо. Однако разработка программного обеспечения такого типа связана с более длительным временем загрузки, но уменьшает количество запросов, сделанных на клиентском устройстве. В некоторых приложениях вы избегаете хранения логики управления по соображениям безопасности. Приложение серверного подхода найдено, например, в рамках Django, Zend и Ruby on Rails .

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

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

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

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

Основанные на действии основы полагаются на модель MVC и, благодаря строгому применению схемы Request-Response, также называются основанными на запросах. Типичными примерами для этого типа рамок являются:

• Django
• Ruby on Rails
• Symfony
• Spring MVC
• CodeIgniter

Поскольку возможные действия основанной на действии структуры подробно определяются разработчиком приложения, мы говорим о подходе White Box, который дает разработчикам больше свободы. Однако требуется более глубокое понимание используемой структуры, поскольку разработчики несут ответственность за создание HTML, CSS и страниц JavaScript.

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

• Lift
• Apache Tapestry
• JavaServer Faces
• Apache Wickett

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

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

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

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

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