ASP.NET Core MVC 中是否继续支持 Ninject？

Question

我很高兴使用Ninject 已经很长时间了，我真的很喜欢它，但是自从ASP.NET Core 和MVC Core 发布以来，我面临着一个艰难的选择。

基本上，微软已经公开了他们自己的依赖注入系统；据我所知，这是一个受到很多批评的地方。但我更大的问题在于它如何影响其他库。

从another question I asked 和other resources online 看来，Ninject 似乎不适用于 MVC Core。尽管以详细库Microsoft.Framework.DependencyInjection.Ninject and Ninject 的形式给出了一个“解决方案”。这更加棘手，因为该库需要将 https://www.myget.org/F/aspnetmaster/ 添加到您的 NuGet 提要列表中。

我已经进行了一些挖掘并找到了该库的托管位置；它看起来不错，据我所知，它似乎工作正常，但有一些事情让我感到困扰。

• 图书馆似乎并没有真正由 Ninject 创建者领导
• 图书馆深埋在一个不起眼的存储库中
• 网上实际的 Ninject 资源从不提及

所以基本上，我非常担心这是某种创可贴，并且对 Ninject（甚至其他容器库）的支持正在消失。是否有一些我没有发现的隐藏信息？

Answer 1

现有 DI 库的维护者之间正在讨论是否为新的 ASP.NET 内置 DI 系统构建、维护和支持适配器。 Autofac 维护者有confirmed，他们将创建并支持适配器，而 Ninject 团队一直是 silent，而其他团队，如 Simple Injector 团队（包括我）have explained，他们将不支持适配器。

我个人认为 ASP.NET Core 内置的 DI 库是一个不错且干净的 DI 库，但仅限于简单的应用程序。正如我所解释的here，不支持开发围绕 SOLID 原则构建的可维护应用程序所需的许多功能。然而，就像几年前 Unity DI 库所做的那样，我认为这个内置容器实际上可能会触发开发人员开始使用依赖注入，这对我们的行业来说是一个胜利。

这些限制使得内置容器特别适合配置和扩展 ASP.NET 系统本身。要构建大型可维护应用程序，您将需要使用不同的 DI 库。这当然很好；您必须为工作选择合适的工具。

不幸的是，到目前为止，ASP.NET 团队已告知publicly，使用不同的 DI 库意味着您必须编写/使用适配器。不幸的是，这是 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 兼容的版本（以防您的产品需要在该新平台上运行）。

更新：“Ninject 3.3.0 于 2017 年 9 月 26 日发布，现在针对 .NET Standard 2.0，因此也可以在 .NET Core 2.0 上运行。” source

因此，简而言之，我不确定支持“正在消失”，尽管一些 DI 维护人员（例如 Simple Injector 团队，可能还有 Castle Windsor 和 Ninject）选择不构建、维护和支持 ASP.NET Core 的适配器实现，因为它不是必需的，只是碍事。

2016 年 11 月更新

我已经discussing some improvements 加入了 Microsoft 的 ASP.NET Core，以便更轻松地插入没有适配器的容器（看看我的 example repository，尤其是 Startup.cs of the Ninject sample project），但直到现在，微软似乎停滞不前，因为（正如 Fowler 自己所说）他们的“bias towards conforming containers [正在] 模糊 [他们] 的愿景”。

Answer 2

• 图书馆似乎并没有真正由 Ninject 领导 创作者

那个库，看起来是these also，看起来是微软创建的依赖注入提供程序样本removed in beta7。请注意，您的original question 引用的DI in MVC 6 链接说明如下；

这些 DI 容器适配器是临时的，可供参考； 我们预计它们最终会被移除并由 各自的容器所有者。

正如他们应该的那样。 Microsoft 不应负责维护第 3 方提供商。

• 图书馆深埋在一个不起眼的存储库中

如果您不知道，ASP.NET 5 仍在开发中。 Beta 7 在 nuget 上作为预发布版本提供，但还有其他来源，包括：

• https://github.com/aspnet/（源代码）
• https://www.myget.org/gallery/aspnetvnext（上面的nuget dev分支构建）
• https://www.myget.org/gallery/aspnetmaster（上述的nuget master分支构建[与您的问题相同]）

这些来源由 Microsoft 维护。

• 网上实际的 Ninject 资源从不提及

与任何新开发一样，第 3 方库提供商必须自己确定何时（如果有的话）他们将提供支持新代码库的产品实现。对一些人来说，等到新框架正式发布被认为是最有效的，因为在那之前仍然很有可能发生 API 重大更改。是否会实施支持当然取决于提供者的资源，和/或在开源的情况下由社区决定。