Нас всех учат использовать Dependency-Injection для кодирования в ASP. NET Базовых приложениях, но все примеры, которые я до сих пор видел, связанные с поиском сервисов через DI, относятся к ситуациям. где метод с внедренной ссылкой на службу строго связан с указанным c HTTP-запросом (HttpContext) (например, MVC контроллеры, делегаты маршрутизации).
Расположение службы предупреждается как антишаблон , но я не уверен, как получить надлежащую ссылку на службу (например, DbContext) через DI в коде, который не связан с конкретным c HTTP-запросом, например, кодом, который должен отвечать на поступающие сообщения через веб-сокет.
Хотя сам веб-сокет изначально настроен с указанным c HTTP-запросом, сообщения будут получать ответы в течение потенциально длительного срока службы веб-сокета (пока длится пользовательский веб-сеанс) , Сервер должен не резервировать / тратить соединение DbContext / DB в течение всего этого срока жизни (это быстро приведет к исчерпанию), а вместо этого временно получать соединение с БД, когда приходит сообщение и требуется ответ; немедленно отбрасывая DbContext / connection - хотя исходный HTTP-запрос, который технически настраивал websocket в самом начале пользовательской сессии, все еще существует.
Я не смог найти ничего другого, кроме используя:
httpContext.RequestServices.GetService(typeof(<MyNeededDbContext>)
Таким образом, я использую исходный httpContext (полученный через DI, когда был настроен websocket), но несколько раз после этого, когда сообщение websocket требует ответа, я могу запросить временный объект службы (в данном примере это DbContext), который может быть переработан или объединен после завершения ответа на сообщение, но хотя исходный httpContext еще очень активен.
Кто-нибудь знает о лучшем подходе?