.net core工具组件系列之Autofac—— 第一篇:Autofac系列Autofac的几种常见注册方式、生命周期和AOP

简介: 使用Autofac进行服务注册实践:新建三个项目,分别是webapi项目 Wesky.Core.Autofac以及两个类库项目 Wesky.Core.Interface和Wesky.Core.Service。在Webapi项目下,引用Autofac的三个包:Autofac、Autofac.Configuration和Autofac.Extensions.DependencyInjection 。


使用Autofac进行服务注册实践:

 

新建三个项目,分别是webapi项目 Wesky.Core.Autofac以及两个类库项目 Wesky.Core.InterfaceWesky.Core.Service


Webapi项目下,引用Autofac的三个包:AutofacAutofac.ConfigurationAutofac.Extensions.DependencyInjection


1995789-20210722234443404-713291094.png

 

在类库下,Interface用于编写Interface接口类;Service用于开发对应的接口实现类。现在先准备了6个接口和实现,用来测试,方法实现都一样,都是打印当前方法名称。如图:

1995789-20210722234454327-261281947.png

 

webapi项目下的Program类里面,添加对autofac工厂(AutofacServiceProviderFactory)的服务实现。如图,需要先 using Autofac.Extensions.DependencyInjection;


1995789-20210722234505019-1315306613.png

 

Startup类下面,新建无返回值的方法ConfigureContainer,并且带有一个ContainerBuilder类型的参数。然后在里面添加两个服务的注册,例如ServiceAServiceD,用来测试使用:


1995789-20210722234517902-126760459.png

 

新增一个控制器TestController,并且实现一个叫Test方法的webapi,用来实验是否依赖注入服务生效:


1995789-20210722234533996-1175596293.png

 

运行程序,并调用webapi,验证依赖注入的结果:

1995789-20210722234545627-1333730617.png


Autofac依赖注入的几个相对常见的生命周期


1、瞬时 InstancePerDependency:每次获取的服务实例都不一样;

2、单例 SingleInstance:在整个容器中获取的服务实例都是同一个;

3、作用域 InstancePerLifetimeScope:相同作用域下获取到的服务实例相同;

4、作用域 InstancePerMatchingLifetimeScope(“作用域名称”):可以指定到某一个具体作用域;

5、每次请求 InstancePerRequest:不同的请求获取的服务实例不一样;

6、隐式关系类型的嵌套作用域 InstancePerOwned:可以使用每一个拥有实例的注册来依赖关系限定到拥有的实例。

对应注册的方式如下代码所示:

1995789-20210722234619798-961246762.png


现在对这些实例的生命周期做个测试,编写一些测试代码,用来验证生命周期:

 1995789-20210722234631102-1136910070.png


在方法最后加个断点,然后运行程序。

A1A2是瞬时周期进行注册,每次都会产生不同的实例,所以两个实例不一样;

B1 B2是单例进行注册,会引用同一个实例,所以两者的实例相等;

C1C2C3C4分别在两个作用域下进行作用域注册,所以在同一个作用域下,C1C2C3C4的实例分别相等;但是C1C3不属于同一个作用域,所以不相等。D1/2/3/4类似,不再描述。


详情,如图所示:

1995789-20210722234646167-1090622612.png


Autofac通过模块化进行注册服务

新建一个继承自Autofac.Module的类WeskyModule,并在里面提供Load方法的实现(在方法里面进行服务注册),下面使用一些其他方式进行注册,如代码以及注释部分:


1995789-20210722234659293-870694728.png


Startup类的ConfigureContainer方法下,注释之前的注册服务,改为引用Module模块来进行服务注册:

1995789-20210722234710368-1643544196.png

 

运行程序,在注册ServiceE的时候会提示错误,这是因为上面注册时候,排除了ServiceE所导致的,会提示服务没注册,如图:

1995789-20210722234720491-1697889117.png

 

现在先屏蔽掉对E服务的依赖,查看注册效果,直接在注册以后,访问注册服务的Hello方法,并运行查看结果。说明服务注册成功:

1995789-20210722234736822-1785697166.png


Autofac通过配置文件进行服务注册的方式


Autofac也可以通过配置文件进行注册服务,下面做个简单的例子。


新建一个叫做autofac.json的文件,然后在里面写上两个简单的单例注册。注意:新建的json文件需要设置为始终复制,防止生成以后没有存在根目录里面导致的找不到文件的问题。

 1995789-20210722234813526-1144565533.png


然后在WeskyModule里面,注释掉先前的注册,使用以下代码进行获取配置文件的注册,并对AB(B没有在文件里面注册,正常情况下应该是要报错的) C进行测试。

1995789-20210722234830936-2081730789.png


运行程序,可以看到由于B并没有在文件里面注册,所以运行到服务B时候,提示未注册服务异常:

1995789-20210722234841442-1926705912.png

 

由此可见,通过配置文件进行服务注册符合预期,测试完毕。

 

Autofac实现AOP切面功能


先添加Autofac.Extras.DynamicProxy的包:

 

1995789-20210722234901350-1064531716.png


新建一个叫做WeskyAOP的类,并且继承自,然后实现里面的Intercept方法,示例如下:


1995789-20210722234911330-924883188.png

 

然后为了方便,我直接在下方新建一个IWeskyTest接口和WeskyTest类,并且提供一个Hello方法进行测试。以及对IWeskyTest添加了上面AOP的标记,如下:

 1995789-20210722234921929-845398402.png


返回WeskyModule里面,把先前注册的内容注释掉,然后添加对新增AOP服务的注册,以及新增服务接口的注册,此处注册为一个单例,不过会行不通,不信的可以自己尝试:


1995789-20210722234932700-1774335257.png


Test控制器里面,添加对IWeskyTest接口服务的依赖注入,并在测试的api里面调用Hello方法进行测试。打印出AOP里面的两句语句,代表AOP实现成功。注意,以上使用单例或者其他的进行注册是不成功的,必须使用 EnableInterfaceInterceptors (需要using Autofac.Extras.DynamicProxy


1995789-20210722234944172-1076322641.png


另外,把标记写到实现类上也是OK的,例如:


1995789-20210722234957108-634890122.png


熬夜写博客太累了,未完,待续……后续继续更新Autofac的属性注入、以及过滤器里面实现依赖注入等方法,如有需要,欢迎提前关注。


如有需要有关资料或是本篇文章源码,可以点击下方Q群加入进行索要。

感谢观看,欢迎留言提供宝贵意见或推荐,谢谢!


目录
相关文章
|
13天前
|
开发框架 .NET 开发者
简化 ASP.NET Core 依赖注入(DI)注册-Scrutor
Scrutor 是一个简化 ASP.NET Core 应用程序中依赖注入(DI)注册过程的开源库,支持自动扫描和注册服务。通过简单的配置,开发者可以轻松地从指定程序集中筛选、注册服务,并设置其生命周期,同时支持服务装饰等高级功能。适用于大型项目,提高代码的可维护性和简洁性。仓库地址:<https://github.com/khellang/Scrutor>
35 5
|
26天前
|
开发框架 .NET 程序员
驾驭Autofac,ASP.NET WebApi实现依赖注入详细步骤总结
Autofac 是一个轻量级的依赖注入框架,专门为 .NET 应用程序量身定做,它就像是你代码中的 "魔法师",用它来管理对象的生命周期,让你的代码更加模块化、易于测试和维护
驾驭Autofac,ASP.NET WebApi实现依赖注入详细步骤总结
|
1月前
|
开发框架 .NET C#
在 ASP.NET Core 中创建 gRPC 客户端和服务器
本文介绍了如何使用 gRPC 框架搭建一个简单的“Hello World”示例。首先创建了一个名为 GrpcDemo 的解决方案,其中包含一个 gRPC 服务端项目 GrpcServer 和一个客户端项目 GrpcClient。服务端通过定义 `greeter.proto` 文件中的服务和消息类型,实现了一个简单的问候服务 `GreeterService`。客户端则通过 gRPC 客户端库连接到服务端并调用其 `SayHello` 方法,展示了 gRPC 在 C# 中的基本使用方法。
41 5
在 ASP.NET Core 中创建 gRPC 客户端和服务器
|
21天前
|
开发框架 缓存 .NET
GraphQL 与 ASP.NET Core 集成:从入门到精通
本文详细介绍了如何在ASP.NET Core中集成GraphQL,包括安装必要的NuGet包、创建GraphQL Schema、配置GraphQL服务等步骤。同时,文章还探讨了常见问题及其解决方法,如处理复杂查询、错误处理、性能优化和实现认证授权等,旨在帮助开发者构建灵活且高效的API。
24 3
|
1月前
|
机器学习/深度学习 文字识别 并行计算
一款.NET开源的屏幕实时翻译工具
一款.NET开源的屏幕实时翻译工具
|
2月前
.NET 4.0下实现.NET4.5的Task类相似功能组件
【10月更文挑战第29天】在.NET 4.0 环境下,可以使用 `BackgroundWorker` 类来实现类似于 .NET 4.5 中 `Task` 类的功能。`BackgroundWorker` 允许在后台执行耗时操作,同时不会阻塞用户界面线程,并支持进度报告和取消操作。尽管它有一些局限性,如复杂的事件处理模型和不灵活的任务管理方式,但在某些情况下仍能有效替代 `Task` 类。
|
2月前
|
前端开发 JavaScript C#
2款.NET开源且高效的代码格式化工具
2款.NET开源且高效的代码格式化工具
|
2月前
|
开发框架 JavaScript 前端开发
一个适用于 ASP.NET Core 的轻量级插件框架
一个适用于 ASP.NET Core 的轻量级插件框架
|
2月前
|
存储 开发工具 C#
Git Extensions:一个.NET开源的 Git 图形用户界面(GUI)工具
Git Extensions:一个.NET开源的 Git 图形用户界面(GUI)工具
145 0
|
2月前
|
XML 存储 安全
C#开发的程序如何良好的防止反编译被破解?ConfuserEx .NET混淆工具使用介绍
C#开发的程序如何良好的防止反编译被破解?ConfuserEx .NET混淆工具使用介绍
112 0

相关实验场景

更多