ASP.NET Core MVC创建控制器与依赖注入讲解

默认的IControllerActivator

在 ASP.NET Core 中,当 MVC 中间件接收到请求时,通过路由选择要执行的控制器和操作方法。为了实际的执行操作, MVC 中间件必须创建所选控制器的实例。

创建控制器的过程依赖众多不同的提供者和工厂类,但最终是由实现IControllerActivator接口的实例来决定的。实现类只需要实现两个方法:

public interface IControllerActivator
{
    object Create(ControllerContext context);
    void Release(ControllerContext context, object controller);
}

如您所见,该IControllerActivator.Create方法传递了用于创建控制器的ControllerContext实例。控制器的创建方式取决于具体的实现。

众所周知,ASP.NET Core 使用的是DefaultControllerActivator,它通过TypeActivatorCache来创建控制器。TypeActivatorCache通过调用类的构造函数,并试图从 DI 容器中解析构造函数所需参数的实例。

有一点很重要,DefaultControllerActivator 不会试图从 DI 容器中解析控制器的实例,只会解析控制器的依赖项。

DefaultControllerActivator 示例

为了演示这个行为,我创建了一个简单的 MVC 应用程序,包括一个单一的服务和一个控制器。服务实例有一个name属性,它通过构造函数来设置。默认情况下,它使用"default"作为默认值。

public class TestService
{
    public TestService(string name = "default")
    {
        Name = name;
    }

    public string Name { get; }
}

在应用程序中HomeController依赖于TestService,并返回Name属性的值:

public class HomeController : Controller
{
    private readonly TestService _testService;
    public HomeController(TestService testService)
    {
        _testService = testService;
    }

    public string Index()
    {
        return "TestService.Name: " + _testService.Name;
    }
}

还有一块代码在Startup文件中。在这里我将TestService注册在 DI 容器中作为范围内服务,并设置 MVC 中间件和服务:

public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
        services.AddMvc();

        services.AddScoped<TestService>();
        services.AddTransient(ctx =>
            new HomeController(new TestService("Non-default value")));
    }

    public void Configure(IApplicationBuilder app)
    {
        app.UseMvcWithDefaultRoute();
    }
}

您会注意到,我定义了一个工厂方法用于创建HomeController的实例。将HomeController类型注册到 DI 容器中,并且在TestService实例中传递自定义Name属性。

如果您运行应用程序,您会看到什么结果?

您可以看到,该TestService.Name属性使用的是默认值,表示TestService实例是直接从 DI 容器中获取的,直接忽略了创建HomeController的工厂方法。

这很容易理解,当您通过DefaultControllerActivator创建控制器时,它不会从DI容器中创建HomeController实例,只会解析构造函数的依赖项。

大多数情况下,使用DefaultControllerActivator是一个不错的选择,但有时您可能希望直接通过 DI 容器来创建控制器,比如您希望使用具有拦截器或装饰器等功能的第三方容器。

幸运的是,MVC 框架包含了一个这样的IControllerActivator实现,并提供了一种非常方便的扩展方法来启用它。

ServiceBasedControllerActivator

如您所见,DefaultControllerActivator使用TypeActivatorCache来创建控制器,MVC还包括另一个实现,称为 ServiceBasedControllerActivator,它是直接从 DI 容器中获取控制器。它的实现非常简单:

public class ServiceBasedControllerActivator : IControllerActivator
{
    public object Create(ControllerContext actionContext)
    {
        var controllerType = actionContext.ActionDescriptor.ControllerTypeInfo.AsType();

        return actionContext.HttpContext.RequestServices.GetRequiredService(controllerType);
    }

    public virtual void Release(ControllerContext context, object controller)
    {
    }
}

当您将 MVC 服务添加到应用程序时,可以使用AddControllersAsServices()扩展方法配置基于 DI 的激活器:

public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
        services.AddMvc()
                .AddControllersAsServices();

        services.AddScoped<TestService>();
        services.AddTransient(ctx =>
            new HomeController(new TestService("Non-default value")));
    }

    public void Configure(IApplicationBuilder app)
    {
        app.UseMvcWithDefaultRoute();
    }
}

通过上面的代码,点击主页将通过 DI 容器来创建一个控制器。由于我们已经注册了一个创建HomeController的工厂方法,我们自定义TestService配置将被保留,使用替换后的Name属性:

AddControllersAsServices方法实现了两件事情 - 它将您应用程序中的所有控制器注册到 DI 容器(如果尚未注册),并将IControllerActivator注册为ServiceBasedControllerActivator

public static IMvcBuilder AddControllersAsServices(this IMvcBuilder builder)
{
    var feature = new ControllerFeature();
    builder.PartManager.PopulateFeature(feature);

    foreach (var controller in feature.Controllers.Select(c => c.AsType()))
    {
        builder.Services.TryAddTransient(controller, controller);
    }

    builder.Services.Replace(ServiceDescriptor.Transient<IControllerActivator, ServiceBasedControllerActivator>());

    return builder;
}

如果需要做一些更复杂的事情,您可以随时实现自己IControllerActivator;不过我找不到任何理由,这两点实现还不能满足您的需求!

总结

  • 默认情况下,在ASP.NET Core MVC 中IControllerActivator配置为DefaultControllerActivator
  • DefaultControllerActivator使用TypeActivatorCache来创建控制器。它从 DI 容器加载构造函数所需参数来创建控制器的实例。
  • 您也可以使用ServiceBasedControllerActivator作替代方法,它直接从 DI 容器加载控制器。您可以在Startup.ConfigureServices方法中使用MvcBuilderAddControllersAsServices()扩展方法来配置此激活方式。

到此这篇关于ASP.NET Core MVC创建控制器与依赖注入的文章就介绍到这了。希望对大家的学习有所帮助,也希望大家多多支持我们。

(0)

相关推荐

  • ASP.NET Core  依赖注入框架的使用

    目录 一.IoC框架 二.IoC-Autofac 三..NET Core中自带DI的使用 四.Autofac 使用 五.批量注入 前言: 还记得上篇文章中ASP.NET Core 依赖注入详细最后提及到,假如服务越来越多怎么处理呢,本篇文章将会带来解决办法.这篇是接上一篇文章的,概念方面的可以参考上一篇文章. 一.IoC框架 先说说常见的Ioc框架吧. Autofac: 目前net用的比较多,好多大佬的项目比较优先选择的框架. Ninject: 已经很少用了,还时在很早的文章中见过. Unity

  • Asp.Net Core控制器如何接收原始请求正文内容详解

    主要目标 在Asp.net Core控制器中,通过自定义格式化程序来映射自定义处理控制器中的"未知"内容.本文将给大家详细介绍关于Asp.Net Core控制器接收原始请求正文内容的相关内容,分享出来供大家参考学习,下面话不多说了,来一起看看详细的介绍吧 简单案例 为了演示这个问题,我们用VS2017创建一个默认的Asp.net Core Web Api项目. [Route("api/[controller]")] [ApiController] public cl

  • .Net Core依赖注入IOC和DI介绍

    名词解释 说起依赖注入,很多人会想起两个词:IOC和DI. IOC(Inversion of Control)=控制反转 DI(Dependency Injection)=依赖注入 IOC其实并不是某项具体的实现技术,它是一种思路(或者是设计理念),这一点很多有经验的同学都会搞混.如果用白话来讲,IOC就意味着把对象交给IOC容器控制,而不是在对象内部控制.简而言之就是“容器控制对象”. 套入到程序来说,我们有两个class,A.B,如果B要用到A的方法,传统的方法是在B中添加A的引用(比如ne

  • 详解asp.net core 依赖注入

    前言 好久没有写微博了,因为前段时间由于家庭原因决定从工作了3年多的北京转移到上海去.依赖注入在学习net core的时候也有写过类似的东西,只是实践的较少,结果来到上海新公司系统框架涉及到了这块知识点,所以在了解完自己的项目之后决定做一些相关的总结.接下来就让我们先来了解hewi依赖注入. 什么是依赖注入 依赖注入,全称是"依赖注入到容器", 容器(IOC容器)是一个设计模式,它也是个对象,你把某个类(不管有多少依赖关系)放入这个容器中,可以"解析"出这个类的实例

  • Asp.net Core MVC中怎么把二级域名绑定到特定的控制器上

    应用场景:企业门户网站会根据内容不同,设置不同的板块,如新浪有体育,娱乐频道,等等.有的情况下需要给不同的板块设置不同的二级域名,如新浪体育sports.sina.com.cn. 在asp.net core mvc中,如果要实现板块的效果,可能会给不同的板块建立不同的控制器(当然也有其他的技术,这里不讨论实现方式的好坏),在这种情况下,如何给控制器绑定上独有的二级域名,比如体育频道对应的控制器叫SportController,通过sports.XXX.com域名访问系统的时候,直接进入Sport

  • ASP.NET Core MVC解决控制器同名Action请求不明确的问题

    在Asp.Net Core MVC Web应用程序的开发过程当中,如果需要在控制器内使用同名的Action,则会出现如下图所示的问题: https://docs.microsoft.com/zh-cn/aspnet/core/mvc/controllers/routing?view=aspnetcore-5.0 代码片段如下: ` //GET: /HelloWorld/Welcome public string Welcome() { return "这是HelloWorld控制器下的Welco

  • 详解如何在ASP.NET Core中编写高效的控制器

    通过遵循最佳实践,可以编写更好的控制器.所谓的"瘦"控制器(指代码更少.职责更少的控制器)更容易阅读和维护.而且,一旦你的控制器很瘦,可能就不需要对它们进行太多测试了.相反,你可以专注于测试业务逻辑和数据访问代码.瘦控制器的另一个优点是,它更容易维护控制器的多个版本. 这篇文章讨论了使控制器变胖的坏习惯,然后探索了使控制器变瘦和易于管理的方法.我列出编写控制器的最佳实践可能并不全面,但我已经讨论了最重要的一些,并在适当的情况下提供了相关的源代码.在接下来的几节中,我们将研究什么是胖控制

  • ASP.NET Core实现自动依赖注入

    在开发.NET Core web服务的时候,我们习惯使用自带的依赖注入容器来进行注入. 于是就会经常进行一个很频繁的的重复动作:定义一个接口->写实现类->注入 有时候会忘了写Add这一步,看到屏幕上的报错一脸懵逼,然后瞬间反应过来忘了注入了.赶紧补上serviceCollection.AddXXX这句话 虽然说有很多开源框架已经实现了类似的工作,比如AutoFac,Unity等依赖注入框架.但是这些库都太庞大了,我个人还是喜欢轻量级的实现. 定义一个枚举 [AttributeUsage(At

  • ASP.NET Core 依赖注入详细

    目录 一.控制反转 二.好莱坞法则 三.流程控制 四.三种依赖注入方式 1.构造器注入 2.属性注入 3.方法注入 五.生命周期 六.ASP.Net Core 中自带的注入 前言: ASP.NET Core 应用在启动过程中会依赖各种组件提供服务,而这些组件会以接口的形式标准化,这些组件这就是我们所说的服务,ASP.NET Core框架建立在一个底层的依赖注入框架之上,它使用容器提供所需的服务.要了解依赖注入容器以及它的机制,我们需要了解什么是依赖注入. 一.控制反转 说道依赖注入就不得不提控制

  • ASP.NET Core MVC 依赖注入View与Controller

    目录 一.ASP.NET Core MVC 之依赖注入 View 1.填充查找数据 2.重写服务 二. ASP.NET Core MVC 之依赖注入 Controller 1.构造函数注入 2.使用 FromServices 操作注入 3.在控制器中访问设置 一.ASP.NET Core MVC 之依赖注入 View ASP.NET Core 支持在试图中使用依赖注入.这将有助于提供视图专用的服务,比如本地化或者仅用于填充视图元素的数据.应尽量保持控制器和视图之间的关注点分离.视图所显示的大部分

随机推荐