如何在 ASP.NET Core DI 中注册具有多个接口的服务_风神修罗使的博客

相关文章推荐
文雅的开心果 · Rkt容器介绍· 2 周前 ·
帅呆的豌豆 · 从PHP数组中删除NULL、FALSE和'‘ ...· 7 月前 ·
淡定的柠檬 · HTML5新控件 - 日期和时间选择输入 ...· 1 年前 ·
讲道义的乌龙茶 · BitConverter.IsLittleE ...· 1 年前 ·
风流的板凳 · Go 语言变量 | 菜鸟教程· 1 年前 ·
讲道义的小虾米 · opencv的imread函数_opencv ...· 1 年前 ·
在本文中，我描述了如何在 ASP.NET Core 中使用的 Microsoft.Extensions.DependencyInjection 容器中注册具有多个公共接口的具体类。使用这种方法，您将能够使用具体类实现的任何接口来检索具体类。例如，如果您有以下类：
public class MyTestClass: ISomeInterface, ISomethingElse { }
然后您将能够注入 ISomeInterface 或 ISomethingElse，您将收到相同的 MyTestClass 实例。 
以特定方式注册 MyTestClass 以避免意外的生命周期问题很重要，例如有两个单例实例！ 
在这篇文章中，我简要概述了 ASP.NET Core 中的 DI 容器及其与第三方容器相比的一些限制。 然后，我将描述将对多个接口的请求“转发”到具体类型的概念，以及如何使用 ASP.NET Core DI 容器实现此目的。 
ASP.NET Core DI 容器本身不支持将实现注册为多个服务（有时称为“转发”）。相反，您必须手动将服务的解析委托给工厂函数，例如
 services.AddSingleton<IFoo>(x=> x.GetRequiredService<Foo>()) 
ASP.NET Core 中的依赖注入
 
ASP.NET Core 的关键特性之一是它使用依赖注入 (DI)。 该框架是围绕“符合容器”的抽象设计的，它允许框架本身使用一个简单的容器，同时还允许您插入功能更丰富的第三方容器。 
“一致容器”的想法并非没有争议——我建议阅读 Mark Seemann 的这篇关于将一致容器作为反模式的文章，或者这篇来自 SimpleInjector 团队的关于 ASP.NET Core DI 容器的文章。 
为了让第三方容器尽可能简单地实现符合标准的容器，它公开了非常有限的 API。 对于给定的服务（例如 IFoo），您可以定义实现它的具体类（例如 Foo），以及它应该具有的生命周期（例如 Singleton）。 在这方面有一些变体，您可以直接提供服务的实例，也可以提供工厂方法，但这是您所能得到的最复杂的方法。 
相比之下，.NET 中的第三方 DI 容器通常会提供更高级的注册 API。 例如，许多 DI 容器公开了一个用于配置的“扫描”API，您可以在其中搜索程序集中的所有类型，并将它们添加到您的 DI 容器中。 以下是一个 Autofac 示例： 
var dataAccess = Assembly.GetExecutingAssembly();
builder.RegisterAssemblyTypes(dataAccess) // find all types in the assembly
       .Where(t => t.Name.EndsWith("Repository")) // filter the types
       .AsImplementedInterfaces()  // register the service with all its public interfaces
       .SingleInstance(); // register the services as singletons
在此示例中，Autofac 将在程序集中查找名称以“Repository”结尾的所有具体类，并根据它们实现的任何公共接口将它们注册到容器中。 因此，例如，给定以下类和接口： 
public interface IStubRepository {}
public interface ICachingRepository {}
public class StubRepository : IStubRepository {}
public class MyRepository : ICachingRepository {}
前面的Autofac代码相当于手动在Startup.ConfigureServices中的ASP.NET Core容器中注册这两个类及其各自的接口： 
services.AddSingleton<IStubRepository, StubRepository>();
services.AddSingleton<ICachingRepository, MyRepository>();
但是如果一个类实现了多个接口会怎样呢？ 
将单个实现注册为多个服务
 
实现多个接口的类很常见，例如： 
public interface IBar {}
public interface IFoo {}
public class Foo : IFoo, IBar {}
让我们编写一个快速测试，看看如果我们使用 ASP.NET Core DI 容器针对两个接口注册类会发生什么： 
[Fact]
public void WhenRegisteredAsSeparateSingleton_InstancesAreNotTheSame()
    var services = new ServiceCollection();
    services.AddSingleton<IFoo, Foo>();
    services.AddSingleton<IBar, Foo>();
    var provider = services.BuildServiceProvider();
    var foo1 = provider.GetService<IFoo>(); // An instance of Foo
    var foo2 = provider.GetService<IBar>(); // An instance of Foo
    Assert.Same(foo1, foo2); // FAILS
我们将 Foo 注册为 IFoo 和 IBar 的单例，但结果可能不是您所期望的。 我们实际上有两个 Foo“Singleton”实例，各自用于它注册的每个服务。 
转发服务请求
 
针对多个服务注册一个实现的一般模式是一种常见的模式。 大多数第三方 DI 容器都内置了这个概念。例如： 
Autofac 默认使用此行为 - 之前的测试会通过
Windsor 具有“转发类型”的概念，允许您将多个服务“转发”到单个实现
StructureMap（现已停用）具有类似的“转发”类型概念。 据我所知，它的继任者 Lamar 还没有，但我在这一点上可能是错的。 
鉴于此要求非常普遍，ASP.NET Core DI 容器不可能实现这一点似乎很奇怪。 这个问题是在 2 年前提出的（由 David Fowler 提出），但已关闭。 幸运的是，有几个概念上简单但有些不雅的解决方案。 
1.提供服务实例（仅限单例）
 
最简单的方法是在注册服务时提供 Foo 的实例。 每个注册的服务都将返回您在请求时提供的确切实例，确保只有一个实例。 
[Fact]
public void WhenRegisteredAsInstance_InstancesAreTheSame()
    var foo = new Foo(); // The singleton instance
    var services = new ServiceCollection();
    services.AddSingleton<IFoo>(foo);
    services.AddSingleton<IBar>(foo);
    var provider = services.BuildServiceProvider();
    var foo1 = provider.GetService<IFoo>();
    var foo2 = provider.GetService<IBar>();
    Assert.Same(foo1, foo); // PASSES;
    Assert.Same(foo2, foo); // PASSES;
对此有一个很大的警告——您必须能够在配置时实例化 Foo，并且您必须知道并提供它的所有依赖项。 这在某些情况下可能对您有用，但不是很灵活。 
此外，您只能使用这种方法来注册单例。 如果您希望 Foo 成为每个请求范围（Scoped）的单个实例，那么您就不走运了。 相反，您需要使用以下技术。 
2.使用工厂方法实现转发
 
如果我们分解我们的需求，就会出现一个替代解决方案： 
我们希望我们注册的服务（Foo）有特定的生命周期（例如 Singleton 或 Scoped）
当请求 IFoo 时，返回 Foo 的实例
请求 IBar 时，也返回 Foo 的实例 
根据这三个规则，我们可以编写另一个测试： 
[Fact]
public void WhenRegisteredAsForwardedSingleton_InstancesAreTheSame()
    var services = new ServiceCollection();
    services.AddSingleton<Foo>(); // 我们必须显式注册 Foo
    services.AddSingleton<IFoo>(x => x.GetRequiredService<Foo>()); // 将请求转发给 Foo
    services.AddSingleton<IBar>(x => x.GetRequiredService<Foo>()); // 将请求转发给 Foo
    var provider = services.BuildServiceProvider();
    var foo1 = provider.GetService<Foo>(); // Foo 的一个实例
    var foo2 = provider.GetService<IFoo>(); // Foo 的一个实例
    var foo3 = provider.GetService<IBar>(); // Foo 的一个实例
    Assert.Same(foo1, foo2); // 通过
    Assert.Same(foo1, foo3); // 通过
为了将对接口的请求“转发”到具体类型，您必须做两件事： 
使用 services.AddSingleton<Foo>() 显式注册具体类型
通过提供工厂函数将接口请求委托给具体类型：services.AddSingleton<IFoo>(x =>x.GetRequiredService<Foo>()) 
使用这种方法，无论您请求哪个实现的服务，您都将拥有一个真正的 Foo 单例实例。 
 这种提供“转发”类型的方法已在原始问题中指出，并有一个警告——它不是很有效。通常最好尽可能避免使用“服务定位器样式”GetService() 调用。 但是，我觉得在这种情况下这绝对是更可取的做法。 
在这篇文章中，我描述了如果将具体类型注册为 ASP.NET Core DI 服务的多个服务会发生什么。 特别是，我展示了如何最终得到 Singleton 对象的多个副本，这可能会导致细微的错误。 要解决这个问题，您可以在注册时提供服务实例，也可以使用工厂方法委托服务解析。 使用工厂方法不是很有效，但通常是最好的方法。
                    在本文中，我描述了如何在 ASP.NET Core 中使用的容器中注册具有多个公共接口的具体类。使用这种方法，您将能够使用具体类实现的任何接口来检索具体类。然后您将能够注入或，您将收到相同的实例。以特定方式注册以避免意外的生命周期问题很重要，例如有两个单例实例！在这篇文章中，我简要概述了 ASP.NET Core 中的 DI 容器及其与第三方容器相比的一些限制。然后，我将描述将对多个接口的请求“转发”到具体类型的概念，以及如何使用 ASP.NET Core DI 容器实现此目的。
				此文是在官方文档的基础上做的个人笔记，一些简单的内容就没用再列出来了，参考官方文档：https://docs.microsoft.com/zh-cn/aspnet/core/fundamentals/dependency-injection?view=aspnetcore-5.0
框架自带的一些符合Add{GROUP_NAME}约定的服务，如：AddControllers、AddDbContext、AddDefaultIdentity等，会自动注册该框架功能所需的所有服务。
1.服务生存周期
Tran.
				前言假设我们有三个Service类实现了同一接口，示例代码如下：publicinterfaceIService{}
publicclassServiceA:IService{}
publicclassServiceB:IService{}
publicclassServiceC:IService{}我们希望在运行时使用依赖注入...
				IoC：控制反转。在一个有层级的结构中，上层依赖下层，下层的改变会影响上层。控制反转就是将自上而下的依赖链部分反转。由A->B，转变为A->Interface<-B。从中间抽象出一层来，上下2层都依赖他。只要中间这一层不变，则2端可以自由发挥。
DI：依赖注入。虽然自己依赖某个类的运行，但是自己不主动去生成某个实例，而是由调用者去生成（将依赖由自己生成变成外部注入）。自己只需要...
				在现代 Web 应用程序中，调用第三方 Web API 来增强应用程序的功能是很常见的。有数以千计的免费和商业 API 可用，如果您知道如何在 ASP.NET Core 应用程序中使用这些 API，您就可以构建非常强大的业务应用程序。在这篇文章中，我将解释如何在 ASP.NET Core 应用程序中使用第三方 Web API。
下载：Download Source Code
				好的，我来给你简单介绍一下如何使用 ASP.NET Core 写一个文件下载接口，数据来自数据库。
首先，你需要在你的 ASP.NET Core 项目中引入相关的命名空间，例如：
using Microsoft.AspNetCore.Mvc;
using Microsoft.EntityFrameworkCore;
然后，你需要准备好文件的信息，并将其存储在数据库中。这里假设你已经有了一个数据库上下文，名为 `DbContext`。
接着，你需要在你的控制器中创建一个新的接口来处理文件下载请求。这里假设你的控制器名为 `FileController`。
具体实现方式如下：
[Route("api/[controller]")]
[ApiController]
public class FileController : ControllerBase
    private readonly DbContext _context;
    public FileController(DbContext context)
        _context = context;
    [HttpGet("{id}")]
    public async Task<IActionResult> Download(int id)
        // 根据文件 ID 从数据库中查询文件信息
        var file = await _context.Files.FirstOrDefaultAsync(f => f.Id == id);
        if (file == null)
            // 如果文件不存在，返回 404 错误
            return NotFound();
        // 读取文件数据
        var fileBytes = System.IO.File.ReadAllBytes(file.FilePath);
        // 返回文件数据
        return File(fileBytes, file.ContentType, file.FileName);
上面的代码中，我们在 `Download` 方法中接收了文件 ID 作为参数，然后从数据库中查询文件信息。如