c# - 无法解析设置类的依赖注入(inject)

Question

好吧，我显然在这里做了一些愚蠢的事情，但我似乎找不到它。

我正在编写我的第一个 Razor Pages 应用程序并创建了一个 EmailSender 类，它实现了 IEmailSender。此外，EmailSender 构造函数接受一个 EmailSettings 参数。 EmailSettings 实现如下。

appsettings.json

"EmailSettings": {
  "Host": "****.*****.com",
  "Port": "587",
  "UserName": "****@**********.com",
  "Password": "***********",
  "FromAddress": "****@**********.com",
  "EnableSsl": "true"
},

EmailSettings.cs

public class EmailSettings
{
    public string Host { get; set; }
    public int Port { get; set; }
    public string UserName { get; set; }
    public string Password { get; set; }
    public string FromAddress { get; set; }
    public bool EnableSsl { get; set; }
}

Startup.cs

public void ConfigureServices(IServiceCollection services)
{

    // ...

    services.Configure<EmailSettings>(Configuration.GetSection("EmailSettings"));
    services.AddSingleton<IEmailSender, EmailSender>();
}

这遵循了 article I read 中的基本方法.但是当我运行该应用程序时，我立即遇到异常:

System.AggregateException: 'Some services are not able to be constructed (Error while validating the service descriptor 'ServiceType: Microsoft.AspNetCore.Identity.UI.Services.IEmailSender Lifetime: Transient ImplementationType: Bamtok.Services.EmailSender': Unable to resolve service for type 'Bamtok.Services.EmailSettings' while attempting to activate 'Bamtok.Services.EmailSender'.)'

不知何故，它无法实例化 EmailSettings 实例以传递给 EmailSender 构造函数。

谁能看到我错过了什么？

Answer 1

Configure<T>寄存器 IOptions<EmailSettings>并且，正如您所说，您注入(inject)了 EmailSettings进入依赖类。

您可以保留该类并重构 Startup

public void ConfigureServices(IServiceCollection services) {

    // ...

    EmailSettings settings = Configuration.GetSection("EmailSettings").Get<EmailSettings>();
    services.AddSingleton(settings);
    services.AddSingleton<IEmailSender, EmailSender>();
}

或者更新类以期待IOptions<T>依赖

public class EmailSender : IEmailSender {
    private readonly EmailSettings emailSettings;

    public EmailSender(IOptions<EmailSettings> emailSettings) {
        this.emailSettings = emailSettings.Value;
    }

    //...
}

前者与后者建议的区别在于实现不会与框架问题耦合。