如何使用 Microsoft.Extension.DependencyInjection 允许可选服务？

Question

我在自己的爱好项目中使用 ASP.NET Core，我想创建一个可供开发人员使用的框架，并且我想允许可选服务并在未注册的情况下使用默认值。

我收到Unable to resolve service for type 'XXX' 错误，但我希望 DI 返回null 而不是抛出异常。 我想允许可选服务，所以如果找到服务，在构造函数中使用它，如果没有找到，将 null 传递给构造函数。

在我的实现中，我有：

public IServiceManager(IService service, ...)
{
    _service = service ?? new DefaultService();
    ...
}

如您所见，如果找不到服务（null），则使用默认值。 也许我误解了 DI 的工作原理。也许我可以使用工厂来代替？ 但是，在我的系统中，我在未提供时使用默认服务是很常见的，因此我需要一个不需要 API 使用者注册服务的解决方案。

有没有办法将 ASP.NET Core DI 配置为返回 null 而不是抛出异常？

Answer 1

在构造函数中为该参数添加默认值。

public IServiceManager(IService service = null, ...)
{
  _service = service ?? new DefaultService();
  ...
}

Answer 2

就其本质而言，构造函数注入始终被认为是强制性的。

Microsoft DI 的第一个版本（我不喜欢使用术语 ASP.NET Core DI，因为它不依赖于 ASP.NET Core 并且可以在它之外使用）仅支持带有大多数参数。

我认为从那时起，这已被更改为允许多个构造函数，并且 IoC 容器将选择一个合适的构造函数。话虽如此，您可能需要定义多个构造函数。

public IServiceManager(IService service, IOtherService otherService)
{
}

public IServiceManager(IOtherService otherService)
{
}

如果IService 未在 IoC 容器中注册，则应调用第二个构造函数。

但这充其量仍然是一个非常值得怀疑的做法，并且会使您的代码更难维护并保持其不变/松散耦合。

您永远不必在服务中实例化您的类型，即使是可选服务也是如此。

相反，您应该提供允许用户使用自己的实现覆盖它们的注册。

public static IServiceCollection AddMyLibrary(this IServiceCollection services)
{
    services.TryAddTransient<IService, Service>();
    services.TryAddTransient<IOtherService, OtherService>();
}

然后用户覆盖它。

services.AddTransient<IService, CustomService>();
services.AddMyLibrary();

现在CustomService 将被注入到请求IService 的地方。

Answer 3

最简单的方法是在 IoC 容器中为 IService service 注册 DefaultService component 本身 - 我使用的是 Castle Windsor 的术语。大多数容器允许为一个服务注册多个组件。如果您没有为服务注册自定义组件（IService 的另一种实现），则会解析并注入 DefaultService；否则您的自定义组件将被解析为服务，只需按正确顺序注册组件（在 Castle Windsor 中，将考虑首先注册的组件：multiple components for a service）

WindsorContainer container = new WindsorContainer();

container.Register(Component.For<IServiceManager>().ImplementedBy<ServiceManager>());
container.Register(Component.For<IService>().ImplementedBy<CustomService>());
container.Register(Component.For<IService>().ImplementedBy<DefaultService>());

IServiceManager serviceManager = container.Resolve<IServiceManager>();
IService service = ((ServiceManager)serviceManager).Service; // service is of type CustomService

关于@Tseng 的以下评论：

当您在构造函数中对其进行实例化时，这击败了首先拥有依赖注入/IoC 容器的想法

并非总是如此...如果您有一个可选依赖项，首先，将其定义为具有公共设置器的属性，以便可以注入组件如果注册。如果没有注册组件（因此容器未设置属性），我认为通过“危险”新关键字实例化默认组件是可以接受的。一切都取决于上下文 - 明确地说，我不会手动实例化服务，但总会有例外。