Множество писем приходит, но ответ на это письмо, не могу не опубликовать. Уж очень интересная картинка рисуется. И более того, эта картина типична для большинства команд разработчиков. Публикую ответы на вопросы, которые были заданы в одном из писем, потому что это просто нужно опубликовать.

Вопросы из письма

"Я так понимаю стандартные контроллеры упразднены, взамен есть реализация с mediator."

Нет, Мediatr тут совсем ни при чем. Его можно использовать не только в Controllers и в Razor Pages, но в Blazor, и в любых других проектах разных платформ. Тут важна концепция Mediatr, она просто отделяет бизнес-логику от платформы, на которой реализовано решение. Никакого указания к тому, что вам использовать нет! Также, как когда-то появился ASP.NET MVC когда ASP.NET WebPages были "на коне", никто не говорил, что именно надо использовать и когда. Разработчики выбирали сами, приходя к выводу самостоятельно. Выбор был очевиден в пользу ASP.NET MVC, потому что позволило, как минимум, использовать unit-тестирование для таких проектов. Теперь пришла новая концепция - Vertical Slice Architecture, у которой свои "плюсы" (и нет минусов). Другими словами, хотите - используйте Controllers (MVC), а хотите Razor Pages и даже ASP.NET WebPages если уж совсем скучно. Более того, если хотите используйте Mediatr на любом из перечисленных типов проекта, а хотите без него. Одно могу утверждать точно, что есть проект не имеет реализации на подобие Mediatr, то с масштабированием проекта могут быть большие проблемы (если таковое планируется).

"По Вашему мнению и опыту данный подход является более гибким, чем стандартные ControllerBase ? Чем обусловлен его выбор?"

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

"Просто очень много негатива от коллег встречал по поводу медиатора. Сам же работал с ним на проекте только в режиме правок."

Всё что люди не знают - их пугает, а то, что их пугает - заставляет сторониться или даже проклинать и/или поливать "грязью". Со своей стороны могу сказать, что "в кривых руках и калькулятор зависает" или "вы просто не умеет готовить mediatr". Есть паттерн "Посредник" (Mediator), но фреймворк Mediatr не реализует этот паттерн полной мере (в некоторых применениях, вообще не реализует, как бы это странно ни звучало). Поэтому нельзя говорить про применение паттерна "Посредник" на базе Mediatr в вашем приложении. Ничего плохого в Mediatr нет, за исключением одного: это еще одна прослойка в бизнес-логике, а это значит, пару десятков миллисекунд добавится к времени выполнения запроса. Но суть в том, что надо понимать, какую пользу может принести эта "прослойка". Если вы не понимаете, то не надо его использовать. Это как оверлок: штука жутко полезная, но только если умеете им пользоваться! Если говорить про пользу, то как раз эта "прослойка" дает вам свободу выбора платформы, масштабируемости и покрытия тестами на базе поведения (behavior). Вы можете абстрагироваться от платформы и фреймворка (речь про MVC), и без особых проблем применить Domain Driven Design. Даже и Clean Architecture как способ построения архитектуры - будет не против, а только "за" использование фреймворков и/или подходов на подобие Mediatr.

"Их доводы:  1) его надо уметь готовить 2) новые сотрудники долго въезжает, приходится очень долго их саппортить чтобы не хардкодили и т.д. 3) медиатор - это хайп."

По порядку, начиная с первого.

      1. Всё надо уметь готовить, иначе будет как законе Мэрфи: "Напишите программу, которой сможет пользоваться даже дурак, и только дурак ей будет пользоваться". 
            а) Если уровень вашей команды не позволяет понять простые принципы и подходы, которые приняты на вооружения другими командами разработчиков, то... Хм... Сами судите об уровне вашей команды. 
            б) У разработчиков в команде, всегда должен быть стимул "расти" и наращивать свои навыки. Если всё будет слишком просто — это тоже не совсем хорошая ситуация, потому они начнут искать новые навыки "на стороне". Проходили это! Хотя, конечно же, и разработчики бывают разные. Но хорошие всегда хотят учиться (потому и хорошие)!
      2. Что касается "саппортить" и "долго въезжают", то тут всё просто. Понимание людей всегда зависит от того, как подается материал. А про для "хардкодили" скажу своё мнение, которое выработалось на основе опыта. Если кто-то что-то захочет захардкодить - вы не сможете этому помешать! Для этого придумали Code Review.
      3. Если что-то не понимаешь и/или нет понимания того, для чего это нужно, то чтобы не прослыть невежей всегда "кричи" что это хайп! (Раньше кричали "понты") 🙂

Заключение

На любую технологию, принцип, подход и прочие штуки найдутся те, что кто скажет - "это хайп". Я помню, что также говорили и про ASP.NET MVC. Я точно знаю, потому что когда к нам в Хабаровск приезжал один из представителей Microsoft и показать MVC v1.0. На серии вопросов к докладчику было много вопросов, про то "что это", "зачем это, ведь есть WebPages", "какой-то костыль"... и прочие формулировки. А теперь вы также думаете про ASP.NET MVC?

Ссылки

You Probably Don't Need to Worry About MediatR (jimmybogard.com)

Mediator на Source Generators