Уважаемый автор, нижайшепрошу прощения, но мне кажется, что вы проиграли пошли не туда ещё на этапе "Подготовка приложения".
Дело в том, что вам стоило задуматься и (вполне закономерно) осознать, что встреченная вами ситуация не так проблематична, как кажется на первый взгляд.
Видите ли, ее можно решить написав небольшую обёртку с DI (мы же хотим красиво), поставив лок против race condition, и все красиво запаковать в минимальное количество абстракций.
В таком виде бизнес-код можно будет писать хоть прямо в этих самых "хендлерах", обернув их, разве что, в делегат.
Да вроде бы именно так вы и сказали: из вашего личного опыта вы считаете наличие некоего функционала минусом. "Наличие" может быть применимо только к пакету, в котором этот функционал находится.
NeoNN описал просто набор дополнительного сахара, но там есть и вещи, которые невозможны в принципе в стандартном DI, их туда просто еще не завезли.
Например, декораторы, или упомянутые интерцепторы.
Еще там есть очень полезная регистрация по ключу, но в .NET 8 её поспешно добавили, ибо без нее DI был совсем дохленький в плане функционала.
Из "сахара" там есть возможность указания делегата для резолва конкретного аргумента конструктора (или свойства, неважно), в то время как в стандартном DI нужно будет писать new X(sp.resolve, sp.resolve, sp.resolve....).
Короче, Autofac в целом делает жизнь намного проще, если у вас проект не самый простенький.
Даже здесь может быть несколько ответов. Например, она могла сидеть на моем лице.
Но подойдёт в том числе и любой исчезающий ответ. Например, она могла сидеть на луже воды, или на осколочной гранате. Вряд ли вы сможете сцедить из атмосферы те же самые молекулы воды, или же склеить все осколки обратно (очистив их от девушки)
Меня эта херня невероятно бесила ещё в 5 лет, когда на загадки типа "висит груша - нельзя скушать" не принимались ответы типа "гнилая/высоковато/итд", а на вопрос "ну почему мой ответ не подходит" вместо обосновывающих аргументом всегда говорили "правильный ответ - лампочка", и все тут. Ух, как же это бесит
У автор использует строгий контракт, где он легко может ограничить диапазон используемых операторов, полей и значений, передаваемых от клиента.
А динамик линк это полный гуляй-вася.
Автор выбрал такой подход, где его код уже находится в самом удобном для валидации входящих параметров контексте, в то время как динамик линк на входе имеет карт-бланш, а на выходе уже готовый экспрешн.
Ну потому что даже глядя на заглавную страницу понятно, что там клиенту очень много позволено будет. Ну или точно так же с валидаторами извращаться, чтобы запретить всё, что клиенту не нужно.
Уважаемый автор, нижайшепрошу прощения, но мне кажется, что вы
проигралипошли не туда ещё на этапе "Подготовка приложения".Дело в том, что вам стоило задуматься и (вполне закономерно) осознать, что встреченная вами ситуация не так проблематична, как кажется на первый взгляд.
Видите ли, ее можно решить написав небольшую обёртку с DI (мы же хотим красиво), поставив лок против race condition, и все красиво запаковать в минимальное количество абстракций.
В таком виде бизнес-код можно будет писать хоть прямо в этих самых "хендлерах", обернув их, разве что, в делегат.
Ах, красота. Но жаль неочевидно ни разу.
Да вроде бы именно так вы и сказали: из вашего личного опыта вы считаете наличие некоего функционала минусом. "Наличие" может быть применимо только к пакету, в котором этот функционал находится.
Это как говорить, что молоток плохой, ибо есть люди, которые им по голове бьют)
Да, допустим интерцепторы редко когда нужны, но их наличие ведь не делает библиотеку более плохой, не так ли?
NeoNN описал просто набор дополнительного сахара, но там есть и вещи, которые невозможны в принципе в стандартном DI, их туда просто еще не завезли.
Например, декораторы, или упомянутые интерцепторы.
Еще там есть очень полезная регистрация по ключу, но в .NET 8 её поспешно добавили, ибо без нее DI был совсем дохленький в плане функционала.
Из "сахара" там есть возможность указания делегата для резолва конкретного аргумента конструктора (или свойства, неважно), в то время как в стандартном DI нужно будет писать new X(sp.resolve, sp.resolve, sp.resolve....).
Короче, Autofac в целом делает жизнь намного проще, если у вас проект не самый простенький.
Таких называют эгоистами, гедонистами, "ишь удумал для себя пожить" и прочими социально-неодобрительными взглядами.
"Загадка" оказалась не в том, чтобы найти подходящее решение, а в том, чтобы угадать общепринятый ответ. Все встало на свои места :)
Надо просто сразу сходу говорить "погоди-погоди, ты, наверное, имеешь ввиду не загадку, а угадайку?" :)
Даже здесь может быть несколько ответов. Например, она могла сидеть на моем лице.
Но подойдёт в том числе и любой исчезающий ответ. Например, она могла сидеть на луже воды, или на осколочной гранате. Вряд ли вы сможете сцедить из атмосферы те же самые молекулы воды, или же склеить все осколки обратно (очистив их от девушки)
Меня эта херня невероятно бесила ещё в 5 лет, когда на загадки типа "висит груша - нельзя скушать" не принимались ответы типа "гнилая/высоковато/итд", а на вопрос "ну почему мой ответ не подходит" вместо обосновывающих аргументом всегда говорили "правильный ответ - лампочка", и все тут. Ух, как же это бесит
Холивар детектед.
А как хром заставить в v6?
Есть AsyncLock из известного пакета.
У Хоум ассистанта такая же беда была. Пришлось под обрезанный недолинук с флешки файлы тащить
Это такой тонкий намек на то, что текст статьи сгенерирован?)
У автор использует строгий контракт, где он легко может ограничить диапазон используемых операторов, полей и значений, передаваемых от клиента.
А динамик линк это полный гуляй-вася.
Автор выбрал такой подход, где его код уже находится в самом удобном для валидации входящих параметров контексте, в то время как динамик линк на входе имеет карт-бланш, а на выходе уже готовый экспрешн.
Ну потому что даже глядя на заглавную страницу понятно, что там клиенту очень много позволено будет. Ну или точно так же с валидаторами извращаться, чтобы запретить всё, что клиенту не нужно.
del
Флешка на лапке?
"давайте-ка исправляйте. В след раз можем и поправить наши if-ы"