.NET Core迁移：Ninject未绑定类型自动解析特性替代咨询

首先直接回应你的问题：你的理解完全正确——Ninject确实支持无需预先绑定就能解析类型的功能，这叫做「隐式绑定」（Implicit Binding）。

Ninject隐式绑定的工作原理 #

Ninject默认会自动尝试解析未注册的类型：

• 如果目标类型有无参数构造函数，Ninject会直接调用它创建实例；
• 如果目标类型的构造函数带有依赖，Ninject会递归尝试解析这些依赖项（只要依赖项本身能被Ninject解析，不管是显式绑定还是隐式绑定的）。

举个实际例子，假设你有这样的类：

public class UserService
{
    private readonly IUserRepository _repo;

    public UserService(IUserRepository repo)
    {
        _repo = repo;
    }
}

只要IUserRepository已经在Ninject中绑定了具体实现，哪怕你没注册UserService，调用kernel.Get<UserService>()也能成功创建实例——Ninject会自动帮你注入IUserRepository的实例。

.NET Core自带DI的情况 #

很遗憾，.NET Core内置的Microsoft.Extensions.DependencyInjection容器不支持这种隐式绑定——它要求所有需要解析的类型必须显式注册（不管是注册具体类型，还是接口到实现的映射）。如果尝试解析未注册的类型，会直接抛出InvalidOperationException。

如果你需要保留类似Ninject的隐式解析能力，有两种可行方案：

方案1：扩展内置DI容器

你可以自己编写扩展逻辑，当DI容器无法找到注册类型时，尝试通过反射创建实例并解析其依赖。.NET Core提供了ActivatorUtilities工具类，可以简化这个过程：

public static class ServiceProviderExtensions
{
    public static T GetOrCreate<T>(this IServiceProvider provider)
    {
        try
        {
            return provider.GetRequiredService<T>();
        }
        catch (InvalidOperationException)
        {
            // 使用ActivatorUtilities创建实例并自动解析构造函数依赖
            return ActivatorUtilities.CreateInstance<T>(provider);
        }
    }
}

不过要注意：

• 这个简单实现只处理了基础场景，你可能需要额外处理构造函数重载选择、循环依赖、可选依赖等复杂情况；
• 隐式绑定会让依赖关系变得不透明，后期调试和维护成本更高，建议谨慎使用。

方案2：使用支持隐式绑定的第三方DI容器

如果不想自己造轮子，可以选择和Ninject行为类似的第三方容器，比如：

• Autofac：支持自动解析未注册的类型，仅需简单配置就能和.NET Core的DI系统无缝集成；
• SimpleInjector：也提供了自动注册特性，不过需要手动开启相关配置项。

这些容器都能很好地替代Ninject，同时保留你习惯的隐式解析能力。

额外建议 #

虽然隐式绑定很方便，但.NET Core内置DI设计成显式注册，是为了让依赖关系更清晰，避免意外引入不必要的依赖。迁移过程中，建议先梳理所有通过隐式绑定使用的类型，评估是否可以改为显式注册——这会让你的代码更符合.NET Core的设计理念，也更易于长期维护。

内容的提问来源于stack exchange，提问作者Stuart.Sklinar