Файл: Варианты построения интерфейса программ: особенности и эволюция..pdf

Понятие Фреймворка иногда путают с понятием библиотеки. На самом деле эти понятия различны. Библиотека в отличие от Фреймворка может быть представлена в программном проекте в качестве набора подпрограммного проекта и не накладывает на нее никаких ограничений. Фреймворк же в свою очередь задает правила для построения архитектуры приложения, диктуя поведение по умолчанию уже на начальном этапе разработки. Он является каркасом, который нужно будет расширять и изменять согласно указанным требованиям. В качестве примера Фреймворка можно привести такие программные продукты как NET Framework или Entity Framework, а примером библиотеки можно считать модуль электронной почты. Также, в отличие от библиотеки, которая объединяет в себе набор близкой функциональности, Фреймворк может содержать в себе большое число разных по тематике библиотек.^[33]

Еще одним из ключевых отличий Фреймворка от библиотеки, считается инверсия управления: пользовательский код вызывает функции библиотеки (или классы) и получает управление после вызова. Во Фреймворке пользовательский код может реализовать конкретное поведение, встраиваемое в общий, абстрактный код Фреймворка. При этом Фреймворк вызывает функции (классы) пользовательского кода. Обычно Фреймворк определяется множеством каких – либо конкретных и абстрактных классов и определениями способов для их взаимодействия между собой.^[34] Конкретные классы реализуют взаимные отношения между классами. Абстрактные классы обычно являются некими точками расширения, где используются и адаптируются каркасы. Точка расширения – это та часть Фреймворка, для которой не приведена реализация. Процесс создания Фреймворка состоит в выборе подмножества задач какой – либо проблемы, а также их реализаций. В процессе реализаций общие средства решения заключаются в конкретных классах, а изменяемые средства выносятся в точки расширения.

2.2. Инструментальные средства проектирования

Исторически сложилось, что все браузеры, мобильные и десктопные, на всех платформах понимают всего лишь три вещи: HTML, CSS и JavaScript (не путать с Java.).Были попытки подружить браузеры с другими технологиями: Visual Basic, Java, ActiveX, — но все они провалились, потому что производители железа и браузеров не смогли договориться об открытых стандартах. Остались только открытые стандарты, разрабатываемые публичными консорциумами и рабочими группами. Например, W3C разрабатывает HTML и CSS.

Итак, у нас есть три технологии:

• HTML отвечает за структуру страницы.
• CSS — за ее оформление (визуальное и адаптив для разных экранов).
• JavaScript — за взаимодействие страницы с пользователем (по изначальной задумке; сейчас-то уже практически вообще за все).

Каждая технология развивается независимо, у каждой есть несколько версий. Самые свежие на сегодня версии: HTML5,CSS3, ECMAS cript 2018 (это стандарт Java Script). Браузеры тоже развиваются независимо. Кто-то (то Internet Explorer, то Safari) отстает от стандартов, кто-то (обычно Chrome или Firefox) впереди и внедряет экспериментальные фичи.

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

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

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

Чтобы проиллюстрировать пример неэффективности всей этой связки, возьмем такую простую конструкцию, как таблица. В HTML есть набор тегов для создания таблицы (основные из них — table, th, tr, td). С их помощью можно создать только сетку таблицы с минимальными настройками внешнего вида: задать ширину колонок, размеры ячеек и в принципе всё. Добавив CSS, можно (изрядно помучавшись) придать ей пристойный вид и при должном старании адаптировать для разных экранов. Но мы все равно не сможем сортировать таблицу по одной или нескольким колонкам, показать порядок сортировки, добавлять или удалять колонки и столбцы, перетаскивать данные из одной ячейки в другую, использовать формулы для подсчета сумм по строкам и столбцам, применить условное форматирование ячеек (подсветить отрицательные, например) и т. п.

Всё это на HTML и CSS невозможно сделать, потому что в HTML нет такого объекта, как таблица, и нет методов работы с ней, которые поддерживались бы любым браузером. Разработчики стандарта 20 лет назад не предполагали, что пользователи захотят работать с содержимым веб-страницы. Похожие проблемы у нас будут, если мы захотим отправить на сайт пачку файлов (например, добавить несколько вложений к письму в веб-почте), выбрать интервал времени (например, запланировать встречу в календаре) или представлять одну и ту же информацию разными способами (например, показывать товары в Интернет -магазине по желанию пользователя карточками или строками). Для всего этого в HTML и CSS нет подходящих решений, потому на помощь приходит JavaScript — язык программирования, который может манипулировать объектами в структуре HTML и применять к ним стили CSS.

Каждый раз писать код на JavaScript, чтобы сделать ту же сортировку таблиц, — это, разумеется, не легкая задача. И появились библиотеки — наборы готовых функций на JavaScript, выполняющие типовые операции с HTML-кодом страницы. Пример такой библиотеки — jQuery. Этих библиотек за двадцать с лишним лет существования JavaScript появилось великое множество. Программистам приходилось комбинировать библиотеки, дружить их между собой, обновлять (ведь каждая развивается своим чередом), следить за совместимостью. Да еще самим код писать — не все же есть в библиотеках. Подход с библиотеками до сих пор живет. В небольших проектах достаточно подключить одну - две библиотеки для конкретных улучшений. Например, чтобы рисовать красивые графики, подключаем бесплатный Chart.js или платный AmCharts. Если нужна анимация и отзывчивость интерфейса — тот же jQuery, для работы с элементами интерфейса есть смысл взглянуть на Sencha Ext JS и т. п.

Для HTML+CSS тоже стали появляться подобные «полуфабрикаты» — заготовки из кусков кода, которые решают типовые проблемы верстки. Например, многоколоночная верстка, закрепленный на странице хедер или футер и прочие типовые задачи, которые выгоднее решить один раз, а потом применять в новых проектах.

Так появились первые фронтенд - каркасы разработки, или Фреймворки. Почему они не библиотеки? Потому что это не набор готовых функций, которые можно добавить к проекту и использовать точечно на отдельных страницах. Каркас (Фреймворк) предполагает, что весь проект будет следовать заданной им структуре.^[35] То есть он задает ограничения, которых нужно придерживаться, чтобы ускорить разработку, точнее следовать стандартам, снизить порог вхождения разработчиков в проект и т. п.

Самый известный образец HTML+CSS - Фреймворка — Bootstrap (вот примеры, вот один из компонентов — карусель, вот другой — кнопки). Важно, что все сделано на стандартных HTML и CSS и будет работать (и работать более или менее одинаково) во всех браузерах. Фреймворки уже содержат подогнанные друг к другу совместимые библиотеки, так что разработчику не нужно ничего обновлять, помнить про ограничения и заботиться о совместимости. Так, многие компоненты Bootstrap содержат код на JavaScript с использованием библиотеки jQuery.

Другой известный Фреймворк, Foundation, кроме jQuery использует библиотеки Modernizr и FastClick. Два Фреймворка в приложении будут конкурировать за базовые вещи. К примеру, один захочет 12-колоночную сетку, другой — 16-колоночную; они могут использовать одинаковые названия методов JavaScript для разных целей и т. д. Поэтому между собой Фреймворки не совместимы: нужно определиться и выбрать один. Если у вас проект на Bootstrap, а вам нужны вот такие вот звездочки из Foundation — то «поженить» их не получится. Главная проблема современного веба — разрозненность технологического стека. Невозможно выучить все технологии, знать и уметь их правильно готовить.

Пять лет назад появилась вполне здравая идея — поскольку большинство сайтов и мобильных приложений оперируют ограниченным набором шаблонов, разумно отделить представление данных от собственно данных.^[36] Пусть бэкенд занимается только хранением, обработкой и безопасностью данных (извлекает их из хранилища, проверяет наличие прав доступа, передает их на Фронтенд), а всё остальное поручим клиенту (браузеру). Дадим ему пачку данных и шаблон — набор инструкций по превращению данных в верстку. Фреймворк на клиенте будет подставлять данные в шаблон, реализовывать бизнес-логику и вообще манипулировать страницей, наводить красоту и т. п.

Такие Фреймворки называются реактивными, потому что в них состояние интерфейса автоматически реагирует на изменение данных. Если сказать «вот эта переменная управляет цветом вон той кнопки», а потом поменять переменную — цвет кнопки изменится сам, перекрашивать ее вручную не надо. Реактивное программирование  — вариант многопоточного, при котором вместо системы «запрос — ожидание ответа — получение ответа — обработка» работает принцип «запрос (послали и забыли) — ответ — обработка ответа».^[37] Примеры: React, Angular, Vue и еще десятки менее известных. Итак, на бэкенде можно использовать любой язык программирования, добывать им данные, упаковывать их в JSON, XML или что угодно другое машинно-читаемое и отдавать на фронт. А на фронтенде JS-Фреймворк делает всю чистовую работу: рисует контролы, анимирует их, проверяет данные, представляет их в соответствии с локальными настройками пользователя и реализует бизнес-логику.

Что касается надстроек: JS - Фреймворки сразу же обросли библиотеками GUI-компонентов, или надстройками, которые решают конкретные вопросы отзывчивого и богатого GUI в рамках конкретного Фреймворка. Примеров множество: KendoUI — набор UI-компонент для jQuery, React, Angular и Vue, ReactStrap — Bootstrap для React,ReactNative — GUI Фреймворк от "Фейсбука" и т. д. Некоторые надстройки реализованы для нескольких Фреймворков, Onsen, например, или тот же KendoUI.

2.3. Проектирование Фреймворка на примере приложения

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

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

примере этого приложения.

Так как в качестве среды разработки выбрана платформа .NET Framework, именование всех проектов, классов, интерфейсов, методов и других различных структур будет вестись в соответствии с общими соглашениями об именовании .NET. Данный подход упростит процесс ознакомления и изучения для будущих разработчиков, собирающихся использовать Фреймворк для построения распределенной ИС. Структура приложения Bookstore, на примере которого происходит описание Фреймворка, представлена на Рисунке 13.

Рисунок 13. Структура приложения на Bookstore

2.4. Проектирование базы данных.

Как уже упоминалось, первичной технологией доступа к данным послужил Entity Framework, а системой управления базами данных – Microsoft SQL Server. В качестве главного подход был выбран Code First. С помощью данного подхода, разработчику не обязательно создавать базу данных вручную, а она проектируется из модели автоматически при написании кода. Для генерации БД, требуется указать строку подключения с такими параметрами: