Можно ли изменить настроенный менеджер времени жизни при разрешении типа?

Question

У меня есть Unity, настроенный для разрешения нескольких типов с помощью собственного менеджера времени жизни (по запросу http). Теперь в одном специальном методе инициализации мне нужно получить свежие экземпляры структуры разрешенных типов, и я не хочу, чтобы эти экземпляры сохранялись и использовались повторно для последующих Resolve вызовов = для этого специального метода, мне нужен временный менеджер времени жизни.

Я хочу избежать конфигурации второго контейнера, потому что это будет копия первого с другими менеджерами времени жизни. Можно ли как-то переопределить конфигурацию менеджера времени жизни при разрешении типа?

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

Edit:

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

Answer 1

Вы можете использовать дочерний контейнер для особого разрешения. Просто зарегистрируйте новый менеджер времени жизни (TransientLifetimeManager звучит так, как вам нужно) в дочернем контейнере для типов, которые вам нужны. Для всего остального потребуется регистрация от родителя, поэтому вам не нужно переделывать огромные куски регистрации.

Но я согласен с Aliostad - этот дизайн пахнет неправильно, но без более подробной информации о том, что вы делаете, я не могу действительно предложить альтернативу.

Answer 2

Я думаю - как вы заметили - мы можем использовать две отдельные регистрации с двумя разными конфигурациями времени жизни. Но вы, кажется, не довольны этой настройкой, и вы хотели бы передать время жизни на момент регистрации .

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

Но, если честно, У меня есть проблема с этим подходом , даже если такой метод существовал в рамках. Контейнеры IoC удаляют знания зависимого от зависимости , но вы добавляете это знание обратно клиенту / зависимому, который против принципа IoC.