在上一篇博客里，我们为.NET Core原生DI扩展了基于名称的注入功能。而今天，我们要来聊一聊属性注入。关于属性注入，历来争议不断，支持派认为，构造函数注入会让构造函数变得冗余，其立意点主要在代码的可读性。而反对派则认为，属性注入会让组件间的依赖关系变得模糊，其立意点主要在代码是否利于测试。我认识的一位前辈更是留下一句话：只要构造函数中超过5个以上的参数，我就觉得无法忍受。我个人是支持派，因为我写这篇博客的动机，正是一位朋友向我吐槽公司项目，说一个控制器里单单是构造函数里的参数就有十来个。在这其中最大的痛点是，有些在构造函数中注入的类型其实是重复的，譬如ILogger<>、IMapper、IRepository<>以及用户上下文信息等，虽然继承可以让痛苦减轻一点，可随之而来的就是冗长的base调用链。博主参与的项目里不乏有大量使用静态类、静态方法的，譬如LogEx、UserContext等等，可这种实践显然与依赖注入的思想背道而驰，为吾所不取也，这就是这篇博客产生的背景啦！
好了，当视角正式切入属性注入的时候，我们不妨先来考虑这样一件事情，即：当我们从容器里Resolve一个特定的类型的时候，这个实例到底是怎么被创建出来的呢？这个问题如果给到三年前的我，我会不假思索的说出两个字——反射。的确，这是最简单的一种实现方式，换句话说，首先，容器收集构造函数中的类型信息，并根据这些类型信息Resolve对应的实例；其次，这些实例最终会被放到一个object[]里，并作为参数传递给Activator.CreateInstance()方法。这是一个一般意义上的Ioc容器的工作机制。那么，相对应地，关于属性注入，我们可以认为容器Reslove一个特定类型的时候，这个类型提供了一个空的构造函数(这一点非常重要)，再创建完实例以后，再去Reslove这个类型中的字段或者是属性。所以，为了在微软自带的DI上实现属性注入，我们就必须实现自己的ServiceProvider——AutowiredServiceProvider，这个ServiceProvider相比默认的ServiceProvider多了一部分功能，即反射属性或者字段的过程。一旦想通这一点，我们可以考虑装饰器模式。
1public class AutowiredServiceProvider : IServiceProvider, ISupportRequiredService {
2 private readonly IServiceProvider _serviceProvider;
3 public AutowiredServiceProvider (IServiceProvider serviceProvider) {
4 _serviceProvider = serviceProvider;
5 }
6
7 public object GetRequiredService (Type serviceType) {
8 return GetService (serviceType);
9 }
10
11 public object GetService (Type serviceType) {
12 var instance = _serviceProvider.GetService (serviceType);
13 Autowried (instance);
14 return instance;
15 }
16
17 private void Autowried (object instance) {
18 if (_serviceProvider == null || instance == null)
19 return;
20
21 var flags = BindingFlags.Public | BindingFlags.NonPublic;
22 var type = instance as Type ?? instance.GetType ();
23 if (instance is Type) {
24 instance = null;
25 flags |= BindingFlags.Static;
26 } else {
27 flags |= BindingFlags.Instance;
28 }
29
30 //Feild
31 foreach (var field in type.GetFields (flags)) {
32 var autowriedAttr = field.GetCustomAttribute ();
33 if (autowriedAttr != null) {
34 var dependency = GetService (field.FieldType);
35 if (dependency != null)
36 field.SetValue (instance, dependency);
37 }
38 }
39
40 //Property
41 foreach (var property in type.GetProperties (flags)) {
42 var autowriedAttr = property.GetCustomAttribute ();
43 if (autowriedAttr != null) {
44 var dependency = GetService (property.PropertyType);
45 if (dependency != null)
46 property.SetValue (instance, dependency);
47 }
48 }
49 }
50}
装饰器模式，又被称之为“静态代理"，是面向切面编程(AOP)的实现方式之一，我们在这里为默认的ServiceProvider增加了Autowired()方法，它会扫描所有含[Autowired]标签的字段或属性，并尝试从容器中获取对应类型的实例。所以，这又说到了反对属性注入第二个理由，即：使用反射带来的性能问题，尤其是当依赖项间的引用关系异常复杂的时候。当然，所谓“兵来将挡，水来土掩”，反射产生性能损失，可以考虑用Emit或者表达书树作来替代反射，不过，微软貌似在.NET Core中阉割了一部分Emit的API，这些都是Todo啦你懂就好，我们继续往下说。接下来，为了替换掉微软默认的ServiceProvider，我们还必须实现自己的ServiceProviderFactory，像Autofac、Unity、Castle等容器，都是采用类似的做法来支持.NET Core。
1 public class AutowiredServiceProviderFactory : IServiceProviderFactory {
2 public IServiceProvider CreateServiceProvider (IServiceCollection containerBuilder) {
3 var serviceProvider = containerBuilder.BuildServiceProvider ();
4 return new AutowiredServiceProvider (serviceProvider);
5 }
6
7 IServiceCollection IServiceProviderFactory.CreateBuilder (IServiceCollection services) {
8 if (services == null) return new ServiceCollection ();
9 return services;
10 }
11 }
因为我们是以微软内置的DI为基础来进行扩展的，所以，在实现AutowiredServiceProviderFactory的时候，提供的泛型参数依然是IServiceCollection。它需要实现两个方法：CreateBuilder和CreateServiceProvider，在这里我们需要返回我们“装饰”过的ServiceProvider。接下来，万事俱备，只欠东风，我们需要在项目入口(Program.cs)调用UseServiceProviderFactory()方法，如果你在.NET Core 使用Autofac，应该会对此感到亲切：
1public static IHostBuilder CreateHostBuilder(string[] args) =>
2 Host.CreateDefaultBuilder(args)
3 .ConfigureWebHostDefaults(webBuilder =>
4 {
5 webBuilder.UseStartup();
6 })
7 .UseServiceProviderFactory(new AutowiredServiceProviderFactory());
至此，我们就完成了对微软默认的ServiceProvider的替换。假设我们有两个接口：IFooService和IBarService：
1//IFooService && FooService
2public interface IFooService {
3 string Foo ();
4 IBarService Bar { get; set; }
5}
6
7public class FooService : IFooService {
8 [Autowired]
9 public IBarService Bar { get; set; }
10 public string Foo () => "I am Foo";
11}
12
13//IBarService && BarService
14public interface IBarService {
15 string Bar();
16}
17
18public class BarService : IBarService {
19 public string Bar () => "I am Bar";
20}
注意到FooService依赖IBarService，而我们只需要给Bar加上[Autowired]标签即可，风格上借鉴了Spring的@Autowired。只要这两个接口被注入到Ioc容器中，这个属性就可以自动获得相应的服务实例。一起来看下面的代码：
1services.AddTransient();
2services.AddTransient();
3var serviceProvider = new AutowiredServiceProvider(services.BuildServiceProvider());
4var fooService = serviceProvier.GetRequiredService();
5Console.WriteLine($"{fooService.Foo()} , {fooService.Bar.Bar()}");
回到我们一开始遇到的那个问题，如果我们让IFooService变成Controller中的一个属性，是否就能解决构造函数参数冗余的问题了呢？下面是一段简单的代码：
1[ApiController]
2[Route("[controller]")]
3public class WeatherForecastController : ControllerBase
4{
5 [Autowired]
6 public IFooService Foo { get; set; }
7
8 [Autowired]
9 public ILogger Logger { get; set; }
10
11 [HttpGet]
12 [Route("Autowired")]
13 public ActionResult GetAutowriedService()
14 {
15 return Content($"{Foo.Foo()} , {Foo.Bar.Bar()}");
16 }
17}
此时，我们会发现Foo属性提示空引用错误，这是为什么呢？这是因为Controller并不是通过IoC容器来负责创建和销毁的，为了实现属性注入的目的，我们就必须让IoC容器来全面接管Controller的创建和销毁，此时，我们需要做两件事情，其一，注册Controller到IoC容器中；其二，实现自定义的IControllerActivator，并替换默认的ControllerActivator:
1services.AddControllers();
2services.AddControllersWithViews().AddControllersAsServices();
3services.Replace(ServiceDescriptor.Transient());
其中，AutowiredControllerActivator实现如下：
1public class AutowiredControllerActivator : IControllerActivator
2{
3 public object Create(ControllerContext context)
4 {
5 if (context == null)
6 throw new ArgumentNullException(nameof(ControllerContext));
7
8 var controllerType = context.ActionDescriptor.ControllerTypeInfo.AsType();
9 var serviceProvider = context.HttpContext.RequestServices;
10 if(!(serviceProvider is AutowiredServiceProvider))
11 serviceProvider = new AutowiredServiceProvider(context.HttpContext.RequestServices);
12 var controller = serviceProvider.GetRequiredService(controllerType);
13 return controller;
14 }
15
16 public void Release(ControllerContext context, object controller)
17 {
18 if (context == null)
19 hrow new ArgumentNullException(nameof(ControllerContext));
20 if (controller == null)
21 throw new ArgumentNullException(nameof(controller));
22
23 var disposeable = controller as IDisposable;
24 if (disposeable != null)
25 disposeable.Dispose();
26 }
27 }
28}
此时，一切都会像我们期待的那样美好，返回正确的结果。目前，这个方案最大的问题是，在非Controller层使用的时候，还是需要构造AutowirdServiceProvider实例。其实，在AutowiredControllerActivator里同样有这个问题，就是你即使实现IServiceProviderFactory接口，依然没有办法替换掉默认的ServiceProvider实现，只能说它能解决一部分问题，同时又引入了新的问题，最直观的例子是，你看到一个接口的时候，你并不能找全所有加了[Autowired]标签的依赖项，所以，直接造成了依赖关系模糊、不透明、难以测试等等的一系列问题，我认为，在一个可控的、小范围内使用还是可以的。
5372
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
