Могу ли я указать область действия в Ninject только для этой конкретной ситуации?

Ранее я задавал этот вопрос . Ответ на который привел к другому вопросу, подобному тому, что ты видишь перед собой.

Первоначальная проблема

Моя проблема в том, что у меня есть собственный MembershipProvider , использующий AccountRepository с использованием ObjectContext . Поскольку MembershipProvider является Singleton в MVC (насколько я понимаю), AccountRepository и его ObjectContext должны быть введены один раз и оставаться там до конца срока службы MembershipProvider .

Однако в своих контроллерах я также использую репозитории с контекстами объектов. В этих контроллерах мне нужно, чтобы контекст объекта был разделен между репозиториями с помощью запроса. У меня есть следующая привязка:

Bind().To().InRequestScope();
// put bindings here
Bind().To

и в Application_Start ()

kernel.Inject(Membership.Provider);

Проблема в том, что Ninject явно вызывает dispose в контексте объекта, когда считает, что запрос выполнен (я думаю, через 30 секунд).

Мое (неработающее) решение

Я заметил, что когда вы устанавливаете свои привязки, вы можете указать «при введении в». Проблема в том, что мне нужно "при вливании при вливании". Т.е. при внедрении контекста объекта в контроллер учетных записей при внедрении контроллера учетных записей в поставщика членства. И, похоже, у меня этого нет ...

Обходы, которые я придумал (но мне не очень нравится).

  1. Не вешайте MyMembershipProvider в MVC. Просто передайте его (позади и интерфейс) контроллерам, которые в нем нуждаются, как я делаю с репозиториями. Затем Ninject будет создавать экземпляр провайдера для каждого запроса. Мне это не нравится, потому что я уверен, что у MVC есть причина для создания экземпляра поставщика членства как синглтона.
  2. Найдите событие, которое происходит при каждом запросе, и вызовите kernel.Inject снова в каждом событии. Повторная инициализация провайдера при каждом запросе почти эквивалентна повторной инициализации, кроме грязных.
  3. Создайте отдельный репозиторий учетных записей для поставщика членства, к которому я могу привязаться другим способом. Мне кажется неправильным изменять мою объектную модель из-за Ninject.

Заключение

ИМХО, первый обходной путь - лучший. Однако я предпочитаю найти способ настроить Ninject для привязки так, как я хочу.

Что мне делать?

5
задан Community 23 May 2017 в 12:04
поделиться