学习代码重构：如何避免传递IConfiguration与IHostingEnvironment？

你现在遇到的问题本质是硬依赖导致的耦合——手动new Emailer()需要你手动传递它的所有依赖，这不仅麻烦，还会让代码难以维护和测试。在.NET生态里，依赖注入（DI）是解决这类问题的标准方案，能彻底帮你摆脱到处传递IConfiguration和IHostingEnvironment的窘境。

步骤1：确保依赖已注册到DI容器 #

首先，你需要把Emailer和它的接口ISender注册到.NET的DI容器中。容器会自动管理所有依赖的创建和传递：

• 如果你用的是.NET 6+（顶级Program.cs）：

// Program.cs
var builder = WebApplication.CreateBuilder(args);

// 注册ISender的实现类Emailer，DI会自动解析它需要的IConfiguration和IHostingEnvironment
// （这两个依赖默认已经被框架注册到容器里了，不用额外手动加）
builder.Services.AddScoped<ISender, Emailer>();

• 如果你用的是.NET Core 3.x或更早版本（Startup.cs）：

// Startup.cs
public void ConfigureServices(IServiceCollection services)
{
    services.AddScoped<ISender, Emailer>();
    // 其他服务注册...
}

步骤2：在PasswordReset中通过构造函数注入依赖 #

接下来，修改PasswordReset类，不要手动new Emailer，而是通过构造函数注入ISender接口。DI容器会自动把已经配置好的Emailer实例（带着它需要的IConfiguration和IHostingEnvironment）传递进来：

namespace app.Notifications {
    public class PasswordReset : INotification {
        // 用readonly字段保存注入的依赖，确保不会被修改
        private readonly ISender _emailer;

        // 构造函数注入ISender
        public PasswordReset(ISender emailer) {
            _emailer = emailer;
        }

        // 之后你就可以在类里直接使用_emailer了
        public void SendResetLink() {
            _emailer.Send(...);
        }
    }
}

步骤3：确保PasswordReset本身也被DI管理（可选但推荐） #

如果PasswordReset也是一个需要被框架调用的服务（比如在控制器里使用），最好也把它注册到DI容器中：

// Program.cs/Startup.cs
builder.Services.AddScoped<INotification, PasswordReset>();

之后在需要使用PasswordReset的地方（比如控制器），同样通过构造函数注入INotification即可，DI会自动完成整个依赖链的解析。

为什么这能解决问题？ #

• 解耦：PasswordReset现在只依赖抽象的ISender，而不是具体的Emailer，后续如果要替换成其他发送方式（比如短信Sender），只需要替换实现类，不用修改PasswordReset的代码。
• 自动传递依赖：DI容器会负责创建Emailer并自动注入它需要的IConfiguration和IHostingEnvironment，你完全不用手动传递这些对象。
• 易于测试：在单元测试中，你可以给PasswordReset传入一个Mock的ISender，不用配置真实的IConfiguration或IHostingEnvironment。

内容的提问来源于stack exchange，提问作者bebo925