Size: a a a

2019 December 30

B

Bunk 🐈 in aiogram [ru]
std::mpa🌲
дурка. ты сам понимаешь, что говоришь?
Не я
источник

B

Bunk 🐈 in aiogram [ru]
источник

B

Bunk 🐈 in aiogram [ru]
Как закончить хоть один?
источник

s

std::mpa🌲 in aiogram [ru]
Gabben
Хороший был наброс с мвс, расходимся, продолжаем писать запросы в хендлерах
мвс говно же.
источник

Y

Yacha in aiogram [ru]
Bunk 🐈
Как закончить хоть один?
А их надо было заканчивать?
источник

B

Bunk 🐈 in aiogram [ru]
Yacha
А их надо было заканчивать?
Орнул
источник

Е

Егор in aiogram [ru]
Bunk 🐈
Как закончить хоть один?
Не писать говнокод
источник

ЮЧ

Юрий 👨‍🔬 Чебышев in aiogram [ru]
Bunk 🐈
Как закончить хоть один?
+
источник

G

Gabben in aiogram [ru]
Егор
Не писать говнокод
Этого недостаточно
источник

ЮЧ

Юрий 👨‍🔬 Чебышев in aiogram [ru]
Егор
Не писать говнокод
я бы сказал это вообще мало коррелирует
источник

Т

ТС in aiogram [ru]
Bunk 🐈
До того, как ему ничего не станет нужным
На самом деле до сих пор идёт внутренняя борьба между несколькими развилками в реализации. Моей целью изначально было желание отбросить поверхностные мнения в стиле «MVC для ботов - оверхед», и посмотреть как это всё-таки адаптировать, хотя бы из интереса "а подойдет ли?".

В моем случае деление системы проходит так:
Есть отделения Диспатч, Хэндлеры, Контроллеры, Модели, Отображения, Сервис (а также иерархические внутренности).

Диспатч - слой роутинга, к нему относятся телодвижения апдейтов, фильтрация, проверки и т. п., результат уходит в Хэндлеры на обработку (в самих обработчиках никаких проверок и фильтров нет, вы же не пилите один толстый хэндлер на сообщения с полотном ифов, верно? Тут тот же принцип, дробление и выполнение готовых команд)

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

Контроллеры - слой управления операциями. Каждый контроллер занимается каким-нибудь одним бизнес-процессом, например BalanceController занимается подготовкой модели юзера, загрузкой в неё баланса, и передачей модели отображению. Вся задача контроллера - подготовить нужные модели в инициализаторе, провести манипуляции и дернуть интерфейсы показа у preview и view объектов (preview полезен, например, для тайпинга от бота, или предупреждения о начале долгой операции). Контроллеры собраны по идеям паттерна Command, и имеют базового родителя, у которого просто перегружают метод манипуляций и конструктор. Таким образом мы разделяем TO_DO и то, что видит пользователь независимо друг от друга и не захламляем один большой хэндлер на 40-50 строк какой-то каши, где идет первичная фильтрация «а можно ли», потом запрос в бд, затем подготовка клавиатур, форматирование текста, подготовка списка выборки, ответ на колбэк, итоговая посылка сообщения и т. п. дичь в которую чтобы что-то добавить, нужно поебстись с расположением (дичь в плане совокупности кучи несвязных вещей, объединенных лишь смыслом «обработки»).
Контроллер по идее получается тонким, т. к. всего лишь берет модели, дергает у них методы load/save для загрузки данных в атрибуты модели-датакласс, и сохранения в БД, а также дергает методы показа. То есть по сути является связующим клеем, без собственной бизнес-логики. Ну это если занудствовать.
# псевдокод метода запуска
# __init__: user, preview, view
preview.show()  # if is not None
manipulate()  # по-умолчанию в теле pass
view.show()  # if is not None

При всём при том, метод todo может вообще отсутствовать, также как и методы показа (мало ли извращенцев). Поэтому особо не опирался на абстракную родительскую базу.

Модели - самая толстая по части логики вещь. Тут описаны все манипуляции по получению/сохранению данных (с DBMS из сервисного слоя), а также методы бизнес-логики. Здесь расположены именно данные, в том виде, в котором они проколонованы в базе.
источник

Т

ТС in aiogram [ru]
Bunk 🐈
До того, как ему ничего не станет нужным
Отображения - самая толстая (и единственная) по части внешнего взаимодействия с пользователем вещь. И тут можно пойти двумя путями, либо вовсе убрать отображенческий слой ввиду особенностей интерфейса ввода-вывода чат-бота (тупо некуда крепить HTML), либо пойти непривычным для классики путём - разделить класс Bot на два класса-полуфасада поменбше... service-bot и view-bot. В первом идет делегирование аиограмовскому Bot технических задач без возможности отображения (проще говоря, манипуляции с чем-либо), это, например, get_me, get_chat, kick_chat_member (рестрикт, промо, анбан и т. п.), а во втором все методы, направленные на видимое взаимодействие с юзером - все сенды, ансверы и т. д.
Причем в сервисном боте есть ветка вью - на случай, если нужно провести, например, массовую рассылку (это уже манипуляция сервиса, а не разговор с кем-то конкретным).
Также ко вью относится вся подготовка клавиатур и текста. Данные поставляются из моделей, которые ожидаются в конструкторе. Виды имеют перегруженный интерфейс show(), который дергает контроллер (по-умолчанию show абстрактный).

Сервис - дополнительные апи, которыми бот руководит. Например, контроллер может в своем манипулятивном методе дернуть запрос погоды у сервиса Weather, а затем подготовить модель-результат с сухими данными, которые затем мы уже можем вырвиглазно размещать как нам хочется в ветке отображений. DBMS (DataBase Management System) тоже относится к сервису.


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

Мог опять что-то проебать, писал второпях, так что простите, и кто ждет - ждите, всё уже на подходе, глянете хотя бы ради интереса, или для публичной порки, что тоже полезно
источник

s

std::mpa🌲 in aiogram [ru]
Шитрид
источник

t

this is not mrklf in aiogram [ru]
охххх заживём же с мвс
источник

MG

Mario Glesias in aiogram [ru]
ТС
Отображения - самая толстая (и единственная) по части внешнего взаимодействия с пользователем вещь. И тут можно пойти двумя путями, либо вовсе убрать отображенческий слой ввиду особенностей интерфейса ввода-вывода чат-бота (тупо некуда крепить HTML), либо пойти непривычным для классики путём - разделить класс Bot на два класса-полуфасада поменбше... service-bot и view-bot. В первом идет делегирование аиограмовскому Bot технических задач без возможности отображения (проще говоря, манипуляции с чем-либо), это, например, get_me, get_chat, kick_chat_member (рестрикт, промо, анбан и т. п.), а во втором все методы, направленные на видимое взаимодействие с юзером - все сенды, ансверы и т. д.
Причем в сервисном боте есть ветка вью - на случай, если нужно провести, например, массовую рассылку (это уже манипуляция сервиса, а не разговор с кем-то конкретным).
Также ко вью относится вся подготовка клавиатур и текста. Данные поставляются из моделей, которые ожидаются в конструкторе. Виды имеют перегруженный интерфейс show(), который дергает контроллер (по-умолчанию show абстрактный).

Сервис - дополнительные апи, которыми бот руководит. Например, контроллер может в своем манипулятивном методе дернуть запрос погоды у сервиса Weather, а затем подготовить модель-результат с сухими данными, которые затем мы уже можем вырвиглазно размещать как нам хочется в ветке отображений. DBMS (DataBase Management System) тоже относится к сервису.


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

Мог опять что-то проебать, писал второпях, так что простите, и кто ждет - ждите, всё уже на подходе, глянете хотя бы ради интереса, или для публичной порки, что тоже полезно
Не забывай о том что мвс после всего
источник

t

this is not mrklf in aiogram [ru]
псс, тс, сначала мвс, потом бот для марио
источник

MG

Mario Glesias in aiogram [ru]
this is not mrklf
псс, тс, сначала мвс, потом бот для марио
Нихуя, такой вариант  если и случится то тс о таком решении пожалеет
источник

B

Bunk 🐈 in aiogram [ru]
this is not mrklf
псс, тс, сначала мвс, потом бот для марио
Ага
источник

B

Bunk 🐈 in aiogram [ru]
Напомню, что можно кидать нам в лс
источник

B

Bunk 🐈 in aiogram [ru]
Марио не узнает
источник