2014-09-10 72 views
0

我正在使用NamedScoped Ninject擴展來嘗試創建每次由容器構造命令處理程序時構造的對象圖。換句話說,我需要一個新的對象圖表來表示每個可能由相應處理程序處理的命令。Ninject提供程序無法解析在命名範圍內註冊的類型

我在註冊我的「命令處理程序」時使用了.DefinesNamedScope(「TopLevelOrhcestrator」)綁定,因爲它們是命令處理的頂層。

此命名範圍中的類型需要注入方法調用的結果,該方法調用的結果已在此命名範圍中註冊。我認爲最好的方式是使用ninject提供程序。 在提供程序內部,我試圖解析該類型,希望我可以調用其上的一個方法來傳遞到我在此命名範圍內創建的另一個對象。我遇到的問題是,當我問IContext爲客戶提供內部的情況下,我得到,說:「沒有符合條件的範圍是可用的,並且類型聲明InNamedScope(TopLevelOrchestrator)例外。

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

是否有可能從當他們被一個名叫範圍內註冊的Ninject提供商容器內部獲得的類型?

編輯

我道歉,如果使用案例似乎有點奇怪,我有一些想法試驗關於如何管理我的工作單位和其他服務可能需要處理uow來完成業務用例的ces /管理員。我知道它的共同之處是工作單元要「開始」,然後傳遞到可能需要參與更大進程的所有依賴項。我想我寧願讓我的管絃樂隊帶着一個工作單位工作,這樣它就可以確定地摧毀UOW,並且很清楚誰是一個用例的擁有者。提供給管理人員/服務的內容將是工作單元的代理,在協調人啓動真正的工作單元之前,這些工作單元將爲空。這就是爲什麼我試圖從我的提供商中的已註冊類型鏈接代理。這一點都是非常實驗性的,並且正在測試一些想法。

我很樂意聽到任何進一步的想法。

回答

0

對於MethodThatGetsAnotherDependency()能夠.Get<>()一個綁定.InNamedScope(...)的實例,您將需要添加Context Preservation Extension

這是因爲NamedScope正在向具有.DefinesNamedScope(...)的綁定的請求上下文添加一個參數。只要該請求結束,該上下文及其參數就會被遺忘。現在使用ContextPreservation擴展,上下文被保留並重用於後期/工廠創建(Func<>,接口工廠,綁定爲.ToFactory() ...)。它認爲它也應該與供應商合作。 如果不是,只需切換到工廠而不是提供者。

但是,我不得不承認,我不完全理解你爲什麼/你試圖達到什麼目的。可能有更簡單的方法。

+0

我添加上下文保存擴展,不得不爲了在上下文中使用GetContextPreservingResolutionRoot()的情況下才能夠解決的命名範圍類型: 回報context.GetContextPreservingResolutionRoot()獲取()。 MethodThatGetsAnotherDependency(); – 2014-09-10 15:16:57

相關問題