作者引言

很高兴啊，我们来到了IceRPC之依赖注入>快乐的RPC，基础引导，打好基础，才能让自已不在迷茫，快乐的畅游世界。

依赖注入和IceRPC

了解 IceRPC (C#) 如何为依赖注入（DI）提供支持。

DI作为可选功能

DI的第一条规则是:不要引入对DI的依赖。

IceRPC (C#) 将此规则放首要位置上,即为 DI 提供全方位支持,同时使此支持完全可选。

IceRPC C# API 被设计为可选 DI 容器。此外,IceRPC 还提供支持代码来帮助大家，在 Microsoft's DI container中使用 IceRPC。.

DI APIs

IceRPC 提供的所有与 DI 相关的 API 都在同一个命名空间中, IceRpc.Extensions.DependencyInjection, 但由多个组件实现:

IceRpc.dll 提供如IDispatcherBuilder和IInvokerBuilder IceRpc.Deadline.dll之类的抽象以及其他拦截器/中间件组件，为IDispatcherBuilder和IInvokerBuilder提供了扩展方法。这些扩展方法与 DI 容器无关。
IceRpc.Extensions.DependencyInjection.dll 为 Microsoft 的 DI 容器提供支持代码。这包括 IServiceCollection 的各种扩展方法,例如 AddIceRpcServer 和 AddIceRpcClientConnection,以及 IDispatcherBuilder 和 IInvokerBuilder 的实现。

---
title: 程序集依赖图
---
flowchart BT
di([Microsoft.Extensions.DependencyInjection.Abstractions.dll])
logging([Microsoft.Extensions.Logging.Abstractions.dll])
options([Microsoft.Extensions.Options.dll])
IceRpc.dll --> logging
IceRpc.Logger.dll --> IceRpc.dll
IceRpc.Logger.dll --> logging
IceRpc.Deadline.dll --> IceRpc.dll
IceRpc.Extensions.DependencyInjection.dll --> di
IceRpc.Extensions.DependencyInjection.dll --> options
IceRpc.Extensions.DependencyInjection.dll --> IceRpc.dll

调度管道与 DI

了解如何使用 DI 容器构建调度管道。

传统的调度管道

传统的调度管道相当静态: 创建路由、添加一些中间件、在此路由中映射或安装少量叶片调度程序,然后让服务器将传入的请求调度到此路由。

叶片调度程序（通常是 Slice 服务）被映射或安装在固定路径（例如/greeter 或/admin/greeter-manager）。这些调度程序是单例（或类似单例）,其使用寿命与路由和服务器相同。

调度管道中的中间件使用以下features相互通信: 上游中间件设置下游中间件可以检索的features。叶片调度程序还可以使用相同的features与这些中间件进行通信。

这对于许多应用程序来说都很有效。然而,这并不是使用 DI 时的典型模型。

DI容器构建调度管道

DI,调度管道通常更具动态性: 一些基础设施代码为每个调度创建唯一的 DI 范围,并且叶片调度程序是由 DI 容器管理的服务。当该叶片调度器的生命周期是短暂的或范围化的时,该叶片调度器是按需创建的（每个调度）。

DI 调度管道中的中间件可以像往常一样使用features，与其他中间件和叶片调度器进行通信。然而,更惯用的方法是使用注入服务进行通信。例如:

上游中间件接收范围服务（通过注入）,然后填写此服务
下游中间件接收相同的作用域服务（也通过注入）并读取上游中间件填写的信息
叶片调度器的构造函数（作用域或瞬态服务）与该先前填充的作用域服务自动连线

中间件链本身是静态的: 每个调度不会创建新的中间件实例。中间件通常是由 DI 容器管理的单例。

使用 Microsoft 的 DI 容器构建调度管道

IceRpc.Extensions.DependencyInjection组件为 IServiceCollection 提供了多种接受 Action<IDispatcherBuilder> 参数的扩展方法。

所有这些方法都允许 Microsoft 的 DI 容器构建和配置调度管道。例如:

// Construct a dispatch pipeline using Microsoft's DI container.

using IceRpc.Extensions.DependencyInjection;

using Microsoft.Extensions.DependencyInjection;

...

// Add a new IDispatcher singleton configured with an action.

services.AddIceRpcDispatcher(builder => builder.Map<IGreeterService>());

由此产生的调度程序（调度管道）为每个传入请求创建一个新的 DI 范围,并使用 IServiceProviderFeature 将此范围传输到下游调度程序。

在 IDispatcherBuilder 中安装标准中间件

标准中间件是可以与 DI 容器一起使用或不使用 DI 容器的中间件: 它不依赖DI容器注入服务来运行,并且实现了接口 IDispatcher 。

IceRPC 附带的所有中间件都是标准中间件: 可以在有或没有 DI 的情况下使用它们,并且它们在调度中使用功能进行通信。

这些中间件可以安装在路由或 IDispatcherBuilder 中。例如:

// Construct a dispatch pipeline using Microsoft's DI container.

using IceRpc.Extensions.DependencyInjection;

using Microsoft.Extensions.DependencyInjection;

...

services.AddIceRpcDispatcher(

    builder => builder

        .UseLogger()

        .Map<IGreeterService>());

这里,UseLogger 是 IceRpc.Logger 组件提供的扩展方法。此扩展方法适用于实现 IServiceProvider 的任何 DI 容器,例如 Microsoft 的 DI 容器和 Simple Injector 的容器。

UseLogger 的实现只是从 DI 容器中检索一个记录器实例, 然后用这个实例创建一个新的中间件:

public static IDispatcherBuilder UseLogger(this IDispatcherBuilder builder) =>

    builder.ServiceProvider.GetService(typeof(ILogger<LoggerMiddleware>)) is ILogger logger ?

        builder.Use(next => new LoggerMiddleware(next, logger)) :

        throw new InvalidOperationException(

            $"Could not find service of type '{nameof(ILogger<LoggerMiddleware>)}' in the service container.");

我们建议在创建自己的标准中间件时遵循相同的模式,并为 Router 和 IDispatcherBuilder 提供使用扩展方法。

通常不鼓励在运行时调用 DI 容器—它是反模式的服务定位器。在这里,应该将 UseLogger 扩展方法视为不受此规则约束的基础设施代码。

具有注入服务的中间件

DI 容器注入的服务来创建与其他中间件和叶片调度器通信的中间件,而不是提供标准的中间件。

DI 友好的中间件需要实现以下 IMiddleware 接口之一:

IMiddleware<TDep>
IMiddleware<TDep1, TDep2>
IMiddleware<TDep1, TDep2, TDep3>

例如,我们希望以更适合 DI 的方式，重新实施截止日期中间件。标准截止日期中间件读取截止日期字段，并创建截止日期功能,以将此截止日期传达给，下游中间件和叶片调度程序。新的 DI 友好截止日期中间件，解码截止日期并将此信息，保存在注入的 scoped 服务中:

// Configured as a scoped service in the composition root of the application.

public class DeadlineInformation

{

    public DateTime Value { get; set; } = DateTime.MinValue; // MinValue means no deadline.

}

...

// New DI-friendly deadline middleware. Note that it does not implement IDispatcher.

public class DIDeadlineMiddleware : IMiddleware<DeadlineInformation>

{

    private readonly IDispatcher _next;

    // A constructor with an IDispatcher parameter is required for auto-wiring.

    public DIDeadlineMiddleware(IDispatcher next) => _next = next;

    // deadlineInfo is a scope service provided by the DI container.

    public ValueTask<OutgoingResponse> DispatchAsync(

        IncomingRequest request,

        DeadlineInformation deadlineInfo,

        CancellationToken cancellationToken)

    {

        // Decode the deadline field as usual.

        DateTime deadline = request.Fields.DecodeValue(

            RequestFieldKey.Deadline,

            (ref SliceDecoder decoder) => decoder.DecodeTimeStamp());

        if (deadline != DateTime.MinValue)

        {

            // If deadline is not MinValue, store it in deadlineInfo

            deadlineInfo.Value = deadline;

            // TODO: enforce deadline while calling _next.DispatchAsync.

        }

        else

        {

            // Call _next.DispatchAsync as usual.

            return _next.DispatchAsync(request, cancellationToken);

        }

    }

}

如果使用 Microsoft 的 DI 容器,可以使用 IceRpc.Extensions.DependencyInjection 组件提供的 UseMiddleware 扩展方法安装此中间件:

using IceRpc.Extensions.DependencyInjection;

using Microsoft.Extensions.DependencyInjection;

...

// The DIDeadlineMiddleware is instantiated and managed by the DI container.

services.AddIceRpcDispatcher(

    builder => builder

        .UseLogger()

        .UseMiddleware<DIDeadlineMiddleware>()

        .Map<IGreeterService>());

// To be registered as a transient or scoped service in the DI container.

[SliceService]

internal partial class Chatbot : IGreeterService

{

    // DeadlineInformation is auto-wired by the DI container.

    internal Chatbot(DeadlineInformation deadlineInfo)

    {

        ...

    }

    ...

}

调用管道与DI

了解如何使用 DI 容器构建调用管道。

DI 容器构建调用管道

与调度管道不同,调用管道在有或没有 DI 容器的情况下几乎相同。这是因为调用没有自然的 DI 范围: DI 作用域内执行调用,则该作用域来自另一个封闭活动,例如进行此调用的调度。

IceRPC [C#] 不会为 DI 范围内的调用提供任何特殊支持。特别是 IMiddleware 没有拦截器对应物。

使用 Microsoft 的 DI 容器构建调用管道

可以调用 AddIceRpcInvoker 将新的调用器（调用管道）单例添加到您的 DI 容器中。

例如:

// Construct an invocation pipeline using Microsoft's DI container.

using IceRpc.Extensions.DependencyInjection;

using Microsoft.Extensions.DependencyInjection;

...

// Add a new IInvoker singleton configured with an action.

services

    .AddIceRpcClientConnection()

    .AddIceRpcInvoker(builder => builder.Into<ClientConnection>())

必须使用 Into 方法指定最终调用器。通过此示例,新调用器流入我们之前配置的 ClientConnection 单例。

在 `IInvokerBuilder` 中安装拦截器

所有使用 IceRPC 发送的拦截器都可以在有或没有 DI 的情况下使用,并使用调用中的通信 features 。例如,重试拦截器使用 IServerAddressFeature 与连接缓存通信,以协调复制服务器上的重试。

这些拦截器可以安装在管道或 IInvokerBuilder 中。

例如:

// Construct an invocation pipeline using Microsoft's DI container.

using IceRpc.Extensions.DependencyInjection;

using Microsoft.Extensions.DependencyInjection;

...

// Add a new IInvoker singleton configured with an action.

services

    .AddIceRpcClientConnection()

    .AddIceRpcInvoker(builder =>

        builder

            .UseLogger()

            .Into<ClientConnection>())

UseLogger 方法的实现只是从 DI 容器中检索一个记录器实例, 然后用这个实例创建一个新的拦截器:

public static IInvokerBuilder UseLogger(this IInvokerBuilder builder) =>

    builder.ServiceProvider.GetService(typeof(ILogger<LoggerInterceptor>)) is ILogger logger ?

        builder.Use(next => new LoggerInterceptor(next, logger)) :

        throw new InvalidOperationException(

            $"Could not find service of type '{nameof(ILogger<LoggerInterceptor>)}' in the service container.");

我们建议在创建自己的拦截器时遵循相同的模式,并为 Pipeline 和 IInvokerBuilder 提供使用扩展方法。