如何在不改變基礎架構的情況下在一個asp.net webforms組件（DotNetNuke模塊）中使用IoC？

Question

我正在研究DotNetNuke模塊中的遺留代碼，試圖在測試框架下獲取類和行爲：我藉此機會遵循「有效地使用遺留代碼」一書的建議，所以會發生什麼呢？我試圖定義可以徹底測試並轉換爲服務的區域。然後我想使用一個IoC框架來工作。現在，我已經開始關注Ninject。

但是我碰到一個設計問題：因爲我在DotNetNuke模塊中，我不能真正改變應用程序範圍的結構：例如我不能從NinjectHttpApplication派生應用程序。我也不能使用these suggestions from SO。 我正在考慮讓我的模塊將設置然後使用的靜態類中的內核，但從我讀過這是一個非常糟糕的主意。

所以我開始問自己是否可以在一個應用程序中使用IoC，這個應用程序還沒有被設置爲從頭開始支持它。如果我應該爲每個請求加載一個完整的依賴關係樹，我如何重寫本地代碼並從IoC中受益？有沒有一種模式可以從當地的重寫中使用IoC？

即使我正在使用DotNetNuke，任何可以安裝到獨立框架中的獨立組件都會引發同樣的問題。另外，我並沒有專門針對Ninject，如果另一個IoC框架可以幫助在這種情況下，我願意考慮它。

Answer 1

根據我的經驗，在DotNetNuke的上下文中獲得此類抽象類型的最佳方法是使用WebFormsMVP框架。這真的是我發現在DNN模塊中進行單元測試的唯一理智方法，如果內存服務，我花了一段時間嘗試連接Ninject大約一年前。

但是要警告，它仍然是WebForms，並且永遠不會簡單。如果不知道現有的代碼庫，我很難知道遷移的容易程度。

我已經在GitHub上使用的資源，你可以檢查出來以供參考：

首先，應作爲一個堅實的起點扮演一個模塊模板：

https://github.com/irobinson/WebFormsMvp-DNN-Module-Template

第二是一個小例子項目：

https://github.com/irobinson/BeerCollectionMVP

根據版本您正在使用的DNN，它可能已經或可能不會隨WebFormsMVP一起提供，但您應該能夠將模塊的依賴關係捆綁在一起，或者如果合理的話，可以升級到較新版本的DNN。