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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#полезное #tips

AutoFixture killer feature

Разбираясь в библиотеке AutoFixture пришёл к выводу, что её главное назначение это минимизация Arrange этапа в тесте.

За счёт чего это достигается? Специальные атрибуты для интеграций с фреймворками xUnit и NUnit предоставляют всю необходимую магию.

Например, атрибут AutoData.
Допустим, у нас есть некоторая корзина, которую надо протестировать на добавление позиций.
Как бы выглядел тест без AutoFixture?

[Fact]
public void Cart_NotNullItem_NotEmpty()
{
    var item = new Item();
    var sut = new Cart();

    sut.AddItem(item);

    Assert.NotEmpty(sut.Items);
}

А после применения атрибута?

[Theory, AutoData]
public void Cart_NotNullItem_NotEmpty(Item item, [Frozen] Cart sut)
{
    sut.AddItem(item);

    Assert.NotEmpty(sut.Items);
}

Теперь весь Arrange лёг на плечи библиотеки и больше не надо волноваться по поводу template кода с инстанциированием!
Ну а расширять поведение под нужды валидаций или каких-то moq'ирований естественно можно, но об этом в другой раз.

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

#полезное #tips

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

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

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

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

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

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

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

services.AddScoped<IMyService, MyService>();

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

#полезное #tips

C# разработчик

Полная занятость, удаленно
Зарплата: 240 - 330 т.р.
Компания: Top Selection, РФ

Описание: https://telegra.ph/C-razrabotchik-06-22

#вакансия

Факт дня про C# 11

Допустим, в проекте подключены nullable reference types.
Затем, объявляется некоторый класс с полем, у которого notnull ссылочный тип.
Чтобы не получить от компилятора warning CS8618, многие делают так:

public class Foo
{
    public string Bar {get; set;} = null!;
}

В C# 11 появилось ключевое слово required, которое позволяет красиво обыграть эту ситуацию:

public class Foo
{
    public required string Bar {get; set;}
}

#полезное #tips

3 причины использовать DateTimeOffset вместо DateTime

Если что-то из этого вам подходит стоит задуматься о смене используемого типа данных 🤔

Необходимо проверить, что из следующего вашему приложению нужно:

1️⃣ Уникально и однозначно определять единый момент во времени.
В системе появится недвусмысленное понятие «сейчас», можно будет логгировать временные метки транзакций, событий, созданий, модификаций и так далее.

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

3️⃣ Хранение нескольких связанных между собой меток времени, как частей одной структуры или одного массива данных.

#полезное #tips

Middle+/Senior QA Engineer fullstack (Backend)

Полная занятость, удаленно
Зарплата: от 300 т.р.
Компания: Rubraincom

Описание: https://telegra.ph/MiddleSenior-QA-Engineer-fullstack-Backend-07-10-2

#вакансия

Самый редко используемый цикл в C#

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

Его синтаксис таков:

do
{
// тело цикла
} while (condition)

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

Из этой особенности, отличающей do while от других видов циклов, вытекают его основные сценарии использования.

А как часто вы используете do while?

#полезное #tips

"Стоит ли использовать foreach, если for быстрее?"

Здесь важно понимать, чем отличаются эти циклы.

▪️for - это классический управляющий оператор, который транслируется в +/- одинаковый IR или машинный код практически во всех языках программирования согласно блок-схеме выше.

Принцип его работы одинаков везде:
for (выражение1; выражение2; выражение3)
оператор

▪️foreach - это синтаксический сахар над итераторами, который ещё и работает согласно принципам утиной типизации.
Перебираемому объекту даже не обязательно реализовывать IEnumerable.

Разворачивается такой цикл примерно в следующее:
var enumerator = enumerable.GetEnumerator();
while (enumerator.MoveNext())
{
var item = enumerator.Current;
// ...
}

Невооружённым глазом видно, что здесь происходит вызов через VMT, возможен cast, выделение памяти и так далее.
Обслуживание foreach очевидно дороже, потому что это абстракция.

Так что использование везде for вместо foreach - скорее микрооптимизация.

#полезное #tips

В последнее время часто приходится работать с enum.

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

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

Создавая новое перечисление, старайтесь предоставлять значение по умолчанию.

Иначе default(TEnum) может вернуть первое значение из перечисления, что может приводить к логическим несостыковкам и смысловым ошибкам.

Конечно, так надо делать только в соответствии с описываемой предметной областью.
Такое значение может называться None, Default или Unknown.

Такая структура enum позволит описать, как работать с вашим пользовательским типом данных.

#полезное #tips