Комментарии 25
Шел 22-ой год... За код отдельное спасибо :)
Оооочень длинный метод HandleUpdateAsync. Лучше коллекцию методов использовать и перебирать вызывая.
Тут не понял условия:
if (callbackQuery.Data == checkUserCallback.TgId.ToString() != null && userRole.Role == "controller")
Тесты? Декомпозиция кода? Зачем все эти глупости...
И граф переходов лишний :-(
Для MVP в самый раз. После 10 лет структурирования кода теперь учусь наоборот писать просто меньше кода, и меньше принимать инженерных решений. Это позволяет кратно увеличить количество создаваемых MVP и протестированных гипотез и созданных продуктов. А чистый структурированный код мертвых и не взлетевших идей не нужен никому.
Для MVP в самый раз.
Не понятно только, зачем этот код MVP выкладывать на хабр.
меньше принимать инженерных решений
Главное, помнить, что писать такой код - это тоже инженерное решение. И сваливать все принятие решений в один метод - тоже инженерное решение. Ну и так далее.
Зачем? Тут много вариантов ответов. Во-первых, другие так делают. Во-вторых, уровень читателей хабра сильно разный, а вы пытаетесь судить по своим меркам. В-третьих, я хоть и написал 5 ботов на шарпе, но мне пара строчек из исходников была полезна, там где изменился интерфейс либы. В-четвертых, начинающим авторам где-то надо набирать опыт и обратную связь. В-пятых, нашлось достаточно людей проголсовавших за эту статью, чтобы она попала в ленту. В-шестых, кому надо и так смогут разбить длинный метод или написать тесты по надобности. В-седьмых, в правилах хабра нет описанных вами требований к уровню кода. В-восьмых, есть цель повествования и всякие артефакты в виде тестов создают побочную нецелевую нагрузку.
я решил выложить, так как сам на хабре не нашел (точнее нашел, но у меня не запустилось) C# аналога машины состояний из aiogram, к примеру, а у меня она есть. Возможно кому-то будет полезно.
Не понятно только, зачем этот код MVP выкладывать на хабр.
чтобы такие ламеры как я разбирались в нем, принимали на вооружение и допиливали свое
стоило бы сделать, но не было времени, простите
Рекомендация: в статье читать километровые портянки кода ну очень неудобно, особенно с телефона
Хороший стиль - делать только какие-то небольшие блоки, которые нужны для иллюстрации подхода. А полный код проекта выложить на гитхаб и просто дать на него ссылку. Так ещё и повторить другим то же самое будет проще - гит клон и погнали.
А чем dependency injection не зашёл, тем более что вся структура проекта с ним создаётся мастером создания нового солюшена. Тут какой-то перебор со статикой.
Судя по качеству коду, автор даже на младшего разработчика не тянет. Лучше бы просто выложил обзор или описание библиотеки Telegram.Bot или сравнение с другими подобными библиотеками. А так смысла в таких публикациях нет
await DataBaseMethods.DialogCreate(userTgId, callbackQuery.Message.Chat.Id);
await DataBaseMethods.ToggleInDialogStatus(callbackQuery.Message.Chat.Id, 1, userTgId);
public static async Task DialogCreate(long IdTc, long IdDriver)
{
using (ApplicationContext db = new ApplicationContext())
{
//...
}
}
public static async Task ToggleInDialogStatus(long TgId, int Status, long receivier)
{
using (ApplicationContext db = new ApplicationContext())
{
//..
}
}
Мне вот любопытно, а вы понимаете, почему так делать не стоит?..
Один из вариантов пути, которым автор мог прийти к текущему коду при изучении EF Core
Загуглить как пользоваться EF Core - вылез бы overview
Увидеть там ТОЧНО ТАКИЕ ЖЕ примеры с using-ом контекста. Использовать их и на их основе писать статью.
А теперь давайте сравним этот код - и код из примера в другом разделе Get started with ASP.NET Core MVC
Случайно заметим, что _context там создаётся не в начале метода - а в конструкторе контроллера.
И тут можно было бы попытаться начать искать информацию в чём разница, может быть вообще стоит один контекст на всё время работы программы сделать? Ищем информацию о времени жизни контекста - находим DbContext Lifetime, Configuration, and Initialization. Перепишем вывод из этой статьи - один контекст на один UnitOfWork...
Вот так, постепенно, и можно собрать информацию на статью - максимально полное описание.
Давайте всё же сделаем скидку на то, что это первая статья.
А я буду держать кулачки за то, чтобы автор продолжил свою работу по изучению интересных ему тем - и с каждым новым разом разборы получались чуть глубже ;)
Спасибо, это была моя первая практика на с#, поэтому получилось не оптимизированно
Я слышал слухи, что EF как-то не особо дружит с паттерном UnitOfWork. Например вот тут:
https://gunnarpeipman.com/ef-core-repository-unit-of-work/
Простой Telegram.Bot мессенджер на C#