CC BY
43УДК 1
Селяков М.А.
студент
Санкт-Петербургский государственный экономический университет
(Россия, г. Санкт-Петербург)
ТРЕХУРОВНЕВАЯ АРХИТЕКТУРА МИКРОСЕРВИСА В ASP.NET
Аннотация: в статье рассмотрен трехуровневый подход при разработке микросервисов с использованием языка программирования C# и кроссплатформенной технологии .NET CORE.
Ключевые слова: .NET CORE, чистая архитектура, разработка программных средств, программная инженерия, микросервис, трехуровневая архитектура, веб разработка.
Трехуровневая архитектура - это тип архитектуры программного обеспечения, который состоит из трех «уровней» логических вычислений. Они часто используются в приложениях как особый тип клиент-серверной системы. 3-уровневые архитектуры предоставляют множество преимуществ для сред производства и разработки за счет модульности пользовательского интерфейса, бизнес-логики и уровней хранения данных. Это дает большую гибкость командам разработчиков, позволяя им обновлять определенную часть приложения независимо от других частей. Эта дополнительная гибкость может улучшить общее время выхода на рынок и сократить время цикла разработки, предоставляя командам разработчиков возможность заменять или обновлять независимые уровни, не затрагивая другие части системы.
Например, пользовательский интерфейс веб-приложения может быть
переработан или модернизирован, не затрагивая основную функциональную бизнес-
логику и логику доступа к данным. Эта архитектурная система часто идеально подходит
для встраивания и интеграции стороннего программного обеспечения в существующее
приложение. Эта гибкость интеграции также делает его идеальным для встраивания
аналитического программного обеспечения в уже существующие приложения и по этой
причине часто используется поставщиками встроенных аналитических средств. 376
уровневые архитектуры часто используются в облачных или локальных приложениях,
а также в приложениях «программное обеспечение как услуга»
В соответствии с вышенаписанным трехуровневая архитектура - не только
способ логического размещения функционала приложения по 3 разным уровням, но и
подход, позволяющий легко масштабировать систему ввиду слабых зависимостей
между уровнями. Классический проект ASP.NET в соответствии с трехуровневый
архитектурой будет иметь основной проект ASP.NET - уровень представления, проекты
бизнес-логики, соответствующие уровню приложения и уровень данных в виде
отдельных проектов. Автор рекомендует создавать проекты для написания
интеграционных и юнит тестов, DI модуль, проект-контракт, если ваше API
используется каким-либо другим ресурсом внутри компании. В общие рекомендации
по использованию подхода автор рекомендует придерживаться общепринятых в
современном мире разработке принципов (SOLID, GoF, KISS)
Уровень представления - уровень представления является внешним уровнем в
3-уровневой системе и состоит из пользовательского интерфейса. Этот
пользовательский интерфейс часто является графическим, доступным через веб-
браузер или веб-приложение, и отображает контент и информацию, полезные для
конечного пользователя. Этот уровень часто основан на веб-технологиях, таких как
HTML5, JavaScript, CSS или других популярных средах веб-разработки, и
взаимодействует с другими уровнями посредством вызовов API.
В контексте применения такого подхода в технологии ASP.NET, уровень
представления - само приложение ASP.NET. Автор рекомендует определять
содержимое уровня следующим образом: DI регистрация всех компонент, которые
использует сервис (данных и приложения), маппинг моделей DTO в бизнес-модели,
валидаторы, контроллеры API и/или UI и набор визуальных компонент, если есть
необходимость. Автор предлагает использовать для маппинга моделей библиотеку
Джимми Богарда «AutoMapper», а при недостатке функционала встроенного DI
менеджера советует рассмотреть DI контейнер «AutoFac». При разработке API
рекомендуется использовать библиотеку Swagger для контроля корректности работы.
Самый частый подход написания API - REST, который позволяет покрыть классические
77
потребности большинства бизнес-приложений. Если REST подход не удовлетворяет всех требований к API в конкретной ситуации, автор рекомендует рассмотреть возможность использования GraphQL или (g)RPC подходов.
Уровень приложения. Уровень приложения содержит функциональную бизнес-логику, которая управляет основными возможностями приложения.
В уровни приложений рекомендуется размешать: валидаторы, бизнес-модели, их маппинг на модели уровня доступа данных и Gateway клиентов. Gateway клиенты -паттерн рекомендуемый автором для реализации взаимодействия с другими API, выделяемого в отдельный проект для каждого из ресурсов, класс регистрации всех необходимых сервисов и вспомогательных модулей в соответствии с DI библиотекой, которая была применена в уровне представления. Интерфейсы и их реализации стоит размещать в разных проектах для создания менее связанного кода, также в отдельный проект имеет смысл выносить бизнес-модели.
Уровень данных. Уровень данных состоит из технологии эксплуатации базы данных (ORM) и валидаторов, вспомогательных модулей. Автор рекомендует выделять модели хранения данных, интерфейсы и их реализации в разные проекты. Автор считает, что наилучшим способом написания слабосвязанного кода
Использование трехуровневой архитектуры имеет много преимуществ, включая скорость разработки, масштабируемость, производительность и доступность. Как уже упоминалось, модульность различных уровней приложения дает командам разработчиков возможность разрабатывать и совершенствовать продукт с большей скоростью, чем разработка единой базы кода, поскольку конкретный уровень может быть обновлен с минимальным воздействием на другие уровни. Это также может помочь повысить эффективность разработки, позволяя группам сосредоточиться на своей основной компетенции. У многих групп разработчиков есть отдельные разработчики, которые специализируются на фронтенде, серверной части и серверной разработке данных, благодаря модульности этих частей приложения вам больше не нужно полагаться на разработчиков полного стека, и они могут лучше использовать особенности каждого из них. команда.
Глоссарий
API (application programming interface) - любой способ взаимодействия одной программы с другой.
DI (dependency imjection) - один из принципов программирования SOLID
SOLID - свод правил и принципов объектно-ориентированного программирования, где каждая буква - принцип\правило.
KISS (keep it simple, stupid) - принцип программирования, зародившийся в 60-х годах 20 века, рекомендующий преследовать простоту при написании любых программ (например, функции не более 20 строк кода или для понимания происходящего в конкретной функции необходимо потратить не более 30 секунд)
GoF (gang of four) - подход в программировании направленный на создание кода таким образом, чтобы его можно было использовать повторно в других проектах.
RPC (remote procedure calling) - сокращение, подразумевающее удаленный вызов процедур\функций.
GraphQL - расширение технологии REST для приложений с множеством различных источников данных в серверной части.
REST - архитектурный подход к написанию приложений, взаимодействующих в распределенной сети.
Фронтенд - часть информационной системы, через которую пользователь взаимодействует с серверной частью.
DTO (data transfer object) - Объект для передачи данных, в контексте ASP.NET -класс с определенной структурой.
СПИСОК ЛИТЕРАТУРЫ:
Мартин Роберт. Чистая архитектура. Искусство разработки программного обеспечения. // Издание «Питер» 2018 г.
Эрик Фриман, Элизабет Фриман, Кэти Сиера, Берст Бейтс. Паттерны проектирования // Издание «Питер» 2011 г.
Троелсен Эндрю, Джепикс Филипп. Язык программирования C# 7 и платформы .NET и .NET Core // Издание «Вильямс» 2018 г.
