Вы знали, что AutoMapper и MediatR создал один и тот же человек?

Джимми Богард создал две крайне обсуждаемые и спорные темы в .NET разработке. Если с MediatR уже разобрались, то c AutoMapper также хотелось бы расставить все точки над "ё".

В этой статье хочу поговорить об истории возникновения библиотеки. О том какую задачу она была призвана решать изначально. И уделить внимание её недостаткам.

Спор "Java vs. C#" существует чуть меньше, чем вечность. Есть много статей, затрагивающих разные участки его спектра: Что есть в C# чего нет в Java, что языки друг у друга позаимствовали, у одних LINQ, у других обратная совместимость, в общем, тысячи их.

Однако, я никогда не видел, чтобы писали о чём-то, что в Java, с точки зрения фич языка есть, чего в C# нет. Впрочем, я здесь не для того, чтобы спорить. Эта статья призвана выразить моё субъективное мнение и заполнить небольшой пробел по теме, озвученной в заголовке.

MediatR - это очень популярная библиотека, которая используется для уменьшения зависимостей между объектами. Она популяризует архитектуру, основанную на крайне значимых принципах проектирования:

• препятствование прямому общению между объектами для уменьшения связности;

• нацеливание на Message-Oriented архитектуру;

• поддержка асинхронного внутреннего обмена сообщениями;

• ориентирование на переиспользование объектов.

Эти практики не пустое слово для меня. Кроме того, кажется, что такой способ создания программного обеспечения должен быть совершенно очевидным. Без сомнения, библиотека MediatR очень успешна и широко применяется разработчиками, которые разделяют эти ценности.

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

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

Также стоит отметить, что эта статья не покрывает положительные аспекты библиотеки, а фокусируется только на недостатках.

MediatR является, безусловно, очень успешным и популярным open-source проектом, который глубоко проник в недры коммерческой разработки. Однако, сколь популярен инструмент столь много способов его применения рождается среди сообщества. В этой статье я покажу два самых главных способа использовать этот инструмент неправильно вместе со способами решения проблемы

Дженерики - мощная фича доступная во многих статически типизированных языках программирования. С их помощью можно писать код, который постоянно работает со множеством разных типов, делая упор на их общие особенности, нежели на сами типы. Они позволяют создавать гибкие и переиспользуемые компоненты без нужды в дублировании кода и жертвы безопасности типов.

Несмотря на то, что дженерики давно в C#, мне всё же удаётся найти новые интересные способы их применения. Например, в одной из моих предыдущих статей я написал об уловке, позволяющей добиться return type inference, что может облегчить работу с контейнерными union types.

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

После нескольких экспериментов, я нашёл способ решить проблему элегантно, используя подход схожий с паттерном проектирования fluent interface, который был применён не к объектам, а к типам. Мой подход предлагает domain-specific language, который позволяет разработчику построить нужный тип за несколько логических шагов, последовательно его "конфигурируя".

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

Мне по-настоящему нравится больше чего-либо в разработке ПО делать фреймворки, позволяющие другим разработчикам создавать что-то крутое. Иногда, в погоне за идеальным кодом, мне на ум приходят странные идеи, при реализации которых C# может дойти до предела своих возможностей.

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

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

Ранее, в материале "Абстрактная алгебра в действии" я привёл некоторые примеры алгебраического подхода в программировании. Публикацию восприняли относительно хорошо, поэтому в этой заметке продолжится развитие мысли о том, что некоторые задачи, хоть так и не кажется на первый взгляд, на самом деле, могут быть решены алгебраическим способом. Сегодня мы продвинемся дальше в вопросе знакомства с абстрактной алгеброй и посмотрим на новые примеры кода с её применением.

В последнее время всё чаще я ощущаю математическое веяние в программировании. Нет, это не про интегралы с производными, а про что-то абстрактное, другое. Про то, что было всегда у нас под носом, но оставалось незамеченным. Наступит день - про это будут говорить на каждом углу. Но не сегодня. Сегодня мы с этим познакомимся.

Аннотация

Пусть дано метрическое пространство $$. Тогда мы можем определить метрическое пространство с расстоянием Хаусдорфа $$ на множестве $$, которое является семейством всех непустых компактных подмножеств $$. В этой статье будет показано, что если $$ — полное, то метрическое пространство $$ также является полным.

Введение

Данная статья не история успеха, а скорее руководство «как не надо делать». Весной 2020 для поддержания спортивного тонуса участвовал в студенческом хакатоне (спойлер: заняли 2-е место). Удивительно, но задача из полуфинала оказалась более интересной и сложной чем финальная. Как вы поняли, о ней и своём решении расскажу под катом.

«Крутую ты штуку придумал, Стёпа», — сообщил мне коллега, осознав рассказанную ему идею. Надеюсь это действительно так, хоть и не скажу, что в том, о чём далее пойдёт речь, есть что-то безумно новаторское, однако, на мой взгляд, интерес данный материал всё же представляет.
Сегодня поговорим о применении интроспекции в разработке веб-интерфейсов, немного пошаманим с обобщённым программированием и изобретём велосипед в Typescript, имеющий похожий аналог в .NET.

Во время выполнения заказа по разработке telegram бота у меня возникла необходимость получения скриншота веб-страницы с его доставкой пользователю. Зачем задумываться над решением проблемы, когда его можно найти? Как оказалось, чтобы не платить! Подробнее пот катом.