Для одного из наших устройств, применяемых в быту, понадобилось удобно и оперативно получать сводную статистику о текущем состоянии. Написание отдельного приложения для телефона показалось не очень удобным, потому что появляется необходимость поддерживать как минимум две распространённые операционные системы – Android и IOS. Также, пользователю потребовалось бы устанавливать данное приложение на свой телефон. Другой источник получения показаний с датчика – это web-сайт, но тут начинает страдать оперативность получения данных: необходимо открыть браузер, перейти на сайт, ввести логин/пароль. Для получения сводной статистики или оповещения о превышении допустимого значения пришлось бы в данном случае использовать иные средства доставки сообщений: электронная почта, СМС, звонки и т.д.
Но в современных реалиях, при большом распространении социальных сетей и мессенджеров, грешно не обратить взгляд в их сторону. Одним из бурно развивающихся, удобных и безопасных мессенджеров является Telegram. С ним и было принято решение начать работу.
Для разработки был выбран C# и NET Core 5, а вести её предполагалось в Visual Studio. Для работы с телеграм-ботом был скачан NuGet пакет Telegram.Bot.
Для регистрации нового бота в Телеграме необходимо зайти в группу BotFather, зарегистрировать свой новый канал и получить token для доступа к своему телеграм-боту.
Существует два способа оповещения от сервиса Telegram о приходе новых сообщений.
- Первый способ – постоянный опрос методом Api Телеграм, который сообщает о наличии новых сообщений. Данный способ рабочий, но могут возникнуть проблемы с самим Телеграмом. В целях уменьшения нагрузки на сервисы или если есть подозрения, что вы спамите, Телеграм может ваш канал заблокировать.
- Второй способ – это вебхуки. Это когда сервис Телеграма присылает в ваше приложение запрос, который содержит новые сообщения. Этот вариант является более перспективным, так как исключает возможность Телеграма заблокировать бота и уменьшает лаг отзыва на отправку запроса на команду пользователя за счёт исключения времени от периодического запроса наличия новых сообщений. Но возникает другая проблема: из соображений безопасности Телеграм требует наличие у хостинга вашего приложения подтверждённого сертификата или размещение вашего приложения на площадках с заведомо подписанным сертификатом, таких как Yandex Cloud, Azure и т.д. В защиту Telegram можно сказать, что он позволяет применение вебхуков и с самоподписным сертификатом, но это отдельная форма “извращения”, которую опустим в данной статье.
Для любого приложения необходимо хорошее логирование, для этого мы использовали Serilog.AspNetCore – достаточно быстрый, удобный и гибкий инструмент.
Сперва необходимо подумать над архитектурой проекта. Для изначально поставленных целей вполне хватило бы и цельно монолитного приложения, но мы подумали, что необходимо сразу же заложить более гибкие возможности, что позволит в дальнейшем производить точечное обновление или вести параллельную разработку. В качестве базы данных была использована применяемая у нас в компании MS SQL.
Дальше необходимо разделить проект на уровни.
Первичным у нас будет уровень доступа к данным (Core), он должен содержать все модели данных, хранящихся в БД, а также классы, через которые идёт взаимодействие с БД. Для увеличения гибкости подключения и работы с БД будем использовать репозитории, поэтому добавим проект (Repositories). Он должен содержать описание интерфейсов репозиториев и саму реализацию интерфейса. Но, к сожалению, впоследствии пришлось вынести описание интерфейса в отдельный проект, для исключения связей зацикливания. Об этом далее.
Следующим у нас будет уровень бизнес-логики. Он инкапсулирует всю бизнес-логику, все необходимые вычисления, получает объекты из уровня доступа к данным и передает их на уровень представления, либо, наоборот, получает данные с уровня представления и передает их на уровень данных. Уровень представлений не должен получать данные и иметь доступ к функциональности уровня доступа к данным. Чтобы разграничить эти два уровня создадим промежуточные сущности. Добавим проект (DTO). Суть этих сущностей будет заключаться в том, чтобы обеспечить необходимое количество данных, передаваемое и получаемое между уровнями представления и доступа к данным. Также, уровень бизнес служит не только для передачи данных между уровнями, но и может иметь свой функционал. Поэтому добавим проект (Services), который будет содержать логику работы программы: команды для приложения, сервисы для информирования пользователя, сервис забора данных из Mqtt и т.д. Для получения значения конфигурационных параметров из файла нам необходима модель для параметров. Чтобы исключить связь проектов Services и Core, который содержит модели базы данных, добавим новый проект (Infrastructure), в который добавим модель описывающую конфигурационные параметры. Чтобы обеспечить более гибкую работу с сервисами в приложении необходимо описать интерфейсы для работы с ними, данные интерфейсы должны располагаться на уровне бизнес-логики. Через них будет происходить взаимодействие с уровнем представлений. Также, логично перенести в данный проект интерфейсы с уровня доступа к данным, для уменьшения количества связок и более читаемого и понятного кода.
Последний уровень в нашем приложении – уровень представлений, это и есть само наше веб-приложение, содержащие контроллеры, необходимые для обработки запросов от пользователя, и конфигурация проекта.
Основной нашей задачей было исключение закольцовывания и уменьшение количества связей между проектами, разделение всех проектов на необходимые логические уровни. Как видим из блок-схемы, у нас получилось это сделать. Красными связями указаны связки проекта для его конфигурирования, и они не участвуют непосредственно в работе. Далее, наше приложение (Web.Api) имеет доступ только к интерфейсам сервисов и репозиториев и работает исключительно с ними, интерфейсы не имеют реализации, поэтому мы имеем гибкий подход к разработке. Сервисы и репозитории обмениваются данными через DTO, что способствует получению только необходимых данных и уменьшает их количество.
В данной статье мы раскрыли общий подход к построению проекта, в следующих частях будет подробно разобрана реализация каждого программного блока.
#телеграм #C# #программирование #edcteam
#разработка #центрразработкиэлектроники