ASP.NET Core Controller与IOC结合问题整理

本文将介绍ASP.NET Core中Controller与IOC结合的相关问题整理。对于不了解这一内容的读者，可以将其视为一次学习的机会。

让我们明确一个结论：默认情况下，ASP.NET Core的Controller并不会被托管到IOC容器中。对于不清楚这一点的朋友们，可以通过几种方式进行验证。

最直接的方式是通过在ServiceProvider中获取某个Controller实例，例如尝试获取ProductController实例，结果很可能为null。另一种方式是通过构造注入，如在OrderController中注入ProductController。但这种写法不规范，也不合理，因此仅为了求证结果而演示。实际上，因为ProductController不在IOC容器中，所以注入会报错。

还可以利用依赖注入的一个特征进行验证。这个特征是允许类包含多个构造函数。我们可以编写两个接受不同参数的OrderController构造函数。运行后会出现错误，因为IOC容器无法确定应该使用哪个构造函数，导致出现“Multiple constructors accepting all given argument types have been found in type 'OrderController'. There should only be one applicable constructor”的错误。这个错误表明，ASP.NET Core的Controller在默认情况下并不在IOC容器中。

那么，如何解决Controller与IOC结合的问题呢？这就需要我们主动将Controller注册到IOC容器中。具体的注册方式可以通过扩展依赖注入的方式来实现。通过这种方式，我们可以将Controller所需要的服务通过构造函数注入到Controller中，从而实现Controller与IOC的结合。这样不仅可以提高代码的可读性和可维护性，还可以方便我们进行单元测试。

ASP.NET Core的Controller默认并不在IOC容器中，需要我们主动进行注册。通过这种方式，我们可以充分利用IOC的优点，实现代码的高内聚低耦合，提高代码的可读性和可维护性。对于开发者来说，理解并熟练掌握这一内容，对于提高开发效率和代码质量有着重要的意义。希望本文的整理和总结能对大家有所帮助，有需要的朋友们可以加以学习和实践。DefaultControllerFactory源码以证实Controller默认不托管于IOC

一、现象启示

在我们日常的开发实践中，有一种普遍的观念：Controller并不在IOC（控制反转）容器中默认托管。这一观念的形成，源于我们在实际项目中的观察与体验，要彻底理解并证实这一点，我们需要进一步深入源码。

二、源码的启示

为了进一步揭示真相，我们深入DefaultControllerFactory的源码。DefaultControllerFactory是ASP.NET MVC中的一个重要组件，它负责创建Controller实例。源码中会明确告诉我们，Controller实例的创建方式，以及它是否与IOC容器有关联。

通过深入研究源码，我们可以发现，DefaultControllerFactory在创建Controller实例时，并没有从IOC容器中获取，而是直接通过反射或其他方式实例化了Controller。这说明，默认情况下，Controller并不会被托管到IOC容器中。

三、结论与理解

通过源码的，我们可以确信，默认情况下，Controller并不会在IOC容器中托管。这是因为DefaultControllerFactory在创建Controller实例时，并没有与IOC容器进行交互。这也意味着，如果我们希望在MVC项目中实现依赖注入（DI），我们需要采取额外的措施，比如自定义ControllerFactory或者使用相关的DI框架。

四、深入的意义

源码的不仅让我们了解了Controller在默认情况下的托管情况，更让我们深入理解了ASP.NET MVC的工作机制。这对于我们提高技术能力，理解框架设计理念，以及在实际项目中灵活应用这些知识点，都具有重要的意义。这也提醒我们，在软件开发的过程中，要始终保持对源码的关注和学习，以便更好地理解和应用各种技术和框架。

通过源码的，我们证实了默认情况下Controller并不会在IOC容器中托管。这对于我们理解ASP.NET MVC的工作机制，以及在实际项目中进行依赖注入具有重要的指导意义。经过深入研究，我们找到了Controller工厂的注册位置，位于MvcCoreServiceCollectionExtensions类的AddMvcCoreServices方法中。在这里，我们为IControllerFactory注册了默认的Controller工厂类DefaultControllerFactory，它也是Controller创建的入口。

进一步追溯，DefaultControllerFactory在创建Controller实例时，实际上调用了IControllerActivator的Create方法。在MVC框架中，默认注册的IControllerActivator实现类是DefaultControllerActivator。DefaultControllerActivator在创建Controller实例时，又调用了ITypeActivatorCache的CreateInstance方法。最终，TypeActivatorCache实现了ITypeActivatorCache接口，并创建了Controller实例。

我们可以清晰地得出结论：默认情况下，Controller实例是由ObjectFactory创建出来的。这个ObjectFactory是通过TypeActivatorCache中的ConcurrentDictionary缓存获得的，而ObjectFactory实例是由ActivatorUtilities的CreateFactory方法创建的。这意味着每次需要创建Controller实例时，都会通过ObjectFactory来创建，而不是从IOC容器中获取。

为了更好地理解这一过程，让我们回顾一下关键代码段：

1. DefaultControllerFactory类中的CreateController方法调用了_controllerActivator的Create方法。

2. DefaultControllerActivator类中的Create方法使用了_typeActivatorCache来创建Controller实例。

3. TypeActivatorCache类中实现了CreateInstance方法，该方法用于真正创建Controller实例。

我们可以理解MVC框架中的Controller实例创建流程：当需要创建Controller实例时，会调用DefaultControllerFactory的CreateController方法，进而调用DefaultControllerActivator的Create方法，最终通过TypeActivatorCache的CreateInstance方法创建出Controller实例。这个过程并不涉及从IOC容器中获取Controller实例，而是由ObjectFactory负责创建。当我们关于软件编程和架构的深层逻辑时，其中涉及到的核心部分之一是依赖注入与对象的创建。这里的ObjectFactory，实际上是一个委托，扮演着创建对象的重要角色。当我们深入其定义和应用时，会发现它与我们常见的依赖注入模式紧密相连。现在，让我们来深入理解一下ObjectFactory背后的机制，并ActivatorUtilities的神秘面纱。

ObjectFactory通过IServiceProvider实例来构建类型的实例。这个委托与IOC容器（控制反转容器）紧密相连，它负责对象的生命周期管理、依赖关系的等核心功能。当Controller实例被创建时，ObjectFactory会根据给定的参数类型和数量来查找相应的构造函数，进而在IServiceProvider中找到已注册的相关类型实例。这是一个典型的依赖注入过程。而这个过程的核心，就隐藏在ActivatorUtilities类中。

接下来，我们来一下ActivatorUtilities类的功能。这个类似乎是一个神秘的组件，负责创建Controller实例的最底层操作。当我们在源码中寻找答案时，会发现它主要是通过CreateFactory方法来创建ObjectFactory实例的。在这个方法中，有一系列的复杂操作：查找合适的构造函数、获取构造信息、在IServiceProvider中获取相应的实例为构造函数赋值等。这一系列的操作都是为了初始化给定的Controller类型实例。在这个过程中，ActivatorUtilities的工作是遍历Controller类型的构造函数参数，然后根据每个参数的类型在IServiceProvider中查找已注册的实例，最终完成Controller实例的初始化。这是一个非常关键的过程，因为它确保了依赖注入的正确性和对象的正确创建。

我们可以从上述流程中得出结论：Controller实例的初始化过程实际上是通过依赖注入实现的。它依赖于IServiceProvider来提供已经注册到容器中的相关类型实例，然后通过ObjectFactory来创建和初始化Controller实例。这个过程确保了代码的解耦和模块化，使得软件更加灵活和可维护。在这个过程中，ActivatorUtilities起到了至关重要的作用，它通过一系列的底层操作确保了对象的正确创建和初始化。这样的设计模式在软件开发中非常常见，尤其是在使用依赖注入框架和IOC容器时。通过理解这个过程，我们可以更好地掌握软件的架构设计和开发实践。理解并创建所需的依赖关系实例 —— iServiceProvider中的角色与ActivatorUtilities的魔力

在软件开发中，我们常常会碰到这样的问题：如何获得所需依赖关系的实例？特别是在使用IServiceProvider时，它是如何帮助我们在应用程序中获取这些实例的呢？接下来，我们将深入了解其背后的工作原理，特别是当涉及到ActivatorUtilities类时。

当我们谈论依赖注入时，我们实际上是在谈论如何从一个容器或提供者中获取对象实例，这些实例可能是服务、控制器或其他任何类型的对象。在ASP.NET Core中，IServiceProvider充当这一角色。它不仅为我们提供了所需的对象实例，还处理了对象的生命周期管理。这一切的背后是复杂的逻辑和机制，其中之一就是ActivatorUtilities类。

想象一下你有一个OrderController类，它依赖于某些服务如IOrderService和IPersonService。这些服务在IOC容器中被注册，但Controller本身并没有注册。但你仍然需要创建OrderController的实例并注入这些依赖项。这时候，ActivatorUtilities的CreateInstance方法就显得尤为重要了。这个方法可以创建指定类型的实例，并通过构造注入的方式将IServiceProvider中的相关依赖注入到该实例中。即使没有注册OrderController本身，只要它的依赖项在容器中，你就可以轻松地获取到完整的OrderController实例。

除了上述功能外，为了让Controller真正地受到IOC容器的托管，还需要进行额外的操作。需要将Controller注册到IOC容器中。但这还不够，因为Controller是由ControllerFactory创建的。我们需要改造ControllerFactory中的创建Controller实例的逻辑，使其从IOC容器中直接获取Controller实例。

这样，我们可以说：通过IServiceProvider和ActivatorUtilities的结合使用，我们可以轻松管理应用程序中的依赖关系，确保对象得到正确的初始化并注入所需的依赖项。这不仅简化了代码，还提高了应用程序的可维护性和可扩展性。对于那些想要深入了解这一领域工作原理的开发者来说，查看和了解ActivatorUtilities的源码是一个很好的起点。通过这种方式，你可以更深入地理解它是如何通过构造注入的方式创建并管理对象实例的。

微软为我们提供了一个神奇的方法，它像是一把钥匙，帮助我们打开将Controller托管到IOC容器的大门。这个方法的使用非常简单，只需像下面这样轻松调用：

```csharp

services.AddMvc().AddControllersAsServices();

```

或者根据你的Web项目需求，选择使用WebApi、Mvc、RazorPage等不同的构建方式，再调用相应的方法，比如`services.AddMvcCore().AddControllersAsServices();`。

大家注意看，关键就在于`AddControllersAsServices`这个方法。它隐藏在MvcCoreMvcBuilderExtensions类和MvcCoreMvcCoreBuilderExtensions类中，虽然类名不同，但它们的代码是完全一样的，这并不会给我们带来困扰。因为这些类只是构建Web项目的工具之一，我们可以根据需要使用AddMvc或者AddMvcCore等方式来构建我们的项目。接下来，让我们深入了解一下这个方法是如何工作的。

这个方法的核心功能有两点：一是将Controller实例添加到IOC容器中；二是替换原本的DefaultControllerActivator为ServiceBasedControllerActivator。我们逐一。

它将每一个Controller实例添加到IOC容器中。这个过程非常直观明了，它遍历所有的Controller，并将它们以Transient生命周期注册到服务容器中。这意味着每次需要Controller实例时，都会从容器中获取一个新的实例。

它替换了原本的DefaultControllerActivator为ServiceBasedControllerActivator。DefaultControllerActivator是默认提供Controller实例的地方，而ServiceBasedControllerActivator则通过服务容器来获取Controller实例。这种改变使得Controller的实例化过程更加灵活和高效。让我们看看ServiceBasedControllerActivator的代码来了解它是如何工作的。

ServiceBasedControllerActivator类实现了IControllerActivator接口。它的Create方法用于创建Controller实例。当需要创建Controller实例时，它会根据ActionContext中的信息获取对应的Controller类型，然后从服务容器中获取该类型的实例。这种方式更加灵活和高效，因为它可以根据需要创建不同的Controller实例。Release方法则用于释放Controller实例，但在这里并没有具体的实现。

微软提供的这个方法为我们解决了将Controller托管到IOC容器的问题，使得Web项目的构建更加灵活和高效。通过上面的，相信大家对这个方法有了更深入的了解。关于ServiceBasedControllerActivator的Release方法未实现的问题，确实令人费解。但这正是依赖注入框架设计的巧妙之处。当我们深入其背后的原理时，会发现Controller的生命周期及其相关资源的释放，其实是由IOC容器全权管理的。Controller的释放操作在IOC容器内部已经完成，无需额外操作。这也体现了IOC容器的高度智能化和自动化特性。

当我们注册Controller实例时，采用TryAddTransient方法，意味着每次请求都会创建一个新的Controller实例。这样的设计有其深刻的考虑，特别是在使用如EFCore等需要作用域为Scope的服务时。如果将Controller注册为单例，在EFCore等场景下可能会导致一些意想不到的问题。Transient注册方式可能是一种更安全和灵活的选项。如果你确信你的应用不需要考虑此类问题，也可以选择其他生命周期注册方式，但这并非推荐做法。

谈及与Autofac的结合时，我们注意到Autofac是一个功能强大的IOC框架，它支持属性和构造两种注入方式。为了在.Net Core中与Autofac无缝集成，我们只需进行简单的配置即可。在创建HostBuilder时，将ServiceProviderFactory设置为AutofacServiceProviderFactory，即可启用Autofac作为我们的IOC容器。微软为我们提供了便捷的方法，通过services.AddMvc().AddControllersAsServices()可以将Controller注册到Autofac容器中。

为了让Controller支持属性注入，除了默认的构造注入方式外，我们还需要进行一些额外的配置。幸运的是，Autofac提供了丰富的扩展方法和插件来实现这一需求。我们可以通过自定义的方式来实现属性注入。具体实现方式可能会涉及到反射和自定义的注入策略等高级技术。这些技术可以帮助我们灵活地管理依赖关系，提高代码的可维护性和可扩展性。具体的实现细节可能会因版本和具体需求而有所不同，建议查阅的官方文档或相关资料以获取更准确的信息。

当我们谈论ASP.NET Core的Controller时，我们必须解决一个核心问题：如何妥善地管理这些Controller的实例？如何让它们与IOC容器无缝结合，以实现依赖注入的强大功能呢？这不仅仅是一个技术难题，更是我们每一个开发者都需要掌握的核心技能。

为了让Controller成功托管到Autofac中，并支持属性的自动注入，我们需要采用Autofac的注册方式。这一切的神奇操作，都源于在Startup类中添加的ConfigureContainer方法。在这里，我们将对Controller进行注册，并声明我们希望实现属性的自动注入。

代码示例：

```csharp

public void ConfigureContainer(ContainerBuilder builder)

{

var controllerBaseType = typeof(ControllerBase);

// 扫描所有的Controller类

builder.RegisterAssemblyTypes(typeof(Program).Assembly)

.Filter(t => controllerBaseType.IsAssignableFrom(t) && t != controllerBaseType) // 确保只注册Controller类，不包括ControllerBase本身

// 为这些Controller类的属性实现自动注入

.PropertiesAutowired();

}

```

解决了注册问题后，我们面临的是如何取得这些已经注册的Controller实例。这时，我们不再需要使用AddControllersAsServices方法，因为它主要解决的是Controller实例在IOC中的存储和获取问题。为了支持属性注入，我们只需要使用ServiceBasedControllerActivator即可。具体操作非常简单：

```csharp

services.Replace(ServiceDescriptor.Transient());

```

仅仅通过这两步操作，我们就能成功将Controller托管到Autofac中，并享受属性注入带来的便利。这是一种合理且高效的方式。使用AddControllersAsServices也能达到同样的效果，但有时候我们不需要将容器重复地放入容器中。这就是今天的重点！让我们一起回顾一下本文的主要内容：我们了解了一个现象——默认情况下Controller并不在IOC容器中。接着，我们通过几个示例验证了这一点。然后，我们深入了如何通过将Controller与IOC容器结合来提高开发效率和灵活性。我们展示了一种最合理的方式来实现这一目标。希望这篇文章能为大家在日常的Web开发中带来一些启示和帮助。狼蚁SEO团队会持续为大家带来有关ASP.NET Core开发的相关知识和技巧，敬请期待和支持！