Поставщик Ninject не может разрешать типы, зарегистрированные в именованной области.

Question

Я использую расширение NamedScoped Ninject в попытке создать графы объектов, которые создаются каждый раз, когда обработчик команд создается контейнером. Другими словами, мне нужен новый график объектов для каждой команды, которая может обрабатываться соответствующим обработчиком.

Я использовал привязку .DefinesNamedScope («TopLevelOrhcestrator») при регистрации моих «обработчиков команд», поскольку они являются верхним уровнем обработки команд.

Тип в этой именованной области должен быть введен с результатом вызова метода по типу, уже зарегистрированному в этой именованной области. Я думал, что лучший способ сделать это будет с поставщиком ninject. Внутри провайдера я пытаюсь разрешить тип в надежде, что могу вызвать метод на нем, чтобы перейти в другой объект, который я создаю в этой именованной области. Проблема у меня в том, что, когда я спрашиваю IContext для экземпляра внутри провайдера клиента я получаю исключение, которое говорит: «Нет соответствующих областей не доступны, и тип объявлен InNamedScope (TopLevelOrchestrator).

context.Kernel.Get<TypeAlreadyRegisteredInScope>().MethodThatGetsAnotherDependency() 

можно ли получить типы из контейнера внутри поставщика Ninject, когда они зарегистрированы в названном объеме?

EDIT

Я извиняюсь, если использование случай кажется немного странным, я экспериментировал с некоторыми идеями о том, как управлять моими подразделениями и другими сервисами ces/менеджеров, которым может потребоваться обращение к uow для завершения бизнес-процесса. Я знаю, что его общее для единицы работы должно быть «запущено», а затем передано во все зависимости, которые могут потребоваться для участия в более крупном процессе. Я думал, что предпочел бы, чтобы мой оркестр взял подразделение фабрики труда, чтобы он мог детерминистически уничтожить UOW, и было бы понятно, кто является владельцем usecase. То, что будет предоставлено менеджерам/службам, будет прокси-сервером для единицы работы, которая будет равна нулю, пока оркестр не начнет работать с реальной единицей работы. Вот почему я пытался связать прокси-сервер с уже зарегистрированным типом у моего провайдера. В этот момент все это очень экспериментально, и он испытывал некоторые идеи.

Буду рад услышать любые дальнейшие мысли.

Answer 1

Для MethodThatGetsAnotherDependency(), чтобы иметь возможность .Get<>() экземпляр, который связан .InNamedScope(...) вам нужно будет добавить Context Preservation Extension.

Это потому, что NamedScope добавляет параметр в контекст запроса привязки, который имеет .DefinesNamedScope(...). Как только этот запрос будет завершен, этот контекст и его параметры будут забыты. Теперь с расширением ContextPreservation контекст сохраняется и повторно используется для создания последних/фабрик (Func<>, интерфейс фабрики с привязкой .ToFactory() ...). Он считает, что он должен также работать с поставщиками. Если нет, просто переключитесь на завод вместо поставщика.

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