Самый быстрый тест на грейд разработчика😁

Как лучше регистрировать коллекцию зависимостей?

Представим, что вам нужно внедрить коллекцию из сервисов типа IMyService. Тогда вы ожидаете её вот так:

class MyOtherService : IMyOtherService
{
    public MyOtherService(IEnumerable<IMyService> myServices)
    {
        //...
    }
}

Что приходит на ум?

▪️Создать свою кастомную коллекцию, и зарегистрировать её.

▪️Буквально зарегистрировать объект списка или массива с набором нужных зависимостей

Однако можно поступить гораздо проще и просто регистрировать зависимости как обычно. Например:

services.AddScoped<IMyService, MyService>();

DI контейнер всё поймёт и даже если будет зарегистрирована всего одна реализация, она будет представлена в коллекции.

Шёл 2023-й год, а некоторые C# разработчики, даже "ведущие", продолжают штамповать обобщённые репозитории...

Мда...🤡

https://habr.com/ru/companies/itq_group/articles/747566/

Об этом не писал только ленивый…

Итак, почему обобщённый репозиторий - это антипаттерн.

Прежде всего, давайте вспомним, что из себя представляет паттерн репозиторий, особенно популярный в DDD.

Согласно Дяде Бобу, репозиторий посредничает между доменом и слоем представления данных, находясь в роли in-memory коллекции доменных объектов.

Проще говоря, это фасад для доступа к данным, который оборачивает конкретный источник данных: ORM, сервис, СУБД, файловая система, Active Directory и т.д.

Так вот, начну с неочевидного.

Если вы используете ORM, например, Entity Framework или NHibernate, то следует помнить, что эти библиотеки сами по себе предоставляют реализации не только обобщённых репозиториев, но и единиц работы Unit Of Work.

В случае EF DbContext является UOW, а DbSet<T> это обобщённый репозиторий.
В случае NHibernate оба паттерна инкапсулированы внутри ISession.

Соответственно, создание новой обёртки поверх существующей аналогично переизобретению колеса, которое ещё и будет квадратным.

В отрыве от ORM, конечно обобщённые репозитории, в силу своей "обобщённости", превращаются в DAL код, намертво впаенный в алгоритмы бизнес-логики.

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

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

А домен не является обобщённым. Не каждая сущность может быть добавлена/удалена или отредактирована единым образом, не у каждой сущности будет репозиторий вовсе.

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

С другой стороны, репозиторий определяет операции, которые хранилище данных можнт осуществлять над доменными объектами.

А обобщённый вариант не предоставляет осмысленного контракта.
Просто сравните две сигнатуры ниже:

// вообще не понятно, что происходит
T Find(object param);

// более читабельный код, который чётко определяет
// отношение между хранилищем данных и доменным объектом
Customer FindCustomerByName(string name);

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

Вот так выглядит медаль за тестирование на проде

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

Ну что ребят, я пошёл изучать data science 😁

https://habr.com/ru/companies/ruvds/articles/749056/

Напоминаю, что 16 сентября буду выступать на Стачке в Ульяновске.

Если вы хотите приехать на конференцию, то сейчас самое время брать билеты.

Ведь для моих подписчиков, их друзей и коллег действует специальный промокод на скидку 10%:

StepOne

Где-то в параллельной вселенной:

1. Java и JavaScript - это один и тот же язык

2. Машинный байт-код был создан специально для фильма "Матрица", он используется только в его титрах

3. HTML и CSS - самые продвинутые языки программирования

4. Комментарии в коде замедляют выполнение программы

5. ВОЗ разрешил ставить SQL-инъекции от ковида

6. Вышел новый стандарт C++: (С++)++, сокращённо - C#

7. UDP и TCP - это legacy протоколы, все сетевые коммуникации массово переводят на JSON

Тем временем количество скачиваний моей библиотеки контрактов для реализации паттерна "Посетитель" превысило 1000 🥳

Самое время поддержать проект звёздочкой ⭐️ на GitHub:
https://github.com/Stepami/visitor-net

Во всю готовлюсь к Стачке

Просматривал выступления прошлых лет, чтобы примерно понимать какие-то особенности и фишки конференции.

Наткнулся на очень интересное выступление - оказывается в 2018 году Анатолий Вассерман читал лекцию на Стачке.

Что могу сказать?
Все без исключения рвутся в IT 😅

А я вот пишу свой язык программирования.

Но поскольку компетенция в области конструирования компиляторов более уникальная, чем перекладывание JSON’ов, то мой проект стоит 200 000 000 рублей 😁

Знай, что разницы нет😁

Брокер сообщений на основе СУБД???

MassTransit в каком-то смысле зарекомендовал себя в качестве solid choice, когда дело доходит до разработки распределённых систем.

Однако, его проблема в том, что он содержит слишком много всего: AWS, Rabbit, in-memory 🤯

И вот совсем недавно, разработчики добавили ЕЩЁ 😰

Встречайте: транспорт сообщений на основе SQL базы данных.

Пока находится в активной разработке и стадии превью, но разработчики уверяют, что мощь PostgreSQL и Microsoft SQL Server можно обернуть во благо микросервисного общения.

Очень хочется потрогать новую технологию, но пока, к сожалению, нагрузка на работе не позволяет 😢

@steponeit

Очередной вклад в ничем не подкреплённый инфопузырь чат жпт.

Когда уже до них дойдёт наконец?)

Автор что-то пишет о работе миддлов, но сам даже до трейни не дотягивает, ибо ему неведомо о генераторах данных 🤡

Кстати, у всех работает поисковик Google без VPN?

Соевой авторке внезапно может не хватить на самокат для штурма Верхнего Ларса.

С одной стороны капитализм - штука циничная.

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

С другой стороны недовольство переносчицы прогрессивных ценностей мне не понять.

Мантры вроде «мы команда-семья вовлечённая в продукт, которая меняет мир» это инфантильный самообман.

Можно и дальше сидеть в ожидании, пока дядя будет снижать твой уровень жизни.

А можно принять суровую реальность и понять, что вариантов немного - эффективный job hopping или работа на себя.

Главное противоречие ООП

Зачастую многие разработчики сталкиваются с популярным заблуждением в коммерческой разработке.

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

Эта ситуация называется InterfaceImplementationPair.

В самом деле привычка восходит корнями к C/C++, где принято разделять header и code файлы.

Однако, время ушло далеко вперёд и надобность в подобных действиях сегодня отсутствует.

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

Поэтому не стоит бояться отсутствия интерфейсов, код от этого не потеряет в чистоте.