很高兴啊，我们来到了IceRPC之依赖注入>快乐的RPC，基础引导，打好基础，才能让自已不在迷茫，快乐的畅游世界。
了解 IceRPC (C#) 如何为依赖注入（DI）提供支持。
DI的第一条规则是:不要引入对DI的依赖。
IceRPC (C#) 将此规则放首要位置上,即为 DI 提供全方位支持,同时使此支持完全可选。
IceRPC C# API 被设计为可选 DI 容器。此外,IceRPC 还提供支持代码来帮助大家，在 Microsoft's DI container中使用 IceRPC。.
IceRPC 提供的所有与 DI 相关的 API 都在同一个命名空间中, IceRpc.Extensions.DependencyInjection, 但由多个组件实现:
IDispatcherBuilder和IInvokerBuilder IceRpc.Deadline.dll之类的抽象以及其他拦截器/中间件组件，为IDispatcherBuilder和IInvokerBuilder提供了扩展方法。这些扩展方法与 DI 容器无关。IServiceCollection 的各种扩展方法,例如 AddIceRpcServer 和 AddIceRpcClientConnection,以及 IDispatcherBuilder 和 IInvokerBuilder 的实现。了解如何使用 DI 容器构建调度管道。
传统的调度管道相当静态: 创建路由、添加一些中间件、在此路由中映射或安装少量叶片调度程序,然后让服务器将传入的请求调度到此路由。
叶片调度程序（通常是 Slice 服务）被映射或安装在固定路径（例如/greeter 或/admin/greeter-manager）。 这些调度程序是单例（或类似单例）,其使用寿命与路由和服务器相同。
调度管道中的中间件使用以下features相互通信: 上游中间件设置下游中间件可以检索的features。叶片调度程序还可以使用相同的features与这些中间件进行通信。
这对于许多应用程序来说都很有效。然而,这并不是使用 DI 时的典型模型。
DI,调度管道通常更具动态性: 一些基础设施代码为每个调度创建唯一的 DI 范围,并且叶片调度程序是由 DI 容器管理的服务。当该叶片调度器的生命周期是短暂的或范围化的时,该叶片调度器是按需创建的（每个调度）。
DI 调度管道中的中间件可以像往常一样使用features，与其他中间件和叶片调度器进行通信。然而,更惯用的方法是使用注入服务进行通信。例如:
中间件链本身是静态的: 每个调度不会创建新的中间件实例。中间件通常是由 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 将此范围传输到下游调度程序。
标准中间件是可以与 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 作用域内执行调用,则该作用域来自另一个封闭活动,例如进行此调用的调度。
IceRPC [C#] 不会为 DI 范围内的调用提供任何特殊支持。特别是
IMiddleware没有拦截器对应物。
可以调用 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 是 IceRpc.Logger 组件提供的扩展方法。 此扩展方法适用于实现 IServiceProvider 的任何 DI 容器,例如 Microsoft 的 DI 容器和 Simple Injector 的容器。
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 提供使用扩展方法。
通常不鼓励在运行时调用 DI 容器—它是反模式的服务定位器。在这里,应该将
UseLogger扩展方法视为不受此规则约束的基础设施代码。
最近写的都是基础相关的概念，大家看看就行，以官方为主更为妙哉。
