Учитывая ваш текст из статьи, описываемый вами .NET хост просто подключает вашу библиотеку к себе в аппдомен и держит его там, дёргая ваши методы через рефлексию (или кодген). Благодаря этому наблюдению у меня сложилась картина, как можно это использовать без какой-либо боли, описанной вами в статье (но я мог что-то пропустить, так что жду обратной связи)
App.Run можно вызывать из любых потоков, в т.ч. из нескольких одновременно.
В BuildContainer инициализируете ваш DI, этот код будет запущен лишь один раз на весь хостовый процесс/аппдомен.
При любом вызове вы получаете ссылку на IServiceProvider, который находится в скоупе, который будет успешно закрыт после выполнения вышего делегата.
Как использовать: рисуете свой хендлер, внутри оборачиваете свой бизнес-код в делегат:
public class Handler { public string FunctionHandler(int arg) { return App.Run(provider => { // Здесь бизнес-код, все сервисы доступны через provider. return $"Hello world_{arg}"; }); } }
Уважаемый автор, нижайшепрошу прощения, но мне кажется, что вы проиграли пошли не туда ещё на этапе "Подготовка приложения".
Дело в том, что вам стоило задуматься и (вполне закономерно) осознать, что встреченная вами ситуация не так проблематична, как кажется на первый взгляд.
Видите ли, ее можно решить написав небольшую обёртку с DI (мы же хотим красиво), поставив лок против race condition, и все красиво запаковать в минимальное количество абстракций.
В таком виде бизнес-код можно будет писать хоть прямо в этих самых "хендлерах", обернув их, разве что, в делегат.
Да вроде бы именно так вы и сказали: из вашего личного опыта вы считаете наличие некоего функционала минусом. "Наличие" может быть применимо только к пакету, в котором этот функционал находится.
NeoNN описал просто набор дополнительного сахара, но там есть и вещи, которые невозможны в принципе в стандартном DI, их туда просто еще не завезли.
Например, декораторы, или упомянутые интерцепторы.
Еще там есть очень полезная регистрация по ключу, но в .NET 8 её поспешно добавили, ибо без нее DI был совсем дохленький в плане функционала.
Из "сахара" там есть возможность указания делегата для резолва конкретного аргумента конструктора (или свойства, неважно), в то время как в стандартном DI нужно будет писать new X(sp.resolve, sp.resolve, sp.resolve....).
Короче, Autofac в целом делает жизнь намного проще, если у вас проект не самый простенький.
Даже здесь может быть несколько ответов. Например, она могла сидеть на моем лице.
Но подойдёт в том числе и любой исчезающий ответ. Например, она могла сидеть на луже воды, или на осколочной гранате. Вряд ли вы сможете сцедить из атмосферы те же самые молекулы воды, или же склеить все осколки обратно (очистив их от девушки)
Меня эта херня невероятно бесила ещё в 5 лет, когда на загадки типа "висит груша - нельзя скушать" не принимались ответы типа "гнилая/высоковато/итд", а на вопрос "ну почему мой ответ не подходит" вместо обосновывающих аргументом всегда говорили "правильный ответ - лампочка", и все тут. Ух, как же это бесит
У автор использует строгий контракт, где он легко может ограничить диапазон используемых операторов, полей и значений, передаваемых от клиента.
А динамик линк это полный гуляй-вася.
Автор выбрал такой подход, где его код уже находится в самом удобном для валидации входящих параметров контексте, в то время как динамик линк на входе имеет карт-бланш, а на выходе уже готовый экспрешн.
После некоторых курсов это даже не джун.
А ещё на улице ветер, бывает, дует)
А что, теперь тут будет реклама в постах?
Учитывая ваш текст из статьи, описываемый вами .NET хост просто подключает вашу библиотеку к себе в аппдомен и держит его там, дёргая ваши методы через рефлексию (или кодген). Благодаря этому наблюдению у меня сложилась картина, как можно это использовать без какой-либо боли, описанной вами в статье (но я мог что-то пропустить, так что жду обратной связи)
Вот микропример того, что я имел ввиду: https://pastebin.com/bG6DyJxn
Что такой подход даёт:
App.Runможно вызывать из любых потоков, в т.ч. из нескольких одновременно.В
BuildContainerинициализируете ваш DI, этот код будет запущен лишь один раз на весь хостовый процесс/аппдомен.При любом вызове вы получаете ссылку на
IServiceProvider, который находится в скоупе, который будет успешно закрыт после выполнения вышего делегата.Как использовать: рисуете свой хендлер, внутри оборачиваете свой бизнес-код в делегат:
public class Handler{
public string FunctionHandler(int arg)
{
return App.Run(provider =>
{
// Здесь бизнес-код, все сервисы доступны через provider.
return $"Hello world_{arg}";
});
}
}
Уважаемый автор, нижайшепрошу прощения, но мне кажется, что вы
проигралипошли не туда ещё на этапе "Подготовка приложения".Дело в том, что вам стоило задуматься и (вполне закономерно) осознать, что встреченная вами ситуация не так проблематична, как кажется на первый взгляд.
Видите ли, ее можно решить написав небольшую обёртку с DI (мы же хотим красиво), поставив лок против race condition, и все красиво запаковать в минимальное количество абстракций.
В таком виде бизнес-код можно будет писать хоть прямо в этих самых "хендлерах", обернув их, разве что, в делегат.
Ах, красота. Но жаль неочевидно ни разу.
Да вроде бы именно так вы и сказали: из вашего личного опыта вы считаете наличие некоего функционала минусом. "Наличие" может быть применимо только к пакету, в котором этот функционал находится.
Это как говорить, что молоток плохой, ибо есть люди, которые им по голове бьют)
Да, допустим интерцепторы редко когда нужны, но их наличие ведь не делает библиотеку более плохой, не так ли?
NeoNN описал просто набор дополнительного сахара, но там есть и вещи, которые невозможны в принципе в стандартном DI, их туда просто еще не завезли.
Например, декораторы, или упомянутые интерцепторы.
Еще там есть очень полезная регистрация по ключу, но в .NET 8 её поспешно добавили, ибо без нее DI был совсем дохленький в плане функционала.
Из "сахара" там есть возможность указания делегата для резолва конкретного аргумента конструктора (или свойства, неважно), в то время как в стандартном DI нужно будет писать new X(sp.resolve, sp.resolve, sp.resolve....).
Короче, Autofac в целом делает жизнь намного проще, если у вас проект не самый простенький.
Таких называют эгоистами, гедонистами, "ишь удумал для себя пожить" и прочими социально-неодобрительными взглядами.
"Загадка" оказалась не в том, чтобы найти подходящее решение, а в том, чтобы угадать общепринятый ответ. Все встало на свои места :)
Надо просто сразу сходу говорить "погоди-погоди, ты, наверное, имеешь ввиду не загадку, а угадайку?" :)
Даже здесь может быть несколько ответов. Например, она могла сидеть на моем лице.
Но подойдёт в том числе и любой исчезающий ответ. Например, она могла сидеть на луже воды, или на осколочной гранате. Вряд ли вы сможете сцедить из атмосферы те же самые молекулы воды, или же склеить все осколки обратно (очистив их от девушки)
Меня эта херня невероятно бесила ещё в 5 лет, когда на загадки типа "висит груша - нельзя скушать" не принимались ответы типа "гнилая/высоковато/итд", а на вопрос "ну почему мой ответ не подходит" вместо обосновывающих аргументом всегда говорили "правильный ответ - лампочка", и все тут. Ух, как же это бесит
Холивар детектед.
А как хром заставить в v6?
Есть AsyncLock из известного пакета.
У Хоум ассистанта такая же беда была. Пришлось под обрезанный недолинук с флешки файлы тащить
Это такой тонкий намек на то, что текст статьи сгенерирован?)
У автор использует строгий контракт, где он легко может ограничить диапазон используемых операторов, полей и значений, передаваемых от клиента.
А динамик линк это полный гуляй-вася.
Автор выбрал такой подход, где его код уже находится в самом удобном для валидации входящих параметров контексте, в то время как динамик линк на входе имеет карт-бланш, а на выходе уже готовый экспрешн.