NET Core依赖注入解读&使用Autofac替代实现

NET Core依赖注入解读&使用Autofac替代实现

1. 前言

关于IoC模式（控制反转）和DI技术（依赖注入），我们已经见过很多的探讨，这里就不再赘述了。比如说必看的Martin Fowler《IoC 容器和 Dependency Injection 模式》，相关资料链接都附于文章末尾。其中我非常赞同Artech的说法"控制更多地体现为一种流程的控制"，而依赖注入技术让我们的应用程序实现了松散耦合。

ASP.NET Core本身已经集成了一个轻量级的IOC容器，开发者只需要定义好接口后，在Startup.cs的ConfigureServices方法里使用对应生命周期的绑定方法即可，常见方法如下

services.AddTransient<IApplicationService,ApplicationService>

services.AddScoped<IApplicationService,ApplicationService>

services.AddSingleton<IApplicationService,ApplicationService>

对于上述的三种DI注入方式，官方也给出了详细的解释，我来简单翻译一下

  • Transient
    Transient 服务在每次请求时被创建，它最好被用于轻量级无状态服务（如我们的Repository和ApplicationService服务）
  • Scoped
    Scoped 服务在每次请求时被创建，生命周期横贯整次请求
  • Singleton
    顾名思义，Singleton（单例） 服务在第一次请求时被创建（或者当我们在ConfigureServices中指定创建某一实例并运行方法），其后的每次请求将沿用已创建服务。如果开发者的应用需要单例服务情景，请设计成允许服务容器来对服务生命周期进行操作，而不是手动实现单例设计模式然后由开发者在自定义类中进行操作。

在这之后，我们便可以将服务通过构造函数注入或者是属性注入的方式注入到Controller，View(通过使用@inject)，甚至是Filter中（以前使用Unity将依赖注入到Filter真是一种痛苦）。话不多说，先来体验一把

Tips：Startup.cs是什么，详见ASP.NET Core 介绍和项目解读

2. ASP.NET Core 中的DI方式

大多项目举例依赖注入的生命周期演示时，都会采取可变Guid来作为返回显示，此次示例也会这样处理。我们先定义一个IGuidAppService接口，里面定义基接口和三种注入模式的接口

    public interface IGuidAppService
    {
        Guid GuidItem();
    }

    public interface IGuidTransientAppService : IGuidAppService
    {
    }

    public interface IGuidScopedAppService : IGuidAppService
    {
    }

    public interface IGuidSingletonAppService : IGuidAppService
    {
    }

同样的，在GuidAppService中定义其实现类。这里为了直观显示每次请求的返回值，采取如下代码

    public class GuidAppServiceBase : IGuidAppService
    {
        private readonly Guid _item;

        public GuidAppServiceBase()
        {
            _item = Guid.NewGuid();
        }

        public Guid GuidItem()
        {
            return _item;
        }
    }

    public class GuidTransientAppService : GuidAppServiceBase, IGuidTransientAppService
    {
    }

    public class GuidScopedAppService : GuidAppServiceBase, IGuidScopedAppService
    {
    }

    public class GuidSingletonAppService : GuidAppServiceBase, IGuidSingletonAppService
    {
    }

最后是Controller和View视图的代码

    # Controller
    public class HomeController : Controller
    {
        private readonly IGuidTransientAppService _guidTransientAppService; //#构造函数注入
        //private  IGuidTransientAppService _guidTransientAppService { get; } #属性注入
        private readonly IGuidScopedAppService _guidScopedAppService;
        private readonly IGuidSingletonAppService _guidSingletonAppService;

        public HomeController(IGuidTransientAppService guidTransientAppService,
            IGuidScopedAppService guidScopedAppService, IGuidSingletonAppService guidSingletonAppService)
        {
            _guidTransientAppService = guidTransientAppService;
            _guidScopedAppService = guidScopedAppService;
            _guidSingletonAppService = guidSingletonAppService;
        }

        public IActionResult Index()
        {
            ViewBag.TransientItem = _guidTransientAppService.GuidItem();
            ViewBag.ScopedItem = _guidScopedAppService.GuidItem();
            ViewBag.SingletonItem = _guidSingletonAppService.GuidItem();

            return View();
        }
    }

    # Index View
    <div class="row">
    <div >
        <h2>GuidItem Shows</h2>

        <h3>TransientItem: @ViewBag.TransientItem</h3>

        <h3>ScopedItem: @ViewBag.ScopedItem</h3>

        <h3>SingletonItem: @ViewBag.SingletonItem</h3>
    </div>
</div>

之后我们打开两个浏览器，分别刷新数次，也只会发现“TransientItem”和“ScopedItem”的数值不断变化，“SingletonItem”栏的数值是不会有任何变化的，这就体现出单例模式的作用了，示例图如下

但是这好像还不够，要知道我们的Scoped的解读是“生命周期横贯整次请求”，但是现在演示起来和Transient好像没有什么区别（因为两个页面每次浏览器请求仍然是独立的，并不包含于一次中），所以我们采用以下代码来演示下（同一请求源）


# 新建GuidItemPartial.cshtml视图，复制如下代码，使用@inject注入依赖
@using DependencyInjection.IApplicationService

@inject IGuidTransientAppService TransientAppService
@inject IGuidScopedAppService GuidScopedAppServic
@inject IGuidSingletonAppService GuidSingletonAppService

<div class="row">
    <div>
        <h2>GuidItem Shows</h2>

        <h3>TransientItem: @TransientAppService.GuidItem()</h3>

        <h3>ScopedItem: @GuidScopedAppServic.GuidItem()</h3>

        <h3>SingletonItem: @GuidSingletonAppService.GuidItem()</h3>
    </div>
</div>

# 原先的index视图
@{
    ViewData["Title"] = "Home Page";
}

@Html.Partial("GuidItemPartial")

@Html.Partial("GuidItemPartial")

依然是 Ctrl+F5 调试运行，可以发现“ScopedItem”在同一请求源中是不会发生变化的，但是“TransientItem”依然不断变化，理论仍然是支持的

3. Autofac实现和自定义实现扩展方法

除了ASP.NETCore自带的IOC容器外，我们还可以使用其他成熟的DI框架，如Autofac，StructureMap等（笔者只用过Unity，Ninject和Castle，Castle也是使用ABP时自带的）。

3.1 安装Autofac

首先在project.json的dependency节点中加入Autofac.Extensions.DependencyInjection引用，目前最新版本是4.0.0-rc3-309

3.2 创建容器并注册依赖

在Startup.cs中创建一个public IContainer ApplicationContainer { get; private set; }对象，并把ConfigureServices返回类型改为IServiceProvider，然后复制以下代码进去，也可以实现相关功能

var builder = new ContainerBuilder();

//注意以下写法
builder.RegisterType<GuidTransientAppService>().As<IGuidTransientAppService>();
builder.RegisterType<GuidScopedAppService>().As<IGuidScopedAppService>().InstancePerLifetimeScope();
builder.RegisterType<GuidSingletonAppService>().As<IGuidSingletonAppService>().SingleInstance();

builder.Populate(services);
this.ApplicationContainer = builder.Build();

return new AutofacServiceProvider(this.ApplicationContainer);

值得注意的几点:

  1. 创建Autofac容器时不要忘了将ConfigureServices的返回值修改为IServiceProvider
  2. 对应ASP.NET Core提及的不同的生命周期，Autofac也定义了对应的扩展方法，如InstancePerLifetimeScope等，默认为Transient模式，包括EntityFramwork等Context也是该种模式
  3. Autofac Core不支持从View中注入，但是可以和ASP.NET Core自带IOC容器配合使用
  4. Autofac Core版本和传统的ASP.NET MVC项目版本的区别

4. 参考链接

时间： 2024-10-27 01:17:42

NET Core依赖注入解读&使用Autofac替代实现的相关文章

ASP.NET Core 依赖注入最佳实践——提示与技巧

在这篇文章,我将分享一些在ASP.NET Core程序中使用依赖注入的个人经验和建议.这些原则背后的动机如下: 高效地设计服务和它们的依赖. 预防多线程问题. 预防内存泄漏. 预防潜在的BUG. 这篇文章假设你已经基本熟悉依赖注入和ASP.NET Core.如果不是,则先阅读文章: 在ASP.NET Core中使用依赖注入 基础 构造函数注入 构造函数注入常用于在服务构建上定义和获取服务依赖.例如: 1 public class ProductService 2 { 3 private read

ASP.NET Core 依赖注入(DI)

原文:ASP.NET Core 依赖注入(DI) ASP.NET Core的底层设计支持和使用依赖注入.ASP.NET Core 应用程序可以利用内置的框架服务将服务注入到启动类的方法中,并且应用程序服务也可以配置注入.由ASP.NET Core 提供的默认服务容器提供了最小功能集,并不是取代其他容器. 1.浅谈依赖注入 依赖注入(Dependency injection,DI)是一种实现对象和依赖者之间松耦合的技术,将类用来执行其操作的这些对象以注入的方式提供给该类,而不是直接实例化依赖项或者

ASP.NET Core 依赖注入基本用法

ASP.NET Core 依赖注入 ASP.NET Core从框架层对依赖注入提供支持.也就是说,如果你不了解依赖注入,将很难适应 ASP.NET Core的开发模式.本文将介绍依赖注入的基本概念,并结合代码演示如何在 ASP.NET Core中使用依赖注入. 什么是依赖注入? 百度百科对于依赖注入的介绍: 控制反转(Inversion of Control,缩写为IoC),是面向对象编程中的一种设计原则,可以用来减低计算机代码之间的耦合度.其中最常见的方式叫做依赖注入(Dependency I

asp.net core 依赖注入

依赖注入入门 全面理解 ASP.NET Core 依赖注入 参考https://www.cnblogs.com/tcjiaan/p/8732848.html 如何在StartUp中的ConfigureServices方法里直接调用刚刚添加好的注册? // redis注入 services.AddSingleton<IRedisConnection>(k => { return new RedisConnection(6, Configuration["RedisConnecti

ASP.NET Core依赖注入——依赖注入最佳实践

在这篇文章中,我们将深入研究.NET Core和ASP.NET Core MVC中的依赖注入,将介绍几乎所有可能的选项,依赖注入是ASP.Net Core的核心,我将分享在ASP.Net Core应用中使用依赖注入的一些经验和建议,并且将会讨论这些原则背后的动机是什么: (1)有效地设计服务及其依赖关系. (2)防止多线程问题. (3)防止内存泄漏. (4)防止潜在的错误. 在讨论该话题之前,了解什么是服务是生命周期至关重要,当组件通过依赖注入请求另一个组件时,它接收的实例是否对该组件实例是唯一

了解ASP.NET Core 依赖注入，看这篇就够了

DI在.NET Core里面被提到了一个非常重要的位置, 这篇文章主要再给大家普及一下关于依赖注入的概念,身边有工作六七年的同事还个东西搞不清楚.另外再介绍一下.NET  Core的DI实现以及对实例生命周期的管理(这个是经常面试会问到的问题).最后再给大家简单介绍一下在控制台以及Mvc下如何使用DI,以及如何把默认的Service Container 替换成Autofac. 一.什么是依赖注入 1.1 依赖 1.2 什么注入 为什么反转 何为容器 二..NET Core DI 2.1 实例的注

【转】ASP.NET Core 依赖注入

DI在.NET Core里面被提到了一个非常重要的位置, 这篇文章主要再给大家普及一下关于依赖注入的概念,身边有工作六七年的同事还个东西搞不清楚.另外再介绍一下.NET  Core的DI实现以及对实例生命周期的管理(这个是经常面试会问到的问题).最后再给大家简单介绍一下在控制台以及Mvc下如何使用DI,以及如何把默认的Service Container 替换成Autofac. 一.什么是依赖注入 1.1 依赖 1.2 什么注入 为什么反转 何为容器 二..NET Core DI 2.1 实例的注

全面理解 ASP.NET Core 依赖注入

DI在.NET Core里面被提到了一个非常重要的位置, 这篇文章主要再给大家普及一下关于依赖注入的概念,身边有工作六七年的同事还个东西搞不清楚.另外再介绍一下.NET  Core的DI实现以及对实例生命周期的管理(这个是经常面试会问到的问题).最后再给大家简单介绍一下在控制台以及Mvc下如何使用DI,以及如何把默认的Service Container 替换成Autofac. 我录了一些关于ASP.NET Core的入门视频:有兴趣的同学可以去看看.  http://www.cnblogs.co

asp.net core 依赖注入问题

最近.net core可以跨平台了,这是一个伟大的事情,为了可以赶上两年以后的跨平台部署大潮,我也加入到了学习之列.今天研究的是依赖注入,但是我发现一个问题,困扰我很久,现在我贴出来,希望可以有人帮忙解决或回复一下. 背景:我测试.net自带的依赖注入生命周期,一共三个:Transient.Scope.Single三种,通过一个GUID在界面展示,但是我发现scope和single的每次都是相同的,并且single实例的guid值每次都会改变. 通过截图可以看到scope和Single每次浏览器