Я могу видеть определенный смысл в формировании специализированных функций, скажем там, для проверки таких сущностей как email, credit-card, при проверке соответствия шаблону пароля...

Но видеть отдельным оператором такое как `LessThanOrEqual / GreaterThanOrEqual` или `ExclusiveBetween / InclusiveBetween` - мне лично прямо глаз режет.

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

Исправил. Спасибо за замечание.

Это результат валидации, экземпляр класса FlatValidationResult

Я не эксперт в том, что там компилятор Go может наколдовать, но мне видится так, что сами по себе вызовы BenchmarkDirect(), а потом еще и incDirect() помещают в стек свои адреса возврата и переключают адресацию локальных переменных на новые области стека. Так каким же образом тогда получается доступ к переменной testInt64, оставшейся в другой области видимости? Очевидно, только по ссылке/указателю. Что в общем-то и подтверждают результаты теста.

// наш эталон производительности
var testInt64 int64

func BenchmarkDirect(b *testing.B) {
	for i := 0; i < b.N; i++ {
		incDirect()
	}
}

func incDirect() {
	testInt64++
}

StealthDogg, этот код был написан в основном просто, чтобы продемонстрировать возможность использования асинхронных вызовов. async и await тоже были добавлены только для демонстрации асинхронности, можно писать и так -

ErrorIf(m => userService.IsUserExistAsync(m.Email),
        m => $"Email {m.Email} already registered", 
        m => m.Email);

Соглашусь, в вашем замечании определённо присутствует рациональное зерно, у меня тоже были сомнения - вставлять нечто, что выглядит как вызов в базу, непосредственно в код самой валидации, кажется диким и режет глаз. Хотя ведь не факт же, что это именно вызов в базу, мало ли что там за сервис ))). Да, обычно такие проверки появляются уже в коде обработки запроса, после чего может следовать возврат NotFound404.

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

На мой взгляд, принципиально выбор между контроллерами и "минималками" лежит в основном в плоскости согласования с конкретными потребностями и/или ограничениями проекта. Контроллеры чисто психологически воспринимаются как нечто более постоянное, устойчивое. Наверное, они могут быть предпочтительнее для крупных, сложных проектов, где количество endpoint-ов велико. В Minimal API очевидна выгода при быстрой разработке, когда количество конечных точек не превышает уровень памяти программииста.

Использование любого подхода или даже гибридной модели просто оставляет возможность выбора.

Про сравнение производительности minimal api vs controllers - увы, ничего не могу сказать. Даже не задумывался как-то, в уверенности, что раз технология более новая, то и более быстрая. А вопрос интересный.

Пишите на контроллерах ))) Это вкусовщина, как мне кажется.

Конечно, меппинг бъётся на секции. А, вообще, я использую extension-метод, у меня проброс в MediatR происходит за скобками, а в самом меппинге только строка маршрута и DTO запроса. Правда, подгрузку файлов приходится штатно делать, но сколько там того.

Соглашусь, тут есть некоторые неудобства, как и с отладкой - надо знать, где точку останова ставить. Но, честно говоря, меня это как-то не сильно напрягает, всё дело в организации кода - когда по F12 на молели можно перейти в папку со всем скопом классов, поиск не вызывает трудностей. Попробуйте посмотреть пару-тройку примеров с clean architecture на гитхабе, там полно этого сейчас.

Что такое 10 контроллеров? Сколько это концов? Метод с CQRS, чаще реализуемый на базе MediatR, спокойно вытянет и 100 и 1000 обработчиков, и больше. Разницы нет, и читаемость проекта при этом ухудшается незначительно.

Обычно реализуется clean architecture с CQRS, получается удобно.

Описаны не люди, а роботы какие-то. Человеческий фактор или не учитывается, или учитывается в виде коэффициентов производительности. И с чего автор везде говорит о стабильном росте прибыли компании? Как этого добиться он нам секрета не раскрыл. Без реальной обратной связи легко ошибиться и повысить не того человека, а нужного - уволить. Как так? А потому что на всех уровнях двигают "своих", а высшее звено вынуждено доверять подаваемой информации. И всё, человек получил понижение и сделал ручкой, потому что обиделся, а проект в попке, потому что кум-сват-брат не могут.

Короче, гладко на бумаге, но в жизни-то - овраги.

Удобнее оно как-то, нагляднее, стыкуется по синтаксису с некоторыми библиотеками под другие ЯП. Но, конечно же, это не значит, что контроллеры прямо вот всё, это просто частное мннние )). Но я новые проекты уже только на "минималках" начинаю.

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

app.MapGet("/", ([AsParameters] MyRequest request) => Results.Ok());

Вообще, передача массивов рекордов через строку запросов выглядит как нестандартная задача. Как это вообще организовано? Не могли бы вы привести QueryString для такой конечной точки?

Еще есть вариант с десеарилизацией

app.MapPost("/", async (HttpContext context) => {
    if (context.Request.HasJsonContentType()) {
        var todo = await context.Request.ReadFromJsonAsync<Todo>(options);