Андрей Парамонов "MediatR не нужен" 

zen of pyton очень крутая философия - там сказано что "явное лучше неявного" и оно так и получается по сути))

Мне было интересно прослушать Ваш доклад и очень приятно то что Вы, в качестве отправной точки, рассказали о вкладе Максима Аршинова в развитие этой очень важной темы для разработчиков вашей страны. Я могу поделиться своей историей. Я, как менеджер проекта и «представитель заказчика из-за рубежа», работал с Максимом над большим проектом более четырех лет. Со стороны команды возглавляемой Максимом в проекте участвовали не менее 10 человек, в разные периоды времени количество разработчиков менялось. Максим реализовал именно ту схему которую он подробно описал в своем докладе. Я думаю что людям прослушавшим его доклад не надо рассказывать о его высоком профессионализме; поверьте мне на слово что он не только блестящий профессионал но и прекрасный человек, менеджер и руководитель группы. Итак - проект на backend-е был реализован по схеме доклада. У разработчиков в России не было проблем найти ошибку, понять логику кода и т.п. В конце моего участия в проекте в нашу команду «тут» были взяты двое местных разработчиков. И вот у них начались проблемы, но какого рода? Они были по техническому уровню несколько ниже разработчиков команды Максима и поэтому в течении месяца-двух они вносили баги из-за непонимания структуры middleware. Если бы, до начала работы, их бы провели по схеме и рассказали как это запроектировано, проблем бы не было, но они отказались по причине "сами-с-усами". Они разобрались в конце концов, но ценой нескольких очень неприятных ошибок в production, и, кстати говоря, непрерывно жалуясь на сложность, непонятность и "зачем так сложно хотя можно просто". Я хотел рассказать о практическом опыте в котором принимал участие лично я. Я не могу назвать вам этот проект, и Максим тоже не сможет по условиям NDA, но, учитывая срок разработки и количество разработчиков, вы сами сможете представить об'ем кода. Бизнес логика была очень и очень непростая.

Даа, неявно, все у него неявно. Если все это неявно сделать явно, то бизнес код просто утонет во всей этой инфраструктурной мишуре. Инфраструктура редко меняется, там практически нет багов, нет никакой необходимости постоянно на нее смотреть. Большинство проблем и багов обычно возникает в бизнес логике, изменения необходимы там же, новые фичи необходимы там же. И то, что медиатор позволяет изолировать бизнес аспекты от инфраструктурных это прекрасно. Все непонятки и неявности могут быть только в самом начале, когда команда только адаптируется к такому стилю. Со временем вопросы типа "Ой, откуда взялись транзакции" возникнуть просто не смогут, потому что единственное место, где идет работа с транзакциями это поведение медиатра. Практически все его поинты невалидные, за исключением может data enrichment и distributed lock-ов, которые действительно выглядят извращениями. При чем он часто противоречит сам себе. В одном кейсе говорит, что плохо, что используется HttpContextAccessor, потому что это может быть обработчик события. Через 5 минут предлагает пайплайн строить на мидлварях аспнета забыв про то, что есть еще обработчики событий, задачи по рассписанию etc Я думаю, что такой отрицательный опыт у человека возник исключительно из специфики его работы, где он постоянно залезает в разные проекты разных команд, которые пишут и строят код по разному. В таком случае неявность медиатора это конечно минус и лично для него было бы лучше, если бы его не было. Но для продуктовых команд которые годами работают над одной и той же кодовой базой это вообще не проблема.

ну так что бы не было загадкой давайте все писать в контроллере, а ?

🤦‍♂️

Не совсем ясно кто мешает расположить 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")); При проваливании в эту команду мы сразу увидим и хендлер и валидатор в одном файле.

То есть любой разработчик, когда пишет новый метод, реализующий новую логику, вместе ним должен написать 125 явных вызовов ортогональных абстракций (скоупы логгинга, метрик, валидации, еще черте что). Каждый раз для каждого нового метода, потому что вам лень посмотреть в стартапе порядок регистрации пайплайнов? Ну отличное решение, чо. Давайте тогда сразу вернемся к процедурному программированию, там одна большая портянка на 100500 строк и все понятно, кто где чего вызывает.

"В индустрии использование MediatR считается хорошим тоном." - нет, не считается)

Богохульство, Ересь - батон крошить на MediatR! Предать анафеме! )

Наверное надо просто хорошенько во всем разобраться, а уже потом выступать с вопросом "А что-то тут мне не понятно"

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

Я смотрю что современным программистам совсем сложно жить стало. То им сложно, это им не понятно. Скорее бы вас уже ChatGPT заменил и остались только нормальные программисты.