繼續ASP.NET MVC 6中的Ninject支持？

Question

我一直非常高興地使用Ninject很長一段時間，而且我非常喜歡它，但自ASP.NET 5和MVC 6發佈以來，我面臨着一個困難的選擇。微軟公司基本上走出了門戶，透露了自己的依賴注入系統;據我所知，這是一個很多批評。但是我更大的問題在於它如何影響其他圖書館。

從another question I asked和other resources online，似乎Ninject不開箱與MVC 6.工作，雖然有一個「解決方案」的詳細庫Microsoft.Framework.DependencyInjection.Ninject and Ninject的形式給出。這更加棘手，因爲該庫需要將https://www.myget.org/F/aspnetmaster/添加到您的NuGet訂閱源列表中。

我已經做了一些挖掘並找到了這個庫的託管位置;它看起來很好，它似乎可以從我能說的很好，但有幾件事情讓我感到困擾。

• 庫並沒有真正出現在Ninject創
• 庫埋藏很深的一個不起眼的倉庫領導
• 實際Ninject資源在線別說

所以基本上，我非常擔心這是某種形式的助手，對Ninject（甚至其他容器庫）的支持正在消失。是否有一些隱藏的信息，我只是沒有發現？

Answer 1

• 庫並沒有真正出現在Ninject 創

那個圖書館領導，而且它似乎these also，看起來是微軟創建了依賴注入提供的樣品是是removed in beta7。請注意，您的original question引用的DI in MVC 6鏈接指出以下內容;

這些DI容器適配器是臨時的，供參考;我們預計他們最終將被移除並由相應的容器所有者替換爲 。

因爲他們應該。微軟不應該負責維護第三方提供商。

• 如果你不知道該庫埋藏很深的一個不起眼的倉庫

，ASP.NET 5仍然在發展。Beta 7可在nuget上作爲預發佈版本使用，但也有其他來源，包括：

• ​​（源代碼）
• https://www.myget.org/gallery/aspnetvnext（的NuGet Dev分支的生成的上述說明）
• https://www.myget.org/gallery/aspnetmaster（的NuGet主分支建立上述的[與您的問題]）

這些來源由Microsoft維護。

• 實際Ninject資源在線別說

正如任何新的發展，第三方庫供應商必須自己決定什麼時候（如果有的話），他們將提供他們的產品的實現支持新的代碼庫。對於一些人來說，等到新框架正式發佈時纔會被認爲是最有效率的，因爲在此之前API破解的變化仍然很有可能發生。當然，支持是否會得到實施當然取決於提供者資源，並且/或者開源社區。

Answer 2

在現有的DI庫的維護人員之間正在進行討論，無論是否構建，維護和支持新的ASP.NET內置DI系統的適配器。 Autofac維護者有confirmed，他們將創建和支持一個適配器，而Ninject團隊已經，以及其他團隊，如簡單注入器團隊（包括我）have explained，他們將不支持一個適配器。我個人認爲，ASP.NET Core內置的DI庫是一個不錯的，乾淨的DI庫，但它僅限於簡單的應用程序。正如我所解釋的here，不支持開發圍繞SOLID原則構建的可維護應用程序所需的許多功能。然而，就像幾年前Unity DI庫做的那樣，我認爲這個內置容器實際上可能會觸發開發人員開始使用依賴注入，這對我們這個行業來說是一個勝利。

這些限制使內置容器特別適合配置和擴展ASP.NET系統本身。要構建大型可維護應用程序，您需要使用不同的DI庫。這當然很好;你將不得不爲工作挑選合適的工具。

不幸的是，直到現在，ASP.NET團隊已經溝通了使用不同DI庫的publicly，這意味着您必須編寫/使用適配器。這不幸的是IMO的錯誤信息，因爲大多數DI庫與內置容器提供的API不兼容（如我詳細解釋here和here）。只有Autofac似乎合理同步，這就解釋了爲什麼Autofac團隊選擇維護一個適配器。但請注意，即使Autofac已被證明與Microsoft定義的抽象不兼容，並且它們（就像StructureMap）必須對其產品進行big changes才能符合抽象。關於整個過程和抽象的一般，Autofac維護者是severely frustrated。正如我解釋here，即使ASP.NET提供的Ninject適配器實現也被破壞了。

這條消息由ASP.NET團隊使用一個適配器是IMO的一個很大的錯誤，因爲這扼殺了創新（而DI庫本身沒有;它只是另一個DI庫）。 ASP。.NET團隊正在推廣一個模型，在該模型中，您的應用程序組件和ASP.NET系統（以及將來插件的所有其他子系統）將在您的自定義容器中註冊。將您的應用程序配置與ASP.NET系統的配置分開更爲合理和實用（如解釋here）。

因此，我發現使用任何容器的適配器都沒用。正如我所示，here真的很容易插入你自己的DI容器，同時保持它與ASP.NET的註冊完全分開。這意味着您不需要支持Ninject就能夠在ASP.NET Core項目上有效地使用Ninject。 Ninject唯一需要做的就是創建一個與.NET Core兼容的版本（以防您的產品需要在新平臺上運行）。所以簡而言之，雖然一些DI維護者（如Simple Injector團隊，也可能是Castle Windsor和Ninject）選擇不構建，維護，但我不確定支持是否正在消失。並支持適用於ASP.NET Core的適配器實現，因爲它不是必需的，而且僅限於此。

UPDATE 2016年11月

我一直discussing some improvements到ASP.NET核心與微軟使其更容易的插件，不帶適配器的容器（看看我example repository，尤其是到Startup.cs of the Ninject sample project ），但直到現在，微軟似乎都在阻礙進步，因爲（正如福勒說的）他們的「bias towards conforming containers [他們]混淆[他們的]願景」。