Андрей Парамонов "MediatR не нужен"
Vložit
- čas přidán 22. 08. 2024
- В индустрии использование MediatR считается хорошим тоном. Поработав с большим количеством сервисов, в которых его применяли, спикер понял, что в 99% случаев он вреден. Почему так и этому есть доказательства - обо всем этом вы узнаете из доклада.
Даа, неявно, все у него неявно. Если все это неявно сделать явно, то бизнес код просто утонет во всей этой инфраструктурной мишуре. Инфраструктура редко меняется, там практически нет багов, нет никакой необходимости постоянно на нее смотреть. Большинство проблем и багов обычно возникает в бизнес логике, изменения необходимы там же, новые фичи необходимы там же. И то, что медиатор позволяет изолировать бизнес аспекты от инфраструктурных это прекрасно. Все непонятки и неявности могут быть только в самом начале, когда команда только адаптируется к такому стилю. Со временем вопросы типа "Ой, откуда взялись транзакции" возникнуть просто не смогут, потому что единственное место, где идет работа с транзакциями это поведение медиатра.
Практически все его поинты невалидные, за исключением может data enrichment и distributed lock-ов, которые действительно выглядят извращениями. При чем он часто противоречит сам себе. В одном кейсе говорит, что плохо, что используется HttpContextAccessor, потому что это может быть обработчик события. Через 5 минут предлагает пайплайн строить на мидлварях аспнета забыв про то, что есть еще обработчики событий, задачи по рассписанию etc
Я думаю, что такой отрицательный опыт у человека возник исключительно из специфики его работы, где он постоянно залезает в разные проекты разных команд, которые пишут и строят код по разному. В таком случае неявность медиатора это конечно минус и лично для него было бы лучше, если бы его не было. Но для продуктовых команд которые годами работают над одной и той же кодовой базой это вообще не проблема.
Есть такая вещь как Leaky abstraction и автор правильно говорит местами, но косяк в том что не особо подготовился кроме "не понятно".
В проекте-однодневке "херак и в продакшн" это действительно вообще не проблема, потому что код писался буквально вчера, причём тобой же, ну или соседом. А вот у "продуктовых команд которые годами работают" есть тонны кода, где последний коммит был пять лет назад и все контрибуторы давно уволились. Ну и ты туда лезешь, а там куча неявных соглашений и вместо навигации по коду и чтения глазами логики начинается детективное расследование "кто инстанциирует объекты и как это вообще делается". Вот это "а откуда здесь вообще транзакции" из доклада - прямо 100% жизненная ситуация.
Мне было интересно прослушать Ваш доклад и очень приятно то что Вы, в качестве отправной точки, рассказали о вкладе Максима Аршинова в развитие этой очень важной темы для разработчиков вашей страны. Я могу поделиться своей историей.
Я, как менеджер проекта и «представитель заказчика из-за рубежа», работал с Максимом над большим проектом более четырех лет. Со стороны команды возглавляемой Максимом в проекте участвовали не менее 10 человек, в разные периоды времени количество разработчиков менялось. Максим реализовал именно ту схему которую он подробно описал в своем докладе. Я думаю что людям прослушавшим его доклад не надо рассказывать о его высоком профессионализме; поверьте мне на слово что он не только блестящий профессионал но и прекрасный человек, менеджер и руководитель группы.
Итак - проект на backend-е был реализован по схеме доклада. У разработчиков в России не было проблем найти ошибку, понять логику кода и т.п. В конце моего участия в проекте в нашу команду «тут» были взяты двое местных разработчиков. И вот у них начались проблемы, но какого рода? Они были по техническому уровню несколько ниже разработчиков команды Максима и поэтому в течении месяца-двух они вносили баги из-за непонимания структуры middleware. Если бы, до начала работы, их бы провели по схеме и рассказали как это запроектировано, проблем бы не было, но они отказались по причине "сами-с-усами". Они разобрались в конце концов, но ценой нескольких очень неприятных ошибок в production, и, кстати говоря, непрерывно жалуясь на сложность, непонятность и "зачем так сложно хотя можно просто".
Я хотел рассказать о практическом опыте в котором принимал участие лично я. Я не могу назвать вам этот проект, и Максим тоже не сможет по условиям NDA, но, учитывая срок разработки и количество разработчиков, вы сами сможете представить об'ем кода. Бизнес логика была очень и очень непростая.
То есть любой разработчик, когда пишет новый метод, реализующий новую логику, вместе ним должен написать 125 явных вызовов ортогональных абстракций (скоупы логгинга, метрик, валидации, еще черте что). Каждый раз для каждого нового метода, потому что вам лень посмотреть в стартапе порядок регистрации пайплайнов? Ну отличное решение, чо. Давайте тогда сразу вернемся к процедурному программированию, там одна большая портянка на 100500 строк и все понятно, кто где чего вызывает.
Добро пожаловать в гошники! 😀
С интерсептeрами+сорсгенераторами можно будет добавлять сбор метрик/логов/валидации/еще черте что без mediatr
@@shaqullЕсть еще 100500 вариантов добавления ортогональных ответственностей и в итоге получится тот же самый медиатр, вид сбоку. И зачем? Чтобы добавить в свой проект кучу плоходокументированного и никем не поддерживаемого инфраструктурного кода?
zen of pyton очень крутая философия - там сказано что "явное лучше неявного" и оно так и получается по сути))
ну так что бы не было загадкой давайте все писать в контроллере, а ?
все новое когда - то забытое старое )
Фи, контроллеры. Прямо в Main через Minimal API!
Чем не устраивает новый подход который выкладываем сами MS в своих примерах? Ендпоинты+обертка для агрегатов в виде репозитория, а для стремных запросов и сложных фильтров использовать спецификации к конкретным агрегатам. Минимум инфраструктурного кода, больше бизнес логики.
@@user-tu2vl5dc9j
Для микро да, для больших монолитов с десятками/сотнями эндпоинтов - бррр...
Ну или решить этот вопрос раз и навсегда - json rpc! 😀😀😀
Не совсем ясно кто мешает расположить Request, Handler и Validator в одном классе.
Тогда при одном взгляде на код становится все очевидно + IDE помогает в навигации
Например у нас домен сотрудников:
Feature folder - Employees;
Class - AddEmployee;
Employees/AddEmployee.AddEmployeeCommand
Employees/AddEmployee.Handler
Employees/AddEmployee.Validator
Вызов из контроллера будет выглядеть так:
var result = await Send(AddEmployee.AddEmployeeCommand("test-name"));
При проваливании в эту команду мы сразу увидим и хендлер и валидатор в одном файле.
"В индустрии использование MediatR считается хорошим тоном." - нет, не считается)
+1, это зашквар, инфа 100%
Никогда не понимал людей которые любят использовать MediatR. Мне кажется, что всегда есть поход лучше и проще.
например?
@@iamprovidence-xj5wf всегда.
@@zodchiygigas6098 какой бы подход ты посоветовал использовать в качестве замены MediatR?
Просто булькнул и ушёл..
Нет лучше/хуже. Есть явно, не явно, удобнее, сложнее :)
Наверное надо просто хорошенько во всем разобраться, а уже потом выступать с вопросом "А что-то тут мне не понятно"
🤦♂️
Я смотрю что современным программистам совсем сложно жить стало. То им сложно, это им не понятно. Скорее бы вас уже ChatGPT заменил и остались только нормальные программисты.
Ты не поверишь, но вся история IT крутится вокруг борьбы со сложностью. Так то можно и на ассемблере написать все что угодно)
@@okke00 можно. Но это не значит что если вам что-то не понятно, то это именно сложно. Большенство чужих решений вам изначально могут показаться не понятными. Всегда можно спросить почему так, а не иначе. В чем была причина написать именно так. Если вы на это не способны - вам сложно.
@@vitaliyleschenko Сложность в ПО довольно редко связана именно с доменом, как правило, это искусственная сложность, которая вызвана или несовершенством средств разработки или неумением людей писать поддерживаемый код. Первая проблема решается естественным эволюционным путем, именно поэтому мы сейчас и не пишем все на коболе или фортране каком-нибудь. Со вторым сложнее, т.к. всегда есть определенный процент разработчиков, которые считают, что на работе им надо писать код так, чтобы доказать остальным какие они крутые. Да, бывают ситуации, когда действительно сложное решение оправдано, но чаще это именно история про то, как условный Петя хотел потешить свое эго или просто развлечься. Ну и да, хорошей практикой является документировать свои решения, а не передавать знания как древние сказители, из уст в уста. Обычно если человек, неспособен описать почему было принято именно такое решение в проекте, то это решение не сильно обосновано.
Виталий был известный дворник, но по ночам в комментах срал 😁
Богохульство, Ересь - батон крошить на MediatR! Предать анафеме! )