ПРЕИМУЩЕСТВА ИСПОЛЬЗОВАНИЯ ПРИНЦИПОВ АРХИТЕКТУРЫ ПРИ РАЗРАБОТКЕ ПРОГРАММНОГО ПРОДУКТА ДЛЯ МОНИТОРИНГА СТАТУСА ПРОЕКТОВ

АННОТАЦИЯ

Главное требование нынешней IT – индустрии - быстрая и качественная разработка, способная своевременно решать задачи. Для достижения такого результата требуется понимать и применять общие принципы программирования для построения успешной архитектуры.

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

На данный момент большое множество популярных используемых паттернов, созданные для решения различных проблем, и делятся на целые ряды групп принципов работы. В данной статье рассматривается паттерны проектирования, архитектурные принципы приложений, которые применяются в ходе разработки. В настоящей работе был применен подход комплексных приложений с N-слойной архитектурой.

Ключевые слова: проектирование веб-продуктов, шаблоны проектирования, архитектурные принципы, ООП, CRUD.

Введение

При выборе проектирования и построения архитектуры, необходимо учитывать текущие версии продкутов, удобство их сопровождения и расширениу.

В данной статье рассмотрим общие архитектуры продуктов в .NET, то они делятся на многослойные и монолитные приложения. Самым непрактичной архитектурой является монолитная. Если описать данную архитектуру в двух словах, то его основа и весь функционал находится в одном проекте, но имеется возможность использовать иные службы или хранилища, но все приложение публикуется как один элемент. Также применение данной архитектуры является крайне нежелательным в случаях расширения функционала приложения или как было отмечено ранее, если потребуется разработка такого же приложения на другую платформу (мобильное, настольное приложения). В таком случае будет затрачено гораздо больше временных ресурсов. Но следуя основым принципам ООП, такие как “Разделение задач”, “Инкапсуляция” и “Не повторяйся” лучшим решением будет использовать многослойную архитектуры, где каждый слой содержит свой функционал. Самым главнымы преимуществами данной архитектуры является удобство чтения самими разработчиками, возможность установить связи только между теми слоями, который требует данный слой и уменьшение повторяющегося кода.

Стандартными слоями подобных продуктов являются слои пользовательского интерфейса (UI), бизнес логики (Business Logic) и слой доступа к данным (Data Access Level) и абстрактных объектов (Abstractions).

Разделение задач

Один из важнейших принципов ООП. Он подразумевает собой разделение продукта на компоненты учитывая требуемый функционал. Важным советом является разделения пользовательского интерфейса и логики проекта (рисунок 1). В данной статье рассматривается реализации бизнес логики с использованием Базового интерфейсы для CRUD операций (IRepo<TEntity>), базового репозитория (BaseRepo<T>) наследующий все методы с базового интерфейса и базового абстрактного контроллера (BaseController<TEntity, TViewModel, TRepo>) (рисунок 2).

Рисунок 1. Архитектура продукта

Рисунок 2. Абстрактные классы

Это один из популярных шаблонов проектирования. Шаблон позволяет абстрагироваться от конкретных подключений к источникам данных, с которыми работает приложение, и является промежуточным звеном между классами, непосредственно взаимодействующими с данными и основным проектом. Также данный паттерн реализует бизнес-логику (в нашем случае технология LINQ to SQL). В классе содержатся методы, способный принять любую сущность. Далее проходит проверка совместимости типа поля с типом столбца таблицы. Здесь реализованы методы транзакции объектов между приложением и базой данных. Методы выполняют функции добавления новых объектов, изменение и удаление уже существующих из БД.го интерфейса. Проект реализующий бизнес логику работает на .NET 6. Клиентское приложение содержит сервисы отправляющие запросы к API, которые использует зависимости с бизнес логикой и слоем доступа к данным. Проекты “Data” и “Models” реализуют задачу уровня доступа к данным. “Data” содержит в себе контекст базы данных и  требуемые миграции с данным для создания и чтения базы данных (рисунок 3). Слой “Models” хранит классы-модели. Данные модели являются объектами данных, отражающие структуру таблицы в базе данных.

Рисунок 3. Слой “Data”

Инкапсуляция

Инкапсуляция отдельных частей приложения позволяет изолировать их друг от друга.  Правильно реализованная инкапсуляция способна получить низко связанную структура продукта, т.к. пакеты NuGet и сущности можно заменить любым слоем, при условии, что используются те же пакеты и интерфейсы [1]. В данном случат слой “Data” зависит от “Models”, но слой “Models” полностью независим и внесение корректировок никак не носят рисков.

Не повторяйся

Для предотвращения дублировония логики приложения, ее следует инкапсулировать в конструкции программирования. Данная конструкция должна быть единственным исполнителем нужного поведения и использоваться в любых других частях приложения в тех случаях, когда требуется реализовать это поведение [1]. Не следует связывать поведение, которое повторяется нерегулярно. В рассматриваемом проекте созданы базовые классы и интерфейсы, позволяющие задать стандарт кодов для всего решения. Класс “BaseController” позволяет предотвратить написание идентичного кода для CRUD операций (рисунок 4). Методы класса “BaseRepo” наследуются от базового интерфейса “IRepo” (рисунок 5). Данные методы принимают любую сущность и производят транзакции, что позволяет отправить нужный класс сущности в наследуемых от “BaseController” контроллерах без повторной реализации под определенную ситуацию (рисунок 6).

Рисунок 4. Абстрактный базовый контроллер

Рисунок 5. Базовый интерфейс

Рисунок 6. Базовый репозиторий

Заключение

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

Список литературы:

1. Steve S. Architect Modern Web Applications with ASP.NET Core and Azure. 2022 – 119 с.