Критерии выбора средств разработки WEB-приложений (CMS 5)
Содержание:
Введение
Современные реале просто наполнены информационными технологиями, с каждым годом всё больше внедряясь и проникая почти во все сферы человечества! Без них в наше время не обойтись. IT несёт в себе огромное количество профилей, отраслей, разновидностей, классификаций и других распределений. Как и во всём в нашей жизни, в ИТ есть большой выбор средств разработки, которые путём анализированною двух сторон, а также познанию всех нюансов того или иного контингента, необходимо выбрать оптимальный вариант. Как вы уже поняли, мы сейчас будем разбираться в таком профиле, как web-приложения (web-application), чтобы познать все особенности и нюансы этого дела от А до Я.
И для начала давайте разберёмся что-же это такое web-приложение. Его ещё называют клиент-серверным приложением, его основная часть находится на удалённом или локальном сервере, а пользовательский интерфейс отображается в браузере web-страницей. И для его запуска в большинстве случаев не нужно устанавливать никаких дополнительных программ и расширений, оно запускается почти на любом устройстве с браузером и доступом в интернет либо к локальному хосту. В большинстве случаев работа клиента совместима с любой операционной системой и её модификации, поэтому при разработке не стоит писать отдельные версии для разных OS. Исключением лишь может служить полная и мобильная версия приложения. Для создания клиентской части используются языки программирования такие, как: HTML, CSS, JavaScript, Ajax. А вот для создания серверной части используются такие языки программирования: PHP, ASP, ASP.NET, Perl, C/C++, Java, Python, Ruby, NodeJS, как мы видим их список более объёмный.
Глава №1. CMS
Аббревиатура CMS переводится с английского (Content management system) система управления контентом, содержимым. Является совокупной информационной системой и используется для обеспечения полного или частичного управления содержимым, контентом web-страницы.
В системе управления может хранится о обрабатываться виды данных, такие как: текстовая, числовая, графическая, звуковая, видео.
CMS как и многое другое ПО обладает определённой своей версией.
На данный момент существует достаточно большое количество «семейств» систем управления web-контентом. Вот самые популярные из них в России: WordPress, Joomla, 1С-Битрикс, UMI-CMS, OpenCart и так далее.
В данной работе возьмём за пример WordPress (
), так как я считаю её выбор – самым оптимальным вариантом по множеству на то причин.
Рассмотри такую утилиту как система управления web-содержимым (WCMS) (рис.1). Она-то как раз и позволяет управлять наполнением страниц сайта и представляет собой специальную форму. А также через неё можно редактировать исходный код элементов сайта: HTML, PHP, CSS, JS.
Система управления контентом (CMS) также обладает множеством различных функций, настроек, плагинов и других элементов, необходимых для стабильной работы системы.
Так чем же CMS WordPress лучше других движков?
Система управления сайтом WordPress, наверное, является самой популярной в мире, не спроста же на ней работает более 60 миллионов сайтов в сети интернет. Основные причины, взывающий такой ажиотаж среди других движков: ↓
Основа WordPress является бесплатной, в отличии от той же 1С, что даёт её большой плюс и причина, которая делает её самой популярной на рынке. Конечно за исключением платных плагинов, шаблонов и других дополнений.
Так же под эту систему разработано множество плагинов, позволяющие защитить ваш сайт от несанкционированного доступа, вредоносного программного обеспеченья и других различных видов атак. Так же существует готовое решение для настройки SSL (https) сертификата.
Как я уже упоминал ранее, WordPress также обладает огромным количеством готовых шаблонов, плагинов и виджетов. Причём как платных, так и бесплатных решений.
WordPress полностью оптимизирован почти под все виды мобильных устройств, работающие на разных операционных системах. Самые популярные из которых являются Android и IOS.
В панели управления WordPress присутствует огромное количество пунктов различных настроек, с которыми можно идеально подстроить сайт под себя. Например, загрузить мультимедийный контент, пользуясь интерфейсом (drag-and-drop), или же создавать галереи изображений, настраивать расписания для публикации постов в определенное время суток и добавлять крутые виджеты для разнообразия боковой панели (рис. 2). И все это без единого вмешательства в исходный код.
Этот движок гораздо мощнее, чем вы представляете! На нём можно строить различные виды сайтов, начиная от простого сайта визитки и заканчивая какой ни будь социальной сетью. Кстати многие крупные бренды используют WordPress в качестве движка сайта по выше перечисленным на то причинам.
Ещё одно большое преимущество - это полностью открытый исходный код движка. Что даёт ему почти полностью безграничные возможности, результат зависит лишь от возможностей и желания разработчика. Ну есть и обратная сторона этого пункта, к которой мы вернёмся чуть позднее.
Ну тут заголовок говорит сам за себя. WordPress хорошо подходит для таких новичков, как я, в профиле web-разработки.
При прохождении пути разработки сложной системы любого типа невозможно избежать попадания «подводных камней». На некоторые из проблем можно найти готовое решение в интернете, достаточно просто обозначить в поисковой системе (например, Google) симптом вызванной проблемы или код ошибки.
Как было сказано ранее WordPress обладает очень большой популярностью среди выбора средств разработки web-сайтов, соответственно хост-провайдеры стараются подстроиться под этот движок используя готовые стандарты, такие как PHP, MySQL.
С положительной стороной движка мы уже разобрались, теперь давайте посмотрим на обратную сторону движка WordPress. Ведь при выборе средств разработки web-приложений, как уже было упомянуто в начале: «путём анализированною двух сторон, а также познанию всех нюансов того или иного контингента, необходимо выбрать оптимальный вариант». Скажу заранее: по сравнению с плюсами у него не так уж и критичны отрицательные нюансы, под некоторые из которых можно даже подстроится опытному специалисту (web-разработчику).
Даже при формировании простого сайта визитки на всем известном движке WordPress возникает ощутимая нагрузка на host-машину, из-за которой очевидно и падает скорость работы сервера.
Так, как у WordPress отсутствует официальная техническая поддержка клиентов из-за бесплатной основы, приходится пользоваться неофициальными соответствующими (порой платными) сервисами и форумами при неизбежном возникновении технических проблем на стадии разработки или обновлении своей платформы.
Вернёмся к этой теме. Открытый исходный код обладает так же отрицательной стороной, так-как система является более уязвимой к всевозможным хакерским атакам. Из-за которого злоумышленникам легче находить уязвимости и слабые места CMS.
Для полной работы WordPress необходимо хоть минимальное количество необходимых на то плагинов, работа которых в свою очередь и даёт нагрузку на сервер.
WordPress всё же уступает по функционалу тому же 1С-Битрикс, возможности и количество которого недостаточно для создания например интернет магазина. При желании можно конечно его нанизать, модифицировать движок под проект, что также приведёт к большой нагрузки на сервер.
Вот мы и узнали все «+» и «-» системы управления контентом на примере WordPress, которая кстати, как уже говорилось неоднократно, имеет большой прецедент при выборе соответствующего движка. Без которого никак не обойтись! Не будите же вы делать сайт на HTML как это было популярно в годах так 90-х, ведь для его разработки и дальнейшего обновления нужны советующие знания программирования, да и про функциональность такого ресурса говорить не о чем. Ещё как вариант сделать свою самописную CMS. Для этого необходимо как минимум владеть HTML и PHP. Согласитесь, навряд ли получится даже у большой группы её разработчиков сделать функциональность даже близко к готовым решениям, тем более это очень затратное дело, если нанимать специалиста в данной области. В большинстве случаев более оптимально сделать модификацию, например, той же WordPress или Joomla.
Глава №2. Классификация web-сайта
Многое зависит от того, какой вид сайта вам необходим, опираясь на вашу деятельность. Вот основные из которых:
- Сайт-визитка
Содержит главную информацию о компании и предоставляемых ею товаров и услуг. Содержит приблизительно 5 страниц.
- Сайт-галерея
Является тем же сайтом-визиткой, отличие лишь в наличие плагина фотогалереи.
- Сайт-витрина
Всё та же разновидность сайта-визитки, но уже со встроенным каталогом товаров или услуг.
- Промо-сайт
Перевод с английского (promo) – рекламный. Необходим, соответственно, для рекламы определённой деятельности. Служит функцией презентации.
- Интернет магазин
Это сайт-витрина, но с множеством функцией, таких как: онлайн оплата, виртуальная корзина, личный кабинет пользователя, возможность отслеживания статуса пребывания заказанных товаров, а также возможность выдачи различных промо кодов или купонов, да обладанием и многого другого по функционалу.
- Корпоративный сайт
Не стоит путать его с сайтом-визиткой или с другой похожей классификации сайта. Является порталом компании, который содержит в себе статьи, новости, каталоги, прайс-листы, вакансии.
- Blog / Vlog
Web-сайт, обладающей соответствующей лентой, в которую постоянно добавляют различные статьи или новости. P.S. Blog – текстовая информация, vlog – видео.
- Форум
Необходим для общения людей на определённую из выбранных в списке тем либо же открыв новую. Темы может закрывать администрация форума.
- Социальная сеть
Онлайн платформа, используется для общения, а также для создания социальных отношений с другими пользователями.
- Landing Page
По-другому – целевая или посадочная страница. Одностраничный сайт со специальной формой для заявки. При этом длина страницы может быть, как относительно небольшой, так и достаточно длинной.
- Multi Landing
Является динамическим Land Page, обладает такими механизмами, которые автоматически предоставляют определённые данные, известные о пользователе. Если конечно у системы будет возможность их правильно выявить.
Определившись с классификацией web-сайта, необходимо спроектировать и продумать всевозможные нюансы, необходимые для дальнейшей его разработки. После чего можно приступать к созданию web-сервера на localhost, установленный непосредственно на вашем персональном компьютере.
Глава №3. Хостинг сервер
Далее нам необходимо разобраться в выборе хостинга, как локального (localhost), так и постоянного (для получения доступа к проекту из вне).
Для начала разберём что же такое локальный хостинг и зачем он нужен на этапах разработки и обновления проекта.
Значение аббревиатуры localhost выражается в компьютерных сетях как: стандартное, официально зарезервированное доменное имя для частных ip-адресов. Можно так сказать, что, посылая запрос к локальному хосту вы обращаетесь к этому же самому компьютеру, на котором сейчас и ведёте работу. Наверняка вам ранее попадались такие понятия, как localhost и 127.0.0.1, значение работы которых описан выше. А вообще localhost является альтернативным способом для обращения к локальному ip по DNS 127.0.0.1
Диапазон ip адресов локальных сетей: 127.0.0.1 - 127.255.255.255
Вот примерно так переводится с технического языка это понятие localhost. Теперь же мы переходим к выбору подходящего ПО для создания своей локальной сети. А именно к программе под названием Open Server Panel (рис.3,4).
Чем хорошо, что эта программа полностью совместима начиная с версией операционной системы Windows 7 и выше, а также частично имея поддержку Windows XP и Vista.
Вот ещё ряд возможностей, которым обладает Open Server:
- Относительно быстрый запуск и остановка сервера
- Возможность поставить в настройках автозапуск сервера при открытии программы, которую также поставить на автозапуск при запуске Windows
- Поддержка нескольких проектов одновременно
- Можно менять такие модули, как HTTP, MySQL, PHP
- Поддержка интерфейса нескольких языков
…и многих других её преимуществ, как достаточно глобальных, так и по мелочи.
А вот недостатков у программы не так уж и много, и лично для меня не доставляют каких-либо проблем. Вот основные из которых:
- Возможет старт сервера только от имени учётной записи администратора.
- Отсутствует функция авто обновления, приходится в ручном режиме её переустанавливать и переносить проекты на новую версию программы.
После того как наш проект полностью готов необходимо позаботится о его переносе во всемирную паутину. Так, как установка своего домашнего хост-сервера, работа которого кстати может происходить через тот же Open Server (только подключена к домену и имеет доступ из сети интернет) не целесообразна, по таким причинам как: финансовый расход, стабильность работы, самостоятельная настройка и подключение различных функций сертификатов и других «танцев с бубном».
И для этого, очевидно, нам потребуется выбор уже готового хостинг провайдера, отвечающего по всем современным критерием нашего проекта. В интернете можно найти огромное количество хостингов, как работающие в России, так и находящиеся на территории, других стран, впрочем, существуют и международные, все те, которые согласны взять работу проекта на себя. Поэтому посоветовать тут определённый вариант достаточно трудно, мы лишь разберём необходимые, как уже говорилось ранее, их критерии, необходимые для успешной реализации своего проекта.
Для начала нужно сравнить критерии, поддержка которых необходима для работы нашего проекта, вот её основные примеры: PHP, MySQL, Perl, Python, совместимость популярных CMS. А также поддерживаемая скорость работы сервера (Mbps, Ping) и по возможности различные степени защиты от хакерских атак, такие как: ssl (https) сертификат, Anti-DDoS, к теме кибербезопасности мы ещё вернёмся в конце.
Глава №4. Домен
Что же такое доменное имя (адрес) web-сайта? Доменный адрес является уникальным идентификатором хоста, могут состоять из латинских букв и арабских цифр. Домены обладают своими определёнными уровнями, разделяются на первый (верхний, родовой), второй и третий уровень (субдомен, поддомен). Считывание домена идёт с лева на право.
Домен самого верхнего уровня имеет отметку «точка» и является нулевым.
Домены верхнего уровня ещё так называемые доменные зоны. Которые разделены на такие группа как: международные, национальные, новые верхнего уровня. Вот пример распространённых доменов первого уровня –
Международные: .com .net .pro .info .club .tv .name .xyz .biz .gov и т.д.
Россия: .ru .rus .рф .su .mos и т.д.
Украина: .ua и т.д.
На домены первого уровня идёт регистрация доменов второго уровня. Именно они распространены и используются в коммерческих целях. Как пример доменами второго уровня являются сайты google.com, yandex.com, synergy.ru, megacampus.ru.
А на домены второго уровня можно регистрировать домены третьего уровня, их ещё называют субдоменами и поддоменами. К домену третьего уровня относятся такие домены, как gmail.google.com и my.megacampus.ru. Так же возможны домены четвёртого уровня и более.
Помимо того существуют так называемые IDN-домены, которые состоят из символов национальных языков. IDN работает через систему кодирования под названием Punycode, потому что DNS работает только через латинский язык. Например, зарегистрированный домен Университет.рф будет выглядеть на латинице, как xn--c1adicwtd2j.xn--p1ai. Все IDN-домены имеют префикс xn--, а в имени IDN домена доступно использования только тех символов, которые принадлежат алфавиту выбранного вами языка. Как же это всё работает в адресной строке браузера, спросите вы. А всё очень просто, при указании в адресной строке IDN- домена браузер в автоматическом режиме его преобразует в Punycode (функция, встроенная почти в любой более-менее современный браузер) и соответственно открывается вызванная страница.
Определённые ограничения при регистрации IDM:
- Имя, состоящее из символов разных алфавитов
- Использование символов из неподдерживаемого алфавита
- Использование символов алфавитов, которые не входят в алфавит указанного при регистрации языка домена
- В таких доменах, например, как .tel .org запрещается регистрировать доменные имена, идентичными занятыми доменными именами, но на другом языке
Глава №5. OS хостинг сервера
Что не менее важно, это определится с какой операционной системой «на борту» выбирать хост провайдер. Или какую OS ставить на свой домашний сервер. Что же на самом деле лучше и оптимальнее для нас Windows или Linux (Unix).
Начнём с графического интерфейса, в Windows Server он почти такой же, как и на обычной (десктопной, пользовательской) версии, которая знакома почти каждому из нас. Но в техническом плане тут далеко не так всё просто! Windows Server технически сложная ось, которая хоть и поддерживает большой набор функций, но вариативность (разнообразие, варианты) например простого сайта-визитки достаточно высока. Дело в том, что по сравнению с Linux различных готовых материалов и документаций достаточно мало. Есть много чего неэффективного и устаревшего, либо упрощённого, или вообще, например, платного контента на эту тему.
К тому же Windows Server наверное самая ресурсоёмкая операционная система. Что означает, часть, возможно большую (зависит от ресурсов хост-машины), VDS необходимо будет освободить для системных процессов. Тем более не стоит забывать, что лицензия, как и в обычной версии является платной (про пиратскую я не говорю), что не есть хорошо, если в подсчёт идёт каждый рубль.
- 5.2 Linux
В народе считается, что Linux и его разновидности, например, Ubuntu или FreeBSD, выбирают достаточно опытные системные администраторы и web-разработчики, обладающие навыками настройки сервера в консоли в ручном режиме без такового графического интерфейса. Но этот минус легко решить, просто установив специальную на то панель управления, например, cPanel или OpenPanel.
Как я уже указывал Linux является общим названием Unix подобных операционных систем, они имеют свои определённые особенности и отличия. Поэтому среди их разновидностей тоже необходимо выбрать подходящий вам вариант. В основном идёт выбор по требованиям CMS (система управления содержимым), либо же смотря на технические требования web-сайта к программным обеспечениям и их необходимым версиям. Нужно изучить требования web-проекта и сверится с таблицей версий ядра и ПО системы. Пример (рис. 5). Также, если не удалось обнаружить в списки нужную версию ядра, то это можно исправить, найдя решение на тематическом ресурсе, ведь Linux системы очень гибкие в настройке. И наверняка можно исправить таким способом, как установка дополнительных версий PHP через панель управления, если конечно в ней присутствует такая возможность. Помимо во многих панелей управления присутствует возможность переносить сои проекты между разными OS Linux, но при условии, что у них у обоих будет установлена панель управления.
Глава №6. Характеристики web-приложений
Современные web-приложения пользователи стараются использовать, так сказать, по полной мере. Они должны быть доступны 24/7 из любой точки мира, где очевидно есть доступ в интернет, а также быть совместимым с любым устройством и операционной системы. Web-приложения должны быть безопасными и гибкими, а также масштабируемыми, чтобы быть устойчивыми к резким скачкам нагрузки. Полнофункциональные пользовательские интерфейсы делают все более сложные схемы с поддержкой клиентов на базе JavaScript и обеспечивают эффективное взаимодействие через интерфейс WEB-API. Платформа ASP.NET Core хорошо оптимизирована для современных web-приложений и сценариев размещения в облаке. При помощи её модульной структуры приложения используют только те компоненты, которые им необходимы по факту, что позволяет повысить их безопасность и производительность при одновременном снижении требований к ресурсам размещения.
"Закон Атвуда: любое приложение, которое можно написать на JavaScript, в конечном итоге будет написано на JavaScript".- Джефф Атвуд (Jeff Atwood)
- 6.1 eShopOnWeb (справочное приложение)
Справочное приложение eShopOnWeb на его примере демонстрируются определённые принципы и рекомендации. Это приложение может представлять собой, например, простой интернет-магазин, в котором можно просматривать различные товары. Справочное приложение намеренно упрощено для наилучшего понимания.
Платформа ASP.NET Core оптимизирована для сценариев размещения в облаке, в основном, как частное, общедоступное или другое, обеспечивая низкое потребление памяти при высокой пропускной способности. Тем самым из-за минимальной потребности приложений ASP.NET Core в ресурсах вы имеете возможность размещать в облаке больше приложений при меньших затратах в плане модели оплаты по мере использования. Высокая пропускная способность позволяет обслуживать в приложении большее количество клиентов при тех же затратах аппаратных ресурсов, благодаря чему сокращается расходы, в финансовом плане, в серверы и инфраструктуру размещения.
Пакеты с названием NuGet часто используются в .NET Core, а вот в самих приложениях ASP.NET Core используется большое количество предоставляемых NuGet библиотек. Такая вид упрощения функций позволяет приложениям использовать и развертывать только те функции, которые им необходимы по факту, благодаря чему сокращается объем потребляемых ими ресурсов и размер так называемой контактной зоны, в которой присутствуют уязвимости. Платформа ASP.NET Core тоже полностью поддерживает внедрение зависимостей на внутреннем уровне и на уровне приложения. Интерфейсы могут иметь множество реализаций, переключение между которыми осуществляется при необходимости. Внесение зависимостей позволяет реализовать слабое связывание приложений с такими интерфейсами вместо конкретных реализаций, с помощью этого упрощается их расширение, обслуживание и тестирование.
При помощи кроссплатформенной поддержке ASP.NET Core может выполняться в операционных системах Linux, macOS и Windows, что даёт разработчикам приложений ASP.NET Core множество различных возможностей для разработки и развертывания. Контейнеры Docker на Linux и Windows могут использоваться для размещения приложений ASP.NET Core, это позволяет им использовать преимущества контейнеров и микрослужб.
Приложения ASP.NET Core являются слабо связанными, а также поддерживают модульное тестирование и внедрение зависимостей, с помощью чего упрощается подход к переключению инфраструктур и созданию сторонних реализаций для тестирования. В состав платформы ASP.NET Core ещё входит компонент TestServer, его можно использовать для размещения приложений в памяти. Функциональные тесты могут выполнять запросы к этому размещаемому в памяти серверу, используя полный стек приложения и получая ответы, в том числе программное обеспечение промежуточного слоя, маршрутизацию, привязку модели фильтры и т. д. Все это выполняется за минимальное время, которое затрачивается при размещении приложения на реальном сервере и выполнении запросов через сетевой уровень. Эти тесты для API просты в разработке и очень нужны, что соответственно играет все более важную роль для современных web-приложений.
- 6.6 Поддержка поведения традиционных и одностраничных приложений
В традиционных web-приложениях находится лишь малая часть функций на стороне клиента и размещаются все возможности навигации, обработки запросов и обновления на сервере. Каждая выполняемая пользователем новая операция должна преобразовываться в web-запрос, что ведёт за собой полную перезагрузку страницы в браузере конечного пользователя. Такой подход в основном применяется на классических платформах MVC и переводится эта аббревиатура, как модель-представление-контроллер, где каждый новый запрос соответствует новому действию контроллера, который, в свою очередь, работает с моделью и возвращает представление. Отдельные операции на конкретной странице могут быть оптимизированы с использованием функций AJAX, расшифровка которого, асинхронный JavaScript и XML, хотя общая архитектура приложения использует множество различных представлений MVC и конечных точек URL-адресов. Мало того, ASP.NET Core MVC также поддерживает Razor Pages — более простой способ организации страниц в стиле MVC. В отличие от которых, одностраничные приложения используют минимум динамически создаваемых на стороне сервера загрузок страниц или не используют их вообще. В основном одностраничные приложения инициализируются с использованием статического HTML-файла, который загружает необходимые для запуска и выполнения приложения библиотеки JavaScript. Такие приложения могут активно использовать WEB-API для обработки данных и реализовывать гораздо более функциональный пользовательский интерфейс.
Во многих приложениях эффективно сочетаются возможности традиционного, в основном для работы с содержимым, и одностраничного, для реализации интерактивного поведения, web-приложения. Платформа ASP.NET Core также обеспечивает одновременную поддержку MVC, представления или страницы, и WEB-API в одном приложении с использованием единого набора средств и базовых библиотек платформы.
Приложения на фреймворке ASP.NET Core можно создавать как с использованием простых текстовых редакторов и интерфейсов командной строки, так и с помощью полнофункциональных сред разработки, например, Visual Studio. Одноуровневые приложения в большинстве случаев развертываются в одной конечной точке. Есть возможность легко автоматизировать развертывание в рамках конвейера непрерывной интеграции и непрерывной поставки. В дополнение к традиционным средствам непрерывной интеграции и непрерывной поставки в Microsoft Azure предусмотрена уже встроенная поддержка репозиториев Git и автоматическое развертывание обновлений для указанных ветвей или тегов Git. Azure DevOps предоставляет полнофункциональный конвейер сборки и развертывания CI/CD, а вот GitHub Actions предоставляет сторонний вариант для размещенных в нём проектов.
Традиционная платформа ASP.NET 4.x делает дополнения возможностей ASP.NET Core и служит надежным и эффективным инструментом для построения web-приложений. Платформа ASP.NET поддерживает модели разработки MVC и WEB-API, а также web-формы, с помощью чего она отлично подходит для разработки полнофункциональных приложений на основе страниц и реализует развернутую экосистему сторонних компонентов. Платформа Microsoft Azure хорошо знакома многим разработчикам и на протяжении многих лет обеспечивает поддержку приложений ASP.NET 4.x.
Blazor входит в состав компонента ASP.NET Core начиная с версии 3.0, он предоставляет новый механизм для создания многофункциональных интерактивных клиентских web-приложений с помощью ASP.NET Core, Razor и C#. И предлагает еще одно решение, на которое стоит обратить внимание при разработке современных web-приложений. Существует две версии Blazor: на стороне клиента и сервера. Функция Blazor на стороне клиента выпущена уже в 2020 году (на момент написания темы) и будет устранять необходимость в отрисовке изменений на сервере. А вместо этого, для запуска кода .NET в клиенте, функция будет использовать WebAssembly. Клиент как обычно сможет выполнять вызовы API на сервер, если необходимо запросить данные, но все поведение на стороне пользователя выполняется в клиенте через WebAssembly, которая уже поддерживается почти всеми распространёнными браузерами и является простой библиотекой JavaScript. Blazor на стороне сервера выпущена чуть ранее в 2019 году с ASP.NET Core 3.0. Как следует из названия, функция работает на сервере, преобразуя изменения в клиентском документе для отображения в браузер по сети и обеспечивает широкие возможности для взаимодействия с пользователем, не требуя наличия JavaScript на стороне клиента и отдельной загрузки страниц для каждого взаимодействия с клиентской страницей. Изменения на загруженной странице запрашиваются и обрабатываются сервером, а затем отправляются обратно клиенту через SignalR.
Глава №7. Web-архитектура
Также нам для правильного понимания сути работы необходимо изучить общие архитектуры WEB-приложений.
Большая часть традиционных приложений (.net) развёрнута в виде единственного элемента, который соответствует исполняемому файлу или же одного web-приложения, выполняющего в домене приложений служб IIS. Является простой моделью развёртывания, она оптимально подходит для большего количества внутренних и также небольших общедоступных web-приложений. Но всё же даже такая простая модель развёртывания в которой большая часть бизнес-приложений вынуждена использовать преимущество логического разделения на слои.
"Если вы считаете хорошую архитектуру слишком дорогой, попробуйте использовать плохую".— Брайан Фут (Brian Foote) и Джозеф Йодер (Joseph Yoder)
- 7.1 Монолитное приложение
Полностью замкнутое в плане контекста поведения. В процессе работы оно конечно может совместно взаимодействовать с другими службами или базами данных, но основа его поведения реализуется в своём собственном процессе, а все другие приложения обычно развёртываются как будто в один элемент. Для горизонтального масштабирования подобное приложение как правило дублируется на нескольких серверах или локальных хостах одновременно.
Архитектура приложения которого содержит минимум один проект. В этом случае вся логистика приложения находится только в одном проекте и компилируется в одну сборку, соответственно развёртываясь в один элемент. Всякий формируемый в Visual Studio или же из командной строки план ASP.NET Core в начале станет представлять собой полный монолитный проект. В нем станет заключено все поведение приложения, охватывая и включая презентацию данных, бизнес-логику и логику доступа к сведениям. В сценарии с одним проектом деление задач реализуется с поддержкой папок. Применяемый по умолчанию шаблон подключает отдельные папки для обязательств шаблона MVC (модели, представления и контроллеры), а еще вспомогательные папки для данных и служб. При подобной организации подробности демонстрации данных в очень максимально вероятной степени находятся в папке представлений (Views), а подробности реализации доступа к сведениям обязаны быть ограничены классами, содержащимися в папке данных (Data). Бизнес-логика при данном располагается в службах и классах, оказавшихся в папке моделей (Models).
Не обращая внимания на собственную простоту, монолитное решение с одним планом содержит конкретные дефекты и недостатки. По мере наращивания объема и трудности плана будет соответственно вырастать количество файлов и папок. Задачки, связанные с пользовательским интерфейсом (модели, представления, контроллеры), находятся в различных папках, которые не упорядочены по алфавиту. С добавлением в отдельные папки систем значения пользовательского интерфейса, к примеру фильтров, или же связанных моделей, обстановка лишь только усугубляется. Бизнес-логика затеривается в папках моделей (Models) и служб (Services), в итоге чего нельзя внятно квалифицировать, какие классы в каких папках обязаны находиться в зависимости от иных классов. Аналогичный неэффективный способ на уровне плана нередко приводит к получению плохого структурированного кода. И для заключения аналогичных задач приложения нередко организуются в виде решений, состоящих из большого количества проектов, где любой этот проект располагается в отдельном слое приложения.
Это когда по мере увеличения трудностей приложения для действенного управления им имеет возможность использоваться разбиение по задачам и обязательствам. Данный подход имеет соответствие с принципом разделения задач, а также помогает сохранить организацию увеличивающего базы кода, благодаря этому разработчики имеют возможность определить, где именно находятся те или иные функции. Многослойная архитектура обладает большим количеством других своих преимуществ. Надо сказать, спасибо упорядочению кода с поддержкой слоев совместные низкоуровневые функции, которые имеют возможность многократно применяться по всему приложению. Это принципиально важно, причём в высшей степени, потому что подобный расклад настоятельно требует наименьшего объёма кода и, за счет стандартизации приложения на уровне одной реализации, соответствует такому принципу, как «Не повторяйся». Приложения с мультислойной архитектурой имеют все шансы устанавливаться соответствующие ограничения на взаимодействие меж слоями. Так получается воплотить в жизнь инкапсуляцию. При изменении или же подмене слоя станут затронуты лишь только те слои, которые работают непосредственно именно с ним. Когда вы ограничиваете зависимости слоев друг от друга, то можете убавить последствия внесения обновлений, в итоге чего одиночное изменение не станет воздействовать на всё приложение. Использование слоев (инкапсуляция) разрешает заметно облегчить подмену функциональных возможностей в приделах приложения. К примеру, приложение имеет возможность в начале применить базу данных SQL Server для сохранности, а после чего перейти на стратегию хранения состояния на базе облачного или же WEB-API. В случае если в приложении правильным образом инкапсулирована осуществление сохранности на логическом слое, этот слой SQL Server имеет возможность быть заменен новым, где будет реализован тот же начальный интерфейс. Кроме возможности подмены реализации в связи с дальнейшими изменениями, использование слоев в приложении еще позволяет заменять реализации в целях испытания (тестирования). Взамен написания соответствующих тестов, которые используются к слоям существующих данных или же пользовательского интерфейса приложения, во время испытания они заменяются фиктивными реализациями, которые показывают известную нам реакцию на требования. В основном это сильно упрощает написание и ускоряет выполнение тестов, если сравнить с испытанием в реальной инфраструктуре приложения. Деление на логические слои обширно распространено и хорошо помогает упорядочить код приложений. Сделать это представляется возможным несколькими методами. Слои обеспечивают логическую степень деления в приложении. В случае если логика приложения на физическом уровне распределена между несколькими серверами или же процессами, эти раздельные физиологические мотивированные объекты развертывания имеют названия - уровни. Этим самым, не только вполне вероятно, но и обширно распространено развертывание N-слойных приложений на одном уровне.
В большинстве случаев в приложении ориентируются слои пользовательского интерфейса, а также бизнес-логики и доступа к данным. В правилах подобный архитектуры юзеры (пользователи) выполняют запросы через слой пользовательского интерфейса, он же ведет взаимодействие лишь только со слоем бизнес-логики. А слой бизнес-логики имеет возможность вызывать слой доступа к данным для обработки запросов. Сам же слой пользовательского интерфейса не может исполнять требования напрямую к слою доступа к сведениям и какими-либо другими методами напрямую вести взаимодействие с сохраняемыми функциями. Подобным образом, слой бизнес-логики должен вести взаимодействие с сохраняемыми функциями лишь только через этот слой доступа к данным. Таким образом, для всякого слоя внятно определена своя функция. Одним из минусов обычного многослойного подхода считается, собственно, что обработка зависимостей во время компиляции исполняется по принципу верх → низ, что означает, собственно, что слой пользовательского интерфейса находится в зависимости от слоя бизнес-логики, который, в собственную очередь, находится в зависимости от слоя доступа к сведениям. Это означает, слой бизнес-логики, который как правило имеет главные функции приложения, находится в зависимости от подробностей реализации доступа к данным, даже часто от присутствия самой базы данных. Тест работы бизнес-логики в подобной архитектуре нередко затруднено и настоятельно просит присутствия самой испытательной базы данных. Для решения сложившейся проблемы имеет возможность использоваться принцип инверсии зависимостей. Даже не обращая внимания на то, что в целях упорядочения в данном приложении применяется определённое количество проектов, оно всё равно развертывается как единственный элемент, и его пользователи ведут взаимодействие с ним как с одним web-приложением, что позволяет воплотить в высшей степени простой процесс развертывания. Соответственно, чему, по мере разработки приложения могут понадобится более надёжные и конечно сложные решения для этого развёртывания.
Разделение сего проекта на некоторое количество проектов на базе обязательств позволяет увеличить удобность техподдержки приложения. Подобный элемент имеет поддержку вертикального и горизонтального масштабирования, собственно, что позволяет преимуществовать облаку масштабирования по запросу. Вертикальное масштабирование имеется в виду наращивание количества центрального процессора, размера памяти, пространства на диске и иных ресурсов на серверах, где располагается сам проект. Горизонтальное масштабирование имеет понимание в добавлении дополнительных элементов физических серверов, таких, как виртуальных машин или же контейнеров. В случае если приложение располагается на нескольких элементах, для разделения запросов меж элементами приложения применяется система балансировки нагрузки. Самый простой способ к масштабированию web-приложения в программе Azure заключается в ручной настройке масштабирования в проекте службы, так сказать, приложений для приложения.
Это приложения, которые используют принципы инверсии зависимости и проблемно-ориентированного проектирования и обладающие схожей архитектурой. Долгое время она меняла своё название, по началу называвшись шестигранной архитектурой, далее архитектурой портов и адаптеров, сейчас же она называется чистой или многослойной архитектурой, но более подходящее ей название всё же является «чистая архитектура». Например, эталонное (абстрактное) приложение под названием eShopOnWeb использует свой подход на основе чистой архитектуры для того, чтобы организовать код в соответствующий проект. В приделах этой чистой архитектуры ядром приложения значится его модель и бизнес-логика. В данном случае бизнес-логика не имеет зависимость от доступа к данным либо другим инфраструктурам. Проще говоря стандартная зависимость имеет инвестирование, соответственно, чему инфраструктура и детали реализации имеют зависимость от ядра этого приложения. Оно достигается с помощью определения абстракций или интерфейсов в ядре, они же реализуются формами, которые указаны в слое инфраструктуры. Она графически обозначается путём серий окружностей, имеющие общий центр, лично мне он внешне напомнил срез луковицы. Стоит обратить внимание, что на этой схеме зависимости направленны из внутренней окружности. Именно поэтому ядро приложения им и является, что находится в центре схемы. Также ядро приложения не имеет зависимостей от других слоёв этого приложения. А интерфейсы и так сказать сущности (тип объекта) приложения находятся в центре. После них (в пределах ядра) находятся доменные службы, которые в основном реализуют интерфейсы, они же определены во внутренней окружности. А вот за пределами ядра находятся слои пользовательского интерфейса и инфраструктуры, они же зависят напрямую от ядра приложения, и не могут иметь зависимость друг от друга. В понятиях чистой архитектуры слой пользовательского интерфейса работает напрямую с внутренними интерфейсами, они же находятся в ядре приложения во время компиляции, и по-хорошему слой не должен иметь доступ к типам реализации, находящихся в слои инфраструктуры, но всё же при выполнении, когда эти виды реализации просто необходимы для исполнения приложения, потому они должны работать и иметь привязку к интерфейсам ядра через внедрение зависимостей. Так, как ядро никак не зависит от инфраструктуры, для такого слоя очень просто написать автоматические модульные тесты. Поскольку слои пользовательского интерфейса не имеет прямых зависимостей видов, которые определены в проекте инфраструктуры, будет соответственно просто изменять реализации в случаях изменения требований к приложению, либо просто его тестированию. Кроссплатформенный фреймворк ASP.NET Core имеет возможность встроенной поддержки внедрения зависимостей, поэтому подобная архитектура представляет собой более оптимальный подход к структурированию технически сложных монолитных приложений. Инфраструктуры пользовательского интерфейса выполняются как единое целое приложения, для таких элементов, как: монолитных приложений, проекты ядра приложений, а также пользовательского интерфейса и инфраструктуры.
В решении, которого через значение чистой архитектуры для каждого проекта определены свои обязанности. По факту каждому из которых проекту будут принадлежать определённые типы, в самих же проектах представлены соответствующие типам папки. Само ядро приложения содержит, так называемую бизнес-модель, в ней же находятся службы, интерфейсы, сущности. Подобные интерфейсы содержат в себе абстракции для операций, которые должны выполнятся при помощи архитектуры, задействовав операции доступа к файловой системе или данным и другого. Иногда бывает службы или интерфейсы, находящиеся в этом слое, работают с типами, которые не являются типами сущностей, они не зависят от инфраструктуры либо пользовательского интерфейса, но могут определятся простыми объектами передачи данных.
Существует класс Startup, который в ответе за настройку приложений, а также типы реализации в интерфейс, соответственно обеспечивая плавную работу внедрения зависимостей при выполнении процесса. Для того, чтобы сделать привязку внедрения зависимостей ConfigureServices в файл Startup.cs пользовательского интерфейса может потребоваться ссылка на проект инфраструктуры.
И вот основные их типы:
- Контроллер
- Представление
- Модель представлений
- Фильтр
- Запуск
7.8 Ядро приложения (типы)
И его проект инфраструктуры, в большинстве случаев, включает функцию реализации доступа к данным. Типовое web-приложение, в котором ASP.NET Core включает элемент Entity Framework (EF) DbContext, другие объекты Migration EF Core и классы реализации доступа к данным. В основном используется такой подход абстрагированию кода реализации данных, как конструктивный шаблон репозитории. А также проект инфраструктуры должен обладать реализации служб, они же должны взаимодействовать с инфраструктурными задачами. Данные службы реализуют определённые интерфейсы в ядре приложения, тем самым инфраструктура должна содержать в себе ссылку на проект ядра приложения.
И вот основные их виды:
- Служба
- Интерфейс
- Сущность
- Объект передачи данных
7.9 Монолитные приложения и контейнеры
С помощью которых возможно создать одно монолитное web-приложение, либо службу и сделать их как контейнер. Монолитность может не соблюдаться в приделах приложения, но будет реализована организация на основе определённого числа библиотек, слоёв или компонентов. Внешне оно будет представляться, как единый контейнер: единое web-приложение, единый процесс, либо единую службу. Развёртывается один контейнер для управления этой моделью, который представляет собой приложение. Для того, чтобы управлять этой моделью, необходимо просто добавить дополнительные копии, обладающие подсистемой балансировки нагрузки. Управление одним развёртыванием в одном контейнере или виртуальной машине намного легче. Обратная отрицательная сторона этого подхода является очевидным, когда это приложение разрастается и его нужно масштабировать, но если это делать целиком, то всё будет удачно. Проблема заключается в том, что в большинстве случаев нужно масштабировать лишь определённые его части, когда другие компоненты исправно работают. Как пример можно взять приложение для электронной торговли, для которого, наверное, понадобится масштабирование компонента со сведениями о его товарах. Также ещё реже оставляют положительные отзывы о компании (про отрицательные всё понятно) и смотрят историю покупок. Клиенты гораздо чаще просто смотрят товары, иногда складывая в корзину, но не покупают их. Скорее всего у вас работают всего несколько сотрудников в одном регионе (городе, селе, посёлке, районе), управляющие содержимым и маркетинговыми компаниями. Когда вы масштабируете монолитное решение, исходных код полностью развёртывается многократно. Мало того, что нужно масштабировать все его компоненты, так ещё при изменении в одном компоненте необходимо проводить полный тест работы всего приложения на выявления ошибок, и полного развёртывания всех экземпляров. Монолитный подход приобрёл широкое распространение при разработке архитектуры и используется многими компаниями. В большинстве случаев позволяя достичь желаемых результатов, но бывает компания сталкивается с определёнными ограничениями. Ранее в большинстве случаев приложения строились по этой модели, ибо в прошлом с помощью уже существующих инструментов инфраструктуры было очень сложно создавать архитектуры, направленные на службы SOA, проблем тогда не возникало до поры, когда приложение начинало разрастаться. Если вы столкнулись с этой проблемой ограничений монолитного подхода, то её решением будет разбиение приложения для эффективного использования микрослужб и контейнеров. В программе Microsoft Azure монолитные приложения возможно развёртывать с помощью нескольких выделенных виртуальных машин для каждого экземпляра. При помощи масштабируемых наборов виртуальных машин Azure имеется возможность с лёгкостью масштабировать виртуальные машины, также могут выполнять монолитный приложения службами приложений Azure и также легко масштабировать экземпляры, чтобы не пришлось управлять вириальными машинами. Службы приложений Azure могут ещё выполнять отдельные экземпляры контейнеров под названием Docker, тем самым упрощая развёртывание. При помощи Docker можно одну виртуальную машину на его узле и соответственно выполнять на ней несколько экземпляров. А для того, чтобы управлять масштабированием, можно использовать систему балансировки под названием Azure. Для того, чтобы управлять развёртыванием на тех или иных узлах, управление идёт с помощью традиционных методов развёртывания. Узлы Docker с помощью которых можно управлять через вводимых команд вручную вида docker run либо автоматически. Как пример ввод автоматических команд при помощи конвейеров непрерывной поставки со значением CD.
Контейнеры, использующиеся для управления развертываниями монолитных приложений, обладают определёнными преимуществами, например, масштабировать экземпляры контейнера намного быстрее и легче, чем развертывать дополнительные виртуальные машины. При использовании масштабируемых наборов виртуальных машин применяется основанный на экземплярах подход, а при развертывании в виде экземпляров приложения управление конфигурацией приложения осуществляется в составе виртуальной машины. Развертывание обновлений в виде образов Docker выполняется в разы быстрее и эффективнее в плане использования сети. Образы Docker как правило запускаются за считанные секунды, что позволяет ускорить выпуск, а вот остановить образ Docker можно с помощью команды docker stop, в большинстве случаев это происходит моментально. Так, как контейнеры являются неизменяемыми элементами, вам не нужно будет беспокоиться о возможности повреждения виртуальной машины. Бывает, когда скрипты обновления не учитывают те или иные оставшиеся на диске файлы или конфигурации.
Контейнеры Docker имеют возможность использования для монолитного развертывания простых web-приложений, что оптимизирует процессы непрерывной интеграции и непрерывного развертывания, а ещё помогает добиться успешного развертывания в рабочей среде. Поэтому больше не придется «плясать с бубном» и думать, почему решение, выполняющееся на компьютере, не может выполнится в рабочей среде. Архитектура на базе микрослужб обладает большим количеством преимуществ, но с другой стороны «медали» придётся столкнуться с повышением сложности. Бывает, когда затраты перевешивают преимущества, и лучше выбрать монолитное развертывание приложения в одном контейнере или нескольких.
Монолитное приложение бывает непросто разделить на отдельные микрослужбы, потому что микрослужбы работают независимо друг от друга для повышения отказоустойчивости приложения. Например, если приложение не представляется возможным разложить на независимые функциональные составляющие, то попытка его разделения только увеличит сложность работы. Приложение пока что не может исправно работать без независимого масштабирования компонентов. Многие приложения, когда им необходимо взять в использование более одного экземпляра, они достаточно легко клонируют весь экземпляр. Ещё одна работа по разделению приложений на отдельные службы предоставляет малое число преимуществ, а вот масштабирование полноценных экземпляров приложения является простым и экономичным решением. На ранних стадиях развертывания приложения может отсутствовать ясное понятие, где находятся границы меж функциональными областями. Во время разработки проекта, который обладает самым небольшим необходимым набором возможностей, его естественное разделение на две и более части может быть неправильным, часть из этих условий может быть временным. Можно сначала создать монолитное приложение, а потом отделить некоторые компоненты для разработки и развертывания в качестве микрослужб. Другие условия могут быть необходимыми особенностями приложения для его работы, это означает, что приложение в общем то невозможно разделить на несколько микрослужб, разделение приложения на множество отдельных процессов также приводит к соответствующим проблемам. Если разделить компонент на несколько процессов также будет повышаться сложность, ещё усложняться протоколы обмена данными. Вместо того, чтобы просто сделать вызовы методов, необходимо использовать асинхронное взаимодействие между службами. Когда вы переходите на архитектуру микрослужб необходимо добавить множество стандартных блоков, реализованных в версии приложения eShopOnContainers на основе микрослужб, а точнее: отказоустойчивость и повторную отправку сообщений, обработку шины событий, итоговую согласованность и так далее. Намного проще привести пример приложения eShopOnWeb, которое поддерживает использование одного монолитного контейнера, тогда включается одно web-приложение с традиционными представлениями MVC, web-API и Razor Pages. Оно (приложение) может запускаться из корня решения с помощью команд docker-compose build и docker-compose up. Эта команда делает насройку контейнера для web-экземпляра при помощи Dockerfile из корневого каталога web-проекта, а ещё выполняет контейнер в указанном порте. Можно скачать исходный код этого приложения, например, с популярного ресурса под названием GitHub и запустить его в локальной системе. Подобное монолитное приложение имеет преимущество от развертывания в контейнерной среде. Начнём с того, что контейнерное развертывание значит: каждый экземпляр приложения выполняется в одной и той же среде, оно относится и к среде разработки, в которой, кстати, проводятся начальные этапы разработки и дальнейшего тестирования. Разработчик имеет возможность запускать приложение в контейнерной среде, которая аналогична рабочей. Помимо того, контейнерные приложения обеспечивают более экономное горизонтальное масштабирование. Контейнерная среда помогает эффективнее организовывать общее использование ресурсов, нежели традиционные среды виртуальных машин. В-третьих, когда вы помещаете приложение в контейнеры, вы тем самым разделяете бизнес-логику и сервер хранилища. В процессе масштабирования приложения все контейнеры будут использовать один физический носитель данных. В большинстве случаев в качестве хранилища, используется сервер высокой доступности с базой данных под названием SQL Server.
Так называемый проект eShopOnWeb работает в .NET Core, благодаря чему можно его запустить как в контейнерах на базе Linux, так соответственно и на Windows. И да, для развёртывания Docker нужно использовать тот же вид узла для SQL Server. Опять же вернёмся к сравнению Linux и Windows, а точнее говоря для контейнеров на базе Linux требуется меньше ресурсов, и они лучше по другим пораметрам. Можно использовать Visual Studio 2017, для добавления поддержки Docker в существующие приложение, нажав проект в обозревателе решений правой кнопкой мыши и выбрав Добавить → Поддержка Docker, этим самым добавив необходимые файлы и внести изменения в проект для их использования. На данном примере eShopOnWeb эти файлы присутствуют: например, файл docker-compose.yml ссылается на Dockerfile в проекте web. При помощи Dockerfile можно указать, какой базовый контейнер будет использоваться и как приложение будет настроено на нем. А вот файл docker-compose.yml содержит такие сведения: какие образы нужно создать и какие контейнеры запустить. Этот файл позволяет использовать команду docker-compose для того, чтобы запустить несколько приложений одновременно. В таком случае он запускает сам web-проект. Также имеется возможность с его помощью настроить зависимости, как пример отдельный контейнер базы данных.
После запуска контейнерное приложение продолжает работать, пока его самостоятельно не остановят. Команда docker ps необходима, чтобы посмотреть, какие контейнеры выполняются. Можно остановить выполняющийся контейнер командой docker stop и ID самого контейнера. Запущенные контейнеры Docker могут иметь привязку к портам, которые в противном случае вы могли бы использовать в среде разработки. Если попытаться сделать запуск или выполнить отладку приложения через порт, связанный с контейнером Docker, вылетит ошибка с сообщением о том, что сервер не может выполнить привязку к этому порту, решение этой проблемы очень простое, необходимо всего лишь остановить контейнер. Если вам нужно добавить поддержку Docker в приложение при помощи Visual Studio, удостоверьтесь, что Docker Desktop работает. Если вдруг при запуске мастера средство Docker Desktop не выполняется, мастер будет работать неисправно, к тому же, мастер проверяет выбранные контейнеры, чтобы правильно реализовать поддержку Docker. Для того чтобы добавить поддержку контейнеров OS Windows, при запуске мастера должно быть запущено средство Docker Desktop с настроенными контейнерами Windows. Дабы добавить поддержку контейнеров Linux, при запуске мастера должно выполняться средство Docker с настроенными контейнерами OS Linux.
По мере развития сети, связанные с ней технологии и структуры, развиваются совместно. Разработка современных web-приложений заменила старые устаревшие структуры и базовые компоненты, поэтому при создании приложения необходимо выбрать правильную архитектуру, которая будет определять производительность web-приложения. Важные параметры зависят от выбора архитектуры - скорости web-приложения, надежного и безопасного характера и способа реагирования. Деловые потребности решения должны рассматриваться в контексте технических потребностей и наоборот. Правильная архитектура web-приложений прокладывает путь для будущих планов расширения и масштабируемости с помощью так называемого интеллектуального проекта. Расширение в будущем - это не просто увеличение спроса, а неизбежное включение в него таких требований, как функциональная совместимость и необходимость повышения надежности.
Глава №8 (Информационная безопасность)
Тут много расписывать не будем, а пройдём лишь поверхностно, чтобы понять суть темы. Начнём с того, что информационная безопасность web-приложений является актуальной уже сколько лет! Ранее годах так в 2000 для обеспечения защиты необходимо было всего лишь правильно настроить web-сервер, а также очищать сайт от лишних участков кода, ненужных файлов и необходимость минимального контроля со стороны разработчика, а действия пользователей предсказывались всего несколькими сценариями. В то время каналы были слабыми, по сравнению с современными, уязвимостей тогда было мало из-за простоты и примитивности приложений. DDoS не был широко распространён и поэтому редки были случаи атак на маленькие компании.
Со временем web-приложения развивались, и вместе с ним усложнялась серверная архитектура и её взаимодействие. Код становился всё более объёмным и соответственно более уязвимым. Web становился всё более популярным, за ним закреплялись возможности финансового роста, это конечно же привлекало желающих ̶с̶к̶о̶м̶у̶н̶и̶з̶д̶и̶т̶ь̶ скопировать чужие конфиденциальные данные или иным образом нанести ущерб работы системе и соответственно корпорации.
Вот основные виды угроз, направляемые на web-приложения, которых как вы видите всего два:
- Нарушение конфиденциальности информации
- Нарушение доступности информации
Во-первых, это затрагивает эксплуатацию системных уязвимостей, во-вторых атаки на отказ в обслуживание. Можно и нужно постараться убрать все уязвимости на стадии разработки приложения, в этом нам помогут такие инструменты, как: анализ кода, тестирование, отладки и другое. Но при размещении web-приложения в сети интернет, оно всё равно будет подвергаться хакерским атакам почти по всем направлениям. Это особенно касается, если у вас популярная компания или иная сфера деятельности. Да и честно говоря на любую защиту найдётся способ взлома, вопрос только в сложности и доступных возможностей для его удачного осуществления.
Вот распрастранённые виды атак на web-приложения:
- DoS / DDoS
- Инъекции (sql)
- XSS
- MITM
- Man-in-the-middle
- Брутфорс
- Различные вирусы, трояны, черви, снифферы (на устройство системного администратора или самого сервера, на котором расположен проект)
- IP-спуфинг
- Сетевая разведка
- Сниффинг пакетов
- Переполнение буфера
- Межсайтовый скриптинг
- Непроверенный переход и редирект (фишинг)
- Повреждение авторизации и управление сеансами
- Чувствительная экспозиция данных
И другие…
Существует множество способов защиты на все виды этих атак, в их число входят антивирусы, фаерволлы, фильтры и другое программное обеспеченье. Также причиной несанкционированного доступа может является человеческий фактор, так называемая социальная инженерия.
Заключение
Главный вывод, который можно выразить, заключается в том, что выбор средств разработки web-приложения напрямую зависит от того контента, который мы хотим вложить в разрабатываемое приложение, имеющегося системного и технического обеспечения для исправного функционирования web-приложения и, конечно, от опыта самого разработчика и схожесть получения с желаемых результатов. В этой работе были рассмотрены актуальные на 2020 год вопросы анализа для безошибочного выбора инструментов разработки web-приложений, а также значительные вопросы учета критериев выбора средств разработки web-приложения опираясь на отраслевые принадлежности этого приложения, потенциальной аудитории, а точнее пользователей web-приложения и его архитектуры.
Библиография
В библиографии:
1. Лубашева, Т.В. Основы алгоритмизации и программирования: учебное пособие: [12+] / Т.В. Лубашева, Б.А. Железко. – Минск: РИПО, 2016. – 378 с.: ил. – Режим доступа: по подписке. – URL: http://biblioclub.ru/index.php?page=book&id=463632 – Библиогр. в кн. – ISBN 978-985-503-625-9. – Текст: электронный.
2. Вагин, Д.В. Современные технологии разработки веб-приложений: учебное пособие: [16+] / Д.В. Вагин, Р.В. Петров; Новосибирский государственный технический университет. – Новосибирск: Новосибирский государственный технический университет, 2019. – 52 с.: ил. – Режим доступа: по подписке. – URL: http://biblioclub.ru/index.php?page=book&id=573960 – ISBN 978-5-7782-3939-5. – Текст: электронный.
3. Гениатулина, Е.В. CMS – системы управления контентом: учебное пособие / Е.В. Гениатулина; Новосибирский государственный технический университет. – Новосибирск: Новосибирский государственный технический университет, 2015. – 63 с.: ил. – Режим доступа: по подписке. – URL: http://biblioclub.ru/index.php?page=book&id=438332 – Библиогр. в кн. – ISBN 978-5-7782-2696-8. – Текст: электронный.
4. Артемов, А.В. Информационная безопасность: курс лекций / А.В. Артемов; Межрегиональная Академия безопасности и выживания. – Орел: Межрегиональная академия безопасности и выживания, 2014. – 257 с.: табл., схем. – Режим доступа: по подписке. – URL: http://biblioclub.ru/index.php?page=book&id=428605 – Текст: электронный.
5. Столбовский, Д.Н. Основы разработки Web-приложений на ASP.NET: учебное пособие / Д.Н. Столбовский; Национальный Открытый Университет "ИНТУИТ". – Москва: Интернет-Университет Информационных Технологий (ИНТУИТ): Бином. Лаборатория знаний, 2009. – 304 с. – (Основы информационных технологий). – Режим доступа: по подписке. – URL: http://biblioclub.ru/index.php?page=book&id=233488 – ISBN 978-5-94774-991-5. – Текст: электронный.
Постраничная сноска:
(Отсутствует в этой работе)
Рис. 1. Редактор страницы CMS WordPress
Рис. 2. Панель управления CMS WordPress
Рис. 3. Меню программы OpenServer
Рис. 4. Окно настроек OpenServer
Рис. 5. Таблица версий ядра и ПО системы
- Пенсия по старости на льготных основаниях (Трудовые пенсии в Российской Федерации)
- Юридическая ответственность (Юридическая ответственность – целостное правовое явление)
- Теории происхождения права (Понятие права и основные пути его возникновения)
- «Анализ внешней и внутренней среды организации» (Управление предприятием в условиях неопределенности внешней среды)
- Мерчандайзинг как система активного продвижения товаров к покупателю в организации коммерческой деятельности
- Цветопередача и сущность картины И.И. Щишкин «Полесский пейзаж»
- Финансы домашних хозяйств (Государственные социальные трансферты)
- Государственный кредит ( Государственный кредит и его значение.)
- Налоговая система Российской Федерации (Сущность налогов и их роль в экономике государства)
- «Анализ внешней и внутренней среды организации» (ПРИНЦИПЫ И МЕТОДЫ АНАЛИЗА ВНУТРЕННЕЙ СРЕДЫ ОРГАНИЗАЦИИ)
- Учет поступления основных средств (на примере ООО «P&G»)
- Защита сетевой инфраструктуры предприятия (Организационно-функциональная структура предприятия)