Телефон: 8-800-350-22-65
WhatsApp: 8-800-350-22-65
Telegram: sibac
Прием заявок круглосуточно
График работы офиса: с 9.00 до 18.00 Нск (5.00 - 14.00 Мск)

Статья опубликована в рамках: Научного журнала «Студенческий» № 19(189)

Рубрика журнала: Информационные технологии

Скачать книгу(-и): скачать журнал часть 1, скачать журнал часть 2, скачать журнал часть 3, скачать журнал часть 4, скачать журнал часть 5, скачать журнал часть 6, скачать журнал часть 7, скачать журнал часть 8, скачать журнал часть 9, скачать журнал часть 10, скачать журнал часть 11, скачать журнал часть 12, скачать журнал часть 13

Библиографическое описание:
Пермебек Е.Д. ОСОБЕННОСТИ ПРИМЕНЕНИЯ АРХИТЕКТУРНЫХ ПРИНЦИПОВ ПРИ РАЗРАБОТКЕ ВЕБ-ПРИЛОЖЕНИЯ УПРАВЛЕНИЯ ДАННЫМИ ОРГАНИЗАЦИИ // Студенческий: электрон. научн. журн. 2022. № 19(189). URL: https://sibac.info/journal/student/189/255169 (дата обращения: 29.03.2024).

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

Пермебек Ернур Дулатулы

студент, Казахский агротехнический университет им С. Сейфуллина,

Республика Казахстан, г. Нур-Султан

АННОТАЦИЯ

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

 

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

 

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

Если говорить про общие архитектуры приложений .NET, а в частности веб-приложений, они делятся на монолитные и многослойные приложения. Монолитные приложения представляют собой проект полностью замкнутый в контексте поведения. Во время работы оно может взаимодействовать с другими службами или хранилищами данных, все же основа его поведения реализуется в собственном процессе, а само приложение развертывается как единый элемент. Такие приложения при задаче горизонтального масштабирования требуют дублирования целиком приложения на нескольких серверах или виртуальных машинах, что является неоптимальным во многих планах. Это требует больше физических ресурсов. Также применение данной архитектуры является крайне нежелательным в случаях расширения функционала приложения или как было отмечено ранее, если потребуется разработка такого же приложения на другую платформу (мобильное, настольное приложения). В таком случае будет затрачено гораздо больше временных ресурсов.

Комплексные приложения содержат в себе минимум один проект. При наличии лишь одного проекта в приложении вся логика компилируется в одну сборку и развертывается как один элемент.

Однако если брать во внимание такие принципы как “Разделение задач”, “Не повторяйся” и “Инкапсуляция”, наиболее оптимальным и производительным решением будет использование комплексного многослойного приложения. Каждый слой выполняет свою обязанность и задачи. Это помогает сохранить организацию расширяющейся базы кода, что позволяет разработчикам быстро понимать, где конкретно реализованы функции приложения. Также данный тип архитектуры имеет целый ряд других преимуществ.

Так как код в момент завершения начальной разработки полностью упорядочен с помощью слоев, общие низкоуровневые функции могут многократно использоваться во всем приложении. Благодаря этому приложение содержит меньший объем кода, и из за стандартизации приложения на уровне реализации(применение базовых классов), соответствует уже другому принципу “Не повторяйся”.

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

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

Разделение задач. Данный принцип является основополагающим в разработке. Он подразумевает за собой разделение ПО на компоненты в соответствии с выполняемыми функциями.

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

 

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

 

В настоящей работе реализация бизнес-логики было произведено в отдельном проекте “BL” (рис. 2). Проект содержит класс “BaseRepo” и “BaseController”. Класс “BaseRepo” реализует шаблон проектирования “Репозиторий”. Это один из наиболее используемых шаблонов проектирования. Шаблон позволяет абстрагироваться от конкретных подключений к источникам данных, с которыми работает приложение, и является промежуточным звеном между классами, непосредственно взаимодействующими с данными и основным проектом. Также данный паттерн реализует бизнес-логику (в нашем случае технология LINQ to SQL). В данном классе содержатся методы, принимающие любой объект. Далее производится проверка совместимости типа поля/объекта с типом столбца/ряда таблицы. Здесь реализованы методы транзакции объектов между приложением и базой данных. Методы выполняют функции добавления новых объектов, изменение и удаление уже существующих из БД.

 

Рисунок 2. Проект BL

 

Проект “Admin” помещен в отдельную папку “Web” с другим веб-приложением (рис. 1). Оба проекта реализуют задачу пользовательского интерфейса. За основу проекта “Admin” взят фреймворк Angular вместе с Web API на платформе .NET 5.0. Данный проект использует зависимости проектов BL и Data. Клиентское приложение содержит сервисы отправляющие запросы к Web API, которая в свою очередь использует зависимости с бизнес логикой и слоем доступа к данным.

Проекты “Data” и “Models” реализуют задачу уровня доступа к данным. “Data” содержит в себе контекс БД и все миграции с изменениями в таблицах БД (рис. 3). “Models” содержит в себе классы-модели. Данные модели являются сущностями данных, отражающие структуру таблицы в базе данных.

 

Рисунок 3. Проекты Dataи Models

 

Инкапсуляция. Инкапсуляция отдельных частей приложения позволяет изолировать их друг от друга. Корректировка внутренней реализации компонентов и слоев приложения должна быть возможна без влияния на участников совместной работы при условии, что при этом не нарушаются внешние контракты. Правильно реализованная инкапсуляция позволяет получить слабо связанную модульную структуру приложения, поскольку объекты и пакеты можно с легкостью заменять альтернативными реализациями, если при этом сохраняется один и тот же интерфейс [1].

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

Проект “BL” зависим от слоя уровня доступа данных, однако вносимые изменения в проектах уровня доступа данных никаким образом не влияют на данный проект.

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

Вместо того чтобы дублировать логику, ее следует инкапсулировать в конструкции программирования. Такая конструкция должна быть единственным исполнителем нужного поведения и использоваться в любых других частях приложения в тех случаях, когда требуется реализовать это поведение [1]. Однако не стоит связывать поведение, которое повторяется нерегулярно.

В настоящем проекте разработаны базовые классы, позволяющие задать стандартизацию кода для всего приложения. Благодаря классу “BaseController” контроллеры пользовательского интерфейса не нуждаются в повторении кода (рис. 5). Методы класса “BaseRepo” принимают любой объект и производят транзакции с ними, что позволяет лишь подставить нужный класс модели в наследуемых от “BaseController” контроллерах без повторной реализации под определенную ситуацию (рис. 4).

 

Рисунок 4. Класс BaseRepo

 

Рисунок 5. Класс BaseController

 

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

 

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

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

Оставить комментарий

Форма обратной связи о взаимодействии с сайтом
CAPTCHA
Этот вопрос задается для того, чтобы выяснить, являетесь ли Вы человеком или представляете из себя автоматическую спам-рассылку.