Использование Lazy<T> с Dependency Injection в .NET

С этим я не спорил, это же очевидно, но непонятно, какие преимущества кроме "меньше кода" это даёт.

Если можно писать меньше кода без каких-либо потерь или жертв, это однозначно - преимущество.

Свои возражения о "скрытой регистрации Lazy для каждого типа T" я уже написал ранее. Мы с вами в этом вопросе никуда не продвинулись.

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

Cкрытая регистрация типов это плохо, это маскирует зависимости, делая код менее читаемым и отлаживаемым.

Само по себе утверждение верно. Но в случае с Lazy, никакого сокрытия или маскирования нет. Lazy интуитивно понятная инфраструктурная обёртка над зависимостью. И подобные обёртки уже активно используются. Никакой магии, никоим образом это не снижает читаемость, и не мешает отладке.

Каким образом размазывают? Все регистрации прописаны явно, если регистрация не прописана тут ModuleBootstrapper, значит её нет - предельно простое правило.

Явность регистраций никуда не девается. Если мне нужен IDataBaseService, я только его и регистрирую. Ленивость это не свойство регистрации, а свойство внедрения.

Действительно, причём тут авторитет, когда ОХ КАК ШИРОКО, АЖ МАКСИМАЛЬНО ШИРОКО это используется. Ссылка на "это очень широко используется" (или "все так делают") - это логическая ошибка argumentum ad populum, популярность не доказывает правильность или эффективность подхода.

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

Так что ваша "логическая ошибка", вообще мимо кассы, извините. Блеснуть не удалось :)

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

Ну я тоже резюмирую. Ваши рассуждения строятся вокруг тезиса, который вы определили как аксиому: "Lazy<T> это скрытая хакерская логика регистрации". А я должен исходя из вашей аксиомы построить убедительную аргументацию по принципу "да, но...".

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

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

Использование Lazy<T> с Dependency Injection в .NET

Ортогональность - возможность использовать Lazy<T> независимо от регистрации других типов. Ещё один пример ортогональности: IEnumerable<T>, который напрямую поддерживается контейнером, без необходимости регистрировать IEnumerable для каждого специфичного типа.

Точка ответственности - единое место, где описано поведение контейнера. Либо знание о Lazy<T> размазано по регистрациям, либо оно централизовано и не влияет на читаемость бизнес-регистраций.

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

Использование Lazy<T> с Dependency Injection в .NET

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

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

Использование Lazy<T> с Dependency Injection в .NET

Ведь бывают не только такие ситуации: "тут играем, тут не играем". Что насчёт кеша? Например, только в случае промаха, нужен ещё один граф объектов для извлечения значения и помещения его в кеш. Никакой SOLID не нарушается, а наоборот улучшает эффективность функции кеширования.

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

Использование Lazy<T> с Dependency Injection в .NET

Регистрация open generic это не "скрытая логика", а стандартный механизм DI, который уже широко используется в самом Microsoft.Extensions.DependencyInjection.
Примеры: ILogger<T>, IOptions<T>, IOptionsSnapshot<T>, IOptionsMonitor<T> - все они регистрируются как open generic и воспринимаются как нормальный контракт, а не магия.

Lazy<T> - это инфраструктурный способ разрешения зависимости, а не бизнес-логика. Его глобальная регистрация делает контейнер более предсказуемым и ортогональным, чем набор частных избыточных регистраций для каждого типа, за которыми ещё нужно дополнительно следить.

Разница между подходами не в прозрачности, а в точке ответственности.
Точечные регистрации размазывают знание о Lazy по регистрации сервисов,
open generic концентрирует его в одном месте, ровно как это сделано для ILogger<T> или IOptions<T>.

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

Более того, Microsoft в своей официальной документации дают ссылки на другие IoC-контейнеры, прямо сообщая, что если вам нужны поддержка Func<T>, прокси и прочие плюшки, выбирайте. Нет замечаний по поводу "скрытой логики" или какой-то магии.

Использование Lazy<T> с Dependency Injection в .NET

Так и используется:

public class ProductController : ControllerBase
{
    private readonly Lazy<IDatabaseService> _db;

    public ProductController(Lazy<IDatabaseService> db)
    {
        _db = db;
    }
}

Не нужно отдельно регистрировать точный generic-тип

// этого делать не требуется!
builder.Services.AddScoped(sp => new Lazy<IDatabaseService>(() => sp.GetRequiredService<IDatabaseService>()));

Использование Lazy<T> с Dependency Injection в .NET

А где пример с open generic? Как-то неудобно каждый раз регать сервис и плюс к нему ещё и Lazy-обёртку.

services.AddTransient(typeof(Lazy<>), typeof(LazyService<>));

public sealed class LazyService<T> : Lazy<T>
{
    public LazyService(IServiceProvider provider)
        : base(provider.GetRequiredService<T>)
    {
    }
}

Проблем с разными lifetime нет, сам Lazy transient. Да, для scoped-зависимостей может появиться несколько контейнеров Lazy, но экземпляр зависимости у них будет один в рамках scope.

Ваш кэш в .NET не защищён от cache stampede

Вот зачем вы такое пишите?

Ну изначально из-за довольно резкого сарказма:

Оказывается если класс использовать для задач, для которых он не предназначен, то он не сработает! Не знал, что такое бывает.

Виагра, например, вообще задумана как лекарство от стенокардии :)

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

С такими требованиями подходит решение через контейнер-функцию, как упомянули в комментариях так и реализовано в HybridCache, через Task.

Жаль, это работает только в рамках одного экземпляра.

Ваш кэш в .NET не защищён от cache stampede

Тут подъёхал релиз FusionCache 2.5.0 с поддержкой Distributed Cache Stampede Protection

Ваш кэш в .NET не защищён от cache stampede

Решение - при отсутсвии ключа в кэше, первый вызов, записывается ключ и статус "не готово", затем запускается метод получения данных, после того как метод завершён, данные помещаются в кэш и статус меняется на "готово".

Но это тоже не решение. В кеш должны помещаться только найденные данные. А если их там нет? Нам надо, например, вернуть 404, и не пытаться что-то писать в кеш.

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

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

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

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

Requestum 1.2.5: теги, политики устойчивости и встроенное логирование

На мой взгляд, теги код лучше не сделают. Одна из самых популярных претензий к MediatR — это ухудшение связности, и навигации по коду. Теги значительно ухудшают навигацию, так как превращают путь исполнения в чёрную магию. Это уже очень похоже на вызов функции по её строковому имени, и это в типизированном-то языке. У меня первая же мысль, как запретить теги на уровне компиляции. Одно дело, какие-нибудь ASP.NET контроллеры, где аспекты ещё уместны, так как это единый слой, одна плоскость, другое — лапша из команд и обработчиков, размазанных по всей кодовой базе.

Также поддержу предыдущий комментарий, если говорим про устойчивость, то нужны стратегии. И лучше всего тут работают политики, а не конкретные атрибуты с [Timeout] и [Retry], я бы направил усилия на интеграцию с Polly, где это всё есть и уже много наработано.

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

.NET C# и RabbitMQ Streams: превратить кролика в Kafka легко, нужно всего лишь…

Я бы выбрал NATS, стримы из коробки, меньше избыточных сущностей, быстрый и со стороны разработки показался прям сильно удобней, чем Rabbit. Конечно, если много всего написано и работает под Rabbit, наверное плагин будет кстати. Но специально я бы в него не шёл.

Главная проблема «чистых архитектур»

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

Извините, но я не понял откуда взялось "толкования". Их не надо толковать, они правда хорошо описаны.

Если у принципа нет однозначной интерпретации то пойдут толкования, различные взгляды и направления.

Различные взгляды произрастают только из-за лени и недостатка хоть какого-то опыта. Вот будет какой-нибудь новоиспечённый джун убеждать вас в том, что 2+2 это 22. Вы правда после этого начнёте утверждать, что алгебра плоха, потому что кто-то неправильно её толкует? Ну да, будут такие люди, это неизбежно.

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

Принципы достаточно хорошо согласуются с практикой. Их ноги растут из практики.

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

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

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

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

Как за 5 дней с помощью Claude я создал приложение для кошки с диабетом (и кажется запустил стартап)

Отдельно плюс за требования к рейтлимитам :) Видимо на опыте.

Как за 5 дней с помощью Claude я создал приложение для кошки с диабетом (и кажется запустил стартап)

Кстати да, я немного поработал с Claude и ChatGPT, для написания развесистой утилиты, меня результат удовлетворил. Правда только через чат. Но понял, что сначала надо поработать над самим заданием вместе с ИИ, прежде чем позволить нейронке срочно бросаться код генерить. Так получается меньше корректировок и меньше необходимости повторного ревью кода. С этой стороны открывается огромный простор для системных и бизнес-аналитиков :)

Как за 5 дней с помощью Claude я создал приложение для кошки с диабетом (и кажется запустил стартап)

Понял, спасибо! К сожалению не каждый проект можно разрабатывать с открытым гитхабом, а в наших реалиях, и вообще с любым гитхабом. Отдельная благодарочка за пример с промптом :) Это был следующий вопрос, выгоднее ли разбивать разработку на маленькие итерации, как это делается в обычных командах, или большими постановками. Ещё интересно, может ли ИИ съесть постановки задач, как это делается для людей, например в Confluence-Jira, но это наверное тема для отдельных статей.

Как за 5 дней с помощью Claude я создал приложение для кошки с диабетом (и кажется запустил стартап)

Т.е. Claude анализировал код на гитхабе, и вносил коммиты туда? Или комиты локальные? Т.е. вопрос скорее, обязателен ли гитхаб, можно было бы это проделать без него?

Как за 5 дней с помощью Claude я создал приложение для кошки с диабетом (и кажется запустил стартап)

Я может проглядел, что использовали для взаимодействия исходного кода и Claude? Какие инструменты? Или копировали исходники из чата и обратно? Спасибо.