我們正在編寫一個充當服務網關的nuget包。其職責是將呼叫打包到外部服務,以便以正確的方式完成,並且正確處理響應。其目的是在新客戶想要使用外部服務時減少開發時間開銷。使用依賴注入設計Nuget包
nuget包是從一個名爲'client'的項目中,在外部服務的解決方案中構建的。這是這樣的,客戶端項目可以共享一個公共域,並保持內部版本號在發佈時保持同步。客戶端項目應用了控制原理的倒置,意味着充當入口點的類(從外部服務獲取響應的堆棧的開始)具有許多接口依賴性。
我們通常使用StrucutreMap作爲我們的IoC容器,但我想知道我們如何配置我們使用依賴注入「內置的」客戶端項目?看起來錯誤的是,每個消費者都需要爲包裝提供依賴關係解決方案。但是,也不應該這樣,每個客戶端都應該使用StructureMap,並且必須將「ClientRegistry」(初始化程序)類添加到其自己的啓動邏輯中。
有沒有什麼指導原則可以幫助解決這個問題?或者是基於IoC原則構建的複雜nuget包的好例子?
請注意,CSL只提供Resolve功能,但您可以添加第二個與StructureMap集成的「MyNyGetPackage.Integration.StructureMap」。 – Steven
我對CSL進行了一些閱讀,我可以看到它的好處,但我仍然對如何解決問題感到困惑。我應該試圖公開一個IServiceLocator的實現,消耗的應用程序可以'附加'到它自己的IoC設置中嗎?還是我僅僅依靠現有的消費和調用'ServiceLocator.SetLocatorProvider'用的容器,這只是內部的客戶在某種初始化任務的CSL參考?採用這種方法是不是有覆蓋消費者現有容器的風險? – Nick
@尼克啊我想我明白你來自哪裏。在這種情況下,我看到一些內部使用autofac的項目(即內部設置和autofac被融入程序集),然後將工廠對象暴露給外部世界。工廠隨後成爲包裝及其內容的主要入口點。 – MattDavey