Как генерировать валидные данные?

Активные читатели моего канала могут подумать, что сейчас будет очередной пост про какую-нибудь кастомизацию AutoFixture, ведь все знают, как библиотека генерирует строки и числа.

А вот и нет! В сегодняшнем разговоре о генерации данных ключевое слово валидные.

Ответ на вопрос в заголовке: Bogus.

Да, для C# существует не один генератор данных.
Но разница проявляется как в назначении, так и в устройстве.

AutoFixture - это скорее некоторое подобие DI контейнера с CQRS архитектурой.
Bogus - инструмент, больше похожий на FluentValudation.

Для каждой модельки создаётся специальный генератор.
В нём с помощью fluent interface api всем полям прописываются правила по заполнению значений.

public class OrderFaker : Faker<Order>
{
public OrderFaker()
{
RuleFor(o => o.OrderId, f => f.Guid.NewGuid());
RuleFor(o => o.Item, f => f.Lorem.Sentence());
RuleFor(o => o.Quantity, f => f.Random.Number(1, 10));
}
}

var orderFaker = new OrderFaker();
var order = orderFaker.Generate();

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

#полезное #tips

Какой длины должны быть функции?

Если обратиться к такой классике, как «Чистый Код» Роберта С. Мартина, то можно увидеть следующее:

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

То есть, кажется, что это означает примерно следующее:

1️⃣ Функции должны быть короткими — не длиннее 20 строк и в большинстве случаев менее 10 строк.

2️⃣ Функции должны иметь как можно меньше аргументов, желательно ни одного.

Стоит придерживаться стратегии «разделяй и властвуй».
Попробовать разделить метод на несколько логических шагов, определить что от чего зависит.

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

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

Однако, практика показывает, что в любом проекте можно найти большой объём кода под рефакторинг с методами и на 100, 200, 300 строк с десятком параметров.

Как вы думаете, стоит их распиливать и переписывать?

#полезное #tips

Full-Stack .NET Developer

Полная занятость, удаленно
Зарплата: 4500-5700$
Компания: Smartbrain.io

Описание: https://telegra.ph/Full-Stack-NET-Developer-07-29

#вакансия

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

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

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

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

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

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

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

services.AddScoped<IMyService, MyService>();

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

#полезное #tips

.Net разработчик

Полная занятость, удаленно
Зарплата: 150 - 400 т.р.
Компания: Platforma

Описание: https://telegra.ph/Net-razrabotchik-08-14

#fulltime #remote

Коллеги, поделитесь в комментариях подходами, которые вы используете для рефакторинга.

Интересно, как вы к нему подступаетесь: сразу удаляете старое и встраиваете новое или реализуете своеобразный v2, на который всё постепенно пересаживаете?

Когда C# и Python разработчики пытаются что-то обсудить.

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

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

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

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

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

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

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

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

#полезное #tips

C# / .NET Backend Developer

Полная занятость, релокация/удаленно
Компания: Finom

Описание: https://telegra.ph/C--NET-Backend-Developer-08-14

#вакансия

Как скрыть от потребителя библиотеки лишние зависимости?

Недавно, я написал небольшую надстройку над AutoFixture, которая позволяет при создании объекта базового абстрактного класса получить экземпляр случайного наследника.

Допустим, у нас есть подобная иерархия:

abstract class A { }
class B : A { }
class C : A { }

Если написать fixture.Create<A>(), то мы получим исключение, поскольку вызывать new для абстрактных классов запрещено.
Ожидается, что мы получим случайным образом либо new B(), либо new C().

Однако, базовый функционал библиотеки не даёт такого поведения из коробки.
С помощью моего NuGet пакета можно настроить fixture таким образом, и всё заработает:

fixture.CustomizePolymorphism<A>()
    .WithDerivedType<B>()
    .WithDerivedType<C>()
    .BuildCustomization();

Так вот при создании библиотеки возникла проблема.
В связи с тем, что она создана как дополнение к AutoFixture, присутствует зависимость, которая потом попадает к потребителю в раздел Implicitly Installed Packages.
Согласитесь, неприятно.

Решается проблема очень просто, достаточно пометить зависимость атрибутом PrivateAssets со значением all в конфигурации файла проекта:

<PackageReference Include="AutoFixture" Version="4.18.0" PrivateAssets="all"/>

#полезное #tips