Селяков М.А.
ТРЕХУРОВНЕВАЯ АРХИТЕКТУРА МИКРОСЕРВИСА В ASP.NET *
Аннотация:
в статье рассмотрен трехуровневый подход при разработке микросервисов с использованием языка программирования C# и кроссплатформенной технологии .NET CORE
Ключевые слова:
.NET CORE, чистая архитектура, разработка программных средств, программная инженерия, микросервис, трехуровневая архитектура, веб разработка
Трехуровневая архитектура - это тип архитектуры программного обеспечения, который состоит из трех «уровней» логических вычислений. Они часто используются в приложениях как особый тип клиент-серверной системы. 3-уровневые архитектуры предоставляют множество преимуществ для сред производства и разработки за счет модульности пользовательского интерфейса, бизнес-логики и уровней хранения данных. Это дает большую гибкость командам разработчиков, позволяя им обновлять определенную часть приложения независимо от других частей. Эта дополнительная гибкость может улучшить общее время выхода на рынок и сократить время цикла разработки, предоставляя командам разработчиков возможность заменять или обновлять независимые уровни, не затрагивая другие части системы. Например, пользовательский интерфейс веб-приложения может быть переработан или модернизирован, не затрагивая основную функциональную бизнеслогику и логику доступа к данным. Эта архитектурная система часто идеально подходит для встраивания и интеграции стороннего программного обеспечения в существующее приложение. Эта гибкость интеграции также делает его идеальным для встраивания аналитического программного обеспечения в уже существующие приложения и по этой причине часто используется поставщиками встроенных аналитических средств. 3- уровневые архитектуры часто используются в облачных или локальных приложениях, а также в приложениях «программное обеспечение как услуга» В соответствии с вышенаписанным трехуровневая архитектура – не только способ логического размещения функционала приложения по 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, который позволяет покрыть классические потребности большинства бизнес-приложений. Если 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 – класс с определенной структурой.
Номер журнала Вестник науки №4 (25) том 1
Ссылка для цитирования:
Селяков М.А. ТРЕХУРОВНЕВАЯ АРХИТЕКТУРА МИКРОСЕРВИСА В ASP.NET // Вестник науки №4 (25) том 1. С. 76 - 80. 2020 г. ISSN 2712-8849 // Электронный ресурс: https://www.вестник-науки.рф/article/2966 (дата обращения: 24.04.2024 г.)
Вестник науки СМИ ЭЛ № ФС 77 - 84401 © 2020. 16+