Файл: Критерии выбора средств разработки WEB-приложений (CMS 5).pdf

Приложения 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 в одном приложении с использованием единого набора средств и базовых библиотек платформы.

6.7 Простота разработки и развертывания

Приложения на фреймворке ASP.NET Core можно создавать как с использованием простых текстовых редакторов и интерфейсов командной строки, так и с помощью полнофункциональных сред разработки, например, Visual Studio. Одноуровневые приложения в большинстве случаев развертываются в одной конечной точке. Есть возможность легко автоматизировать развертывание в рамках конвейера непрерывной интеграции и непрерывной поставки. В дополнение к традиционным средствам непрерывной интеграции и непрерывной поставки в Microsoft Azure предусмотрена уже встроенная поддержка репозиториев Git и автоматическое развертывание обновлений для указанных ветвей или тегов Git. Azure DevOps предоставляет полнофункциональный конвейер сборки и развертывания CI/CD, а вот GitHub Actions предоставляет сторонний вариант для размещенных в нём проектов.

6.8 Традиционные модели ASP.NET и web-формы

Традиционная платформа ASP.NET 4.x делает дополнения возможностей ASP.NET Core и служит надежным и эффективным инструментом для построения web-приложений. Платформа ASP.NET поддерживает модели разработки MVC и WEB-API, а также web-формы, с помощью чего она отлично подходит для разработки полнофункциональных приложений на основе страниц и реализует развернутую экосистему сторонних компонентов. Платформа Microsoft Azure хорошо знакома многим разработчикам и на протяжении многих лет обеспечивает поддержку приложений ASP.NET 4.x.

6.9 Blazor инфраструктура

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 Монолитное приложение

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

7.2 Комплексные приложения

Архитектура приложения которого содержит минимум один проект. В этом случае вся логистика приложения находится только в одном проекте и компилируется в одну сборку, соответственно развёртываясь в один элемент. Всякий формируемый в Visual Studio или же из командной строки план ASP.NET Core в начале станет представлять собой полный монолитный проект. В нем станет заключено все поведение приложения, охватывая и включая презентацию данных, бизнес-логику и логику доступа к сведениям. В сценарии с одним проектом деление задач реализуется с поддержкой папок. Применяемый по умолчанию шаблон подключает отдельные папки для обязательств шаблона MVC (модели, представления и контроллеры), а еще вспомогательные папки для данных и служб. При подобной организации подробности демонстрации данных в очень максимально вероятной степени находятся в папке представлений (Views), а подробности реализации доступа к сведениям обязаны быть ограничены классами, содержащимися в папке данных (Data). Бизнес-логика при данном располагается в службах и классах, оказавшихся в папке моделей (Models).

Не обращая внимания на собственную простоту, монолитное решение с одним планом содержит конкретные дефекты и недостатки. По мере наращивания объема и трудности плана будет соответственно вырастать количество файлов и папок. Задачки, связанные с пользовательским интерфейсом (модели, представления, контроллеры), находятся в различных папках, которые не упорядочены по алфавиту. С добавлением в отдельные папки систем значения пользовательского интерфейса, к примеру фильтров, или же связанных моделей, обстановка лишь только усугубляется. Бизнес-логика затеривается в папках моделей (Models) и служб (Services), в итоге чего нельзя внятно квалифицировать, какие классы в каких папках обязаны находиться в зависимости от иных классов. Аналогичный неэффективный способ на уровне плана нередко приводит к получению плохого структурированного кода. И для заключения аналогичных задач приложения нередко организуются в виде решений, состоящих из большого количества проектов, где любой этот проект располагается в отдельном слое приложения.

7.3 Слои (представления)

Это когда по мере увеличения трудностей приложения для действенного управления им имеет возможность использоваться разбиение по задачам и обязательствам. Данный подход имеет соответствие с принципом разделения задач, а также помогает сохранить организацию увеличивающего базы кода, благодаря этому разработчики имеют возможность определить, где именно находятся те или иные функции. Многослойная архитектура обладает большим количеством других своих преимуществ. Надо сказать, спасибо упорядочению кода с поддержкой слоев совместные низкоуровневые функции, которые имеют возможность многократно применяться по всему приложению. Это принципиально важно, причём в высшей степени, потому что подобный расклад настоятельно требует наименьшего объёма кода и, за счет стандартизации приложения на уровне одной реализации, соответствует такому принципу, как «Не повторяйся». Приложения с мультислойной архитектурой имеют все шансы устанавливаться соответствующие ограничения на взаимодействие меж слоями. Так получается воплотить в жизнь инкапсуляцию. При изменении или же подмене слоя станут затронуты лишь только те слои, которые работают непосредственно именно с ним. Когда вы ограничиваете зависимости слоев друг от друга, то можете убавить последствия внесения обновлений, в итоге чего одиночное изменение не станет воздействовать на всё приложение. Использование слоев (инкапсуляция) разрешает заметно облегчить подмену функциональных возможностей в приделах приложения. К примеру, приложение имеет возможность в начале применить базу данных SQL Server для сохранности, а после чего перейти на стратегию хранения состояния на базе облачного или же WEB-API. В случае если в приложении правильным образом инкапсулирована осуществление сохранности на логическом слое, этот слой SQL Server имеет возможность быть заменен новым, где будет реализован тот же начальный интерфейс. Кроме возможности подмены реализации в связи с дальнейшими изменениями, использование слоев в приложении еще позволяет заменять реализации в целях испытания (тестирования). Взамен написания соответствующих тестов, которые используются к слоям существующих данных или же пользовательского интерфейса приложения, во время испытания они заменяются фиктивными реализациями, которые показывают известную нам реакцию на требования. В основном это сильно упрощает написание и ускоряет выполнение тестов, если сравнить с испытанием в реальной инфраструктуре приложения. Деление на логические слои обширно распространено и хорошо помогает упорядочить код приложений. Сделать это представляется возможным несколькими методами. Слои обеспечивают логическую степень деления в приложении. В случае если логика приложения на физическом уровне распределена между несколькими серверами или же процессами, эти раздельные физиологические мотивированные объекты развертывания имеют названия - уровни. Этим самым, не только вполне вероятно, но и обширно распространено развертывание N-слойных приложений на одном уровне.

7.4 Традиционные приложения, имеющие N-слойную архитектуру

В большинстве случаев в приложении ориентируются слои пользовательского интерфейса, а также бизнес-логики и доступа к данным. В правилах подобный архитектуры юзеры (пользователи) выполняют запросы через слой пользовательского интерфейса, он же ведет взаимодействие лишь только со слоем бизнес-логики. А слой бизнес-логики имеет возможность вызывать слой доступа к данным для обработки запросов. Сам же слой пользовательского интерфейса не может исполнять требования напрямую к слою доступа к сведениям и какими-либо другими методами напрямую вести взаимодействие с сохраняемыми функциями. Подобным образом, слой бизнес-логики должен вести взаимодействие с сохраняемыми функциями лишь только через этот слой доступа к данным. Таким образом, для всякого слоя внятно определена своя функция. Одним из минусов обычного многослойного подхода считается, собственно, что обработка зависимостей во время компиляции исполняется по принципу верх → низ, что означает, собственно, что слой пользовательского интерфейса находится в зависимости от слоя бизнес-логики, который, в собственную очередь, находится в зависимости от слоя доступа к сведениям. Это означает, слой бизнес-логики, который как правило имеет главные функции приложения, находится в зависимости от подробностей реализации доступа к данным, даже часто от присутствия самой базы данных. Тест работы бизнес-логики в подобной архитектуре нередко затруднено и настоятельно просит присутствия самой испытательной базы данных. Для решения сложившейся проблемы имеет возможность использоваться принцип инверсии зависимостей. Даже не обращая внимания на то, что в целях упорядочения в данном приложении применяется определённое количество проектов, оно всё равно развертывается как единственный элемент, и его пользователи ведут взаимодействие с ним как с одним web-приложением, что позволяет воплотить в высшей степени простой процесс развертывания. Соответственно, чему, по мере разработки приложения могут понадобится более надёжные и конечно сложные решения для этого развёртывания.

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