2016-11-28 3 views
0

Мне интересно, как настроить контейнер зависимости netcore для mvc с одним экземпляром для каждого пользователя.инъекция зависимости netcore на пользователя

Согласно https://docs.microsoft.com/en-us/aspnet/core/fundamentals/dependency-injection#service-lifetimes-and-registration-options в настоящее время существует только три метода указания жизни: одиночки (один экземпляр для каждого приложения), областью действия (один экземпляр совместно в HttpRequest), транзиторной (один экземпляр каждого запроса экземпляра DI)

Имеет кто-то пытался создать экземпляр для пользователя еще? Мне было бы любопытно, как это делается - если не я, возможно, в какой-то момент, возможно, выкопаю документы, чтобы посмотреть, как это можно сделать и поделиться решением.

+0

Вы делаете экземпляр на запрос (а не на пользователя). Экземпляр доступен на протяжении всего срока службы запроса. Можете ли вы рассказать о том, как вы хотите использовать экземпляр? – alltej

+0

По сути, у меня есть контроллер входа, где я вводим учетные данные остального api. Эти экземпляры клиента клиента инициализируются учетными данными, переданными при входе в систему. поэтому мой план состоял бы в том, чтобы использовать заводский регистр для экземпляра, используя информацию i i для входа в идентификатор претензии один раз для каждого пользователя. Хотя это уже работает для каждой области/для каждой базы запросов, она является оптимальной с точки зрения производительности. – Dbl

+0

(1) Кэширование памяти с таймаутом; (2) Словарь с синглтонным покрытием с некоторым токеном в качестве ключа (идентификатор сеанса?) - вам нужна ручная очистка; (3) [CookieTempData] (https://luisfsgoncalves.wordpress.com/2016/07/29/cookie-based-tempdata-for-asp-net-core/) – Dmitry

ответ

1

Создайте экземпляр с запросом первого пользователя и сохраните его (для последующих запросов) до тех пор, пока не истечет таймаут истечения срока ... Это выглядит как Sessions.

Вы можете зарегистрировать свой сервис с заводским методом и проанализировать текущий сеанс внутри.

+0

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

+0

Будьте честны с самим собой - вы ищете что-то, чтобы смешивать DI и сеансы. Как бы вы это ни называли - это правда. Это пользовательский интерфейс. Вы можете реализовать его по-разному - скажем, создать свой собственный «Сфера» (с точки зрения DI) и поместить его в сеанс и разрешить другие службы из этой области, но вы все равно будете использовать механизм «некоторых сеансов», который использует память для каждого пользователя , не будет работать в webfarm (вы не можете сериализовать сервис и делиться им между несколькими процессами/машинами) и так далее. Если вам это не нравится (это плохо для масштабирования) - может быть, вам следует пересмотреть/переосмыслить свою архитектуру? – Dmitry

+0

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

Смежные вопросы