Андрей Парамонов, Антон Оникийчук — MediatR не нужен

• Кирилл Маурин представляет доклад Антона Никитка и Андрея Парамонова.  

• Тема доклада: "Медиатор не нужен".  

• Кирилл шутит о том, кто будет экспертом по теме.  

• Андрей признается, что ввел медиатор в проект.  

• Кирилл рассказывает, что успешно отбивал попытки внедрения медиатора.  

• Антон и Андрей решили сделать доклад после получения ссылки на примеры использования медиатора.  

• Кирилл предупреждает, что доклад будет содержать много боли.  

• Антон и Андрей надеются, что их опыт будет полезен для других.  

• Кирилл подчеркивает, что доклад будет полезен как для тех, кто хочет использовать медиатор, так и для тех, кто уже его использует.  

• Антон и Андрей начинают доклад о проблемах с медиатором в компании Додо.  

• Антон рассказывает о шутке проджект-менеджера Microsoft о добавлении медиатора в .NET 8.  

• Антон объясняет, что доклад был инициирован для обсуждения и обмена мнениями.  

• Антон рассказывает о докладе Макса Шинова, который предложил делить код по фичам.  

• Макс упомянул медиатор как возможный инструмент для улучшения обработки ошибок.  

• Антон и Андрей решили использовать медиатор, несмотря на первоначальные сомнения.  

• Андрей объясняет, что медиатор уменьшает связанность внутри приложения.  

• Медиатор позволяет уведомлять заинтересованные сервисы о изменениях.  

• Медиатор имеет базовый интерфейс и метод для обработки запросов.  

• Медиатор позволяет добавлять пайплайны и фильтры для обработки запросов.  

• Медиатор поддерживает логирование и откручивание цепочки вызовов.  

• Медиатор реализует логику идентификации событий через интерфейс IDictionary.  

• Обсуждение перфоманса медиатора.  

• Использование бенчмарка dotnet в песочнице.  

• Призыв к специалистам по перфомансу проверить результаты.  

• Описание пайплайна: два сервиса, юнита форк и медиатор.  

• Результаты: медиатор в 9-89 раз медленнее и потребляет больше памяти.  

• Медиатор редко используется для простых задач.  

• Тестирование с нагрузкой на C#.  

• Два сценария: 20 потоков и 5000 потоков.  

• Результаты: разница в перфомансе незначительна.  

• Пример использования медиатора в контроллере.  

• Сложности в понимании логики обработки данных.  

• Проблемы с навигацией и переиспользованием кода.  

• Медиатор усложняет навигацию и увеличивает неопределенность.  

• Это усложняет работу для новых разработчиков.  

• Пайплайн пришел из функциональных языков и используется для формирования цепочки действий.  

• Пример: валидация адреса, обновление, безопасность, блокировка.  

• В .NET пайплайн реализуется через контейнеры, что усложняет понимание логики.  

• В .NET пайплайн сложно понять без контекста.  

• Пример из бэкенда мобильного приложения: регистрация пайплайна и его поведение.  

• Сравнение с наследованием и композицией: сложность понимания логики.  

• Использование паттерна стратегия для улучшения понимания кода.  

• Пример с классом Format: важно понимать, что происходит внутри метода, а не только его вызов.  

• Пайплайн скрывает детали реализации, что усложняет понимание.  

• В пайплайне выделяются две группы ответственностей: нефункциональные и функциональные.  

• Пример с логированием: важно размещать логирование ближе к входной и выходной точкам приложения.  

• Логирование должно быть максимально точным, чтобы не терять важную информацию.  

• Логирование должно происходить как можно ближе к входной и выходной точкам.  

• Использование библиотеки для логирования: указание полей и типов данных.  

• Введение дополнительного слоя абстракции для логирования детальной информации.  

• Введение дополнительного слоя абстракции для логирования.  

• Пример с генератором, который добавляет данные в логи.  

• Логирование не должно замысливать код и должно быть легко настраиваемым.  

• Метрики должны быть ближе к месту входа запросов в приложение.  

• Логирование и метрики должны быть интегрированы в пайплайн.  

• Использование библиотек для инструментирования пайплайна.  

• Создание метрик с помощью статических классов и методов.  

• Метрики помогают понять, что изменилось в коде.  

• Важно интерпретировать метрики правильно.  

• Трейсинг помогает понять, что происходит в запросах.  

• Использование систем диагностики для трейсинга.  

• Важно собирать трейсы из пайплайна для лучшего понимания кода.  

• Валидация входных параметров и бизнес-валидация.  

• Валидация должна быть ближе к домену.  

• Проблемы с неявной валидацией и её решение.  

• Транзакции должны быть абстрагированы от работы с базой данных.  

• Использование абстракции для управления транзакциями.  

• Важно сделать транзакции явными и предсказуемыми.  

• Проблемы с публикацией изменений в пайплайне.  

• Введение абстракции для идентификации изменений.  

• Использование медиатора для публикации модификаций в однопоточном приложении.  

• Явный код легче отследить и поддерживать.  

• Неявный код может привести к непредсказуемому поведению.  

• Важно, чтобы взятие лока было явно указано в коде.  

• Неявность в использовании локов может привести к ошибкам.  

• Важно, чтобы взятие лока было частью апликейшн кода.  

• Использование абстракций над локинг-механизмами помогает избежать проблем.  

• Ретрайлинг чувствителен к месту применения.  

• Непредсказуемое поведение может привести к ошибкам.  

• Важно явно указывать точку применения ретрайлинга.  

• Явный код валидации и лок-взятия.  

• Применение данных к стейту и коммит изменений.  

• Создание спонсора для отправки данных.  

• Медиаторы усложняют код и диагностику проблем.  

• Контравариантные интерфейсы медиаторов могут привести к непредсказуемому поведению.  

• Явный код лучше конфигурируется и понимается.  

• Странное поведение при парсинге данных вне контекста.  

• Проблемы с валидацией и использованием открытых сетов.  

• Медиаторы могут изменять флоу выполнения запросов.  

• Вопросы о размещении верхнего трай кетч.  

• Использование ссепшен-хендлера для обработки ошибок.  

• Рекомендации по обработке известных ошибок и использованию фильтров.  

• Медиаторы одобрены для агрегации событий.  

• Реактивные библиотеки уже содержат все необходимые функции.  

• Медиаторы полезны для паттерна агрегатора, но не всегда необходимы для дата-флоу.  

• Медиаторы могут быть сложными и не всегда полезны.  

• Концепция обзора интерфейса сложна для понимания.  

• Медиаторы реализуют антипаттерны, такие как неявные связи между компонентами.  

• Неявные связи между компонентами делают их сложными для отладки.  

• Пример с радиосвязью: связь между компонентами неявна.  

• Удаление медиаторов из приложения может улучшить его структуру.  

• Замена API-вызовов на ивенты может быть опасной.  

• Лучше использовать явные каналы, такие как очереди.  

• Если последствия от невосприятия ивента значительны, лучше использовать мультикаст API-вызов.  

• Явная архитектура лучше неявной.  

• Телеметрия и контроллеры часто неявны.  

• Важно разделять технику и инфраструктуру.  

• Возможность задать вопросы докладчикам.  

• Оценка доклада перед обсуждением.  

• Приглашение к дискуссии и оценке выступления.