自定义依赖SDK初始化咨询：ProductService如何初始化SDK1与SDK2？

先明确你的依赖链路：

• ProductService 依赖 SDK1
• SDK1 依赖 SDK2
• SDK1Service 构造依赖 SDK1Interface1（实现类SDK1Class1）、SDK1Interface2（实现类SDK1Class2）、SDK2Interface3（实现类SDK2Class3）
• SDK2Service 构造依赖 SDK2Interface3、SDK2Interface4（实现类SDK2Class4）

下面逐个分析三个候选方案的优劣：

方案1：在ProductService的Program.cs中通过依赖注入完成初始化 #

这是最推荐的方案，完全契合依赖注入的设计原则：

• 所有接口与实现类都在顶层DI容器中注册，ProductService只需声明依赖SDK1Service，无需关心底层SDK的初始化细节
• 以.NET为例，注册逻辑示例：

// 注册SDK2的依赖
builder.Services.AddScoped<SDK2Interface3, SDK2Class3>();
builder.Services.AddScoped<SDK2Interface4, SDK2Class4>();
builder.Services.AddScoped<SDK2Service>();

// 注册SDK1的依赖
builder.Services.AddScoped<SDK1Interface1, SDK1Class1>();
builder.Services.AddScoped<SDK1Interface2, SDK1Class2>();
builder.Services.AddScoped<SDK1Service>();

// 注册ProductService
builder.Services.AddScoped<ProductService>();

• 优化点：如果依赖关系复杂，可以把SDK1、SDK2的注册逻辑封装成扩展方法，让Program.cs保持简洁：

// 封装后的注册代码
builder.Services.AddSdk2();
builder.Services.AddSdk1();
builder.Services.AddProductService();

• 优点：职责清晰，ProductService专注自身业务，依赖的生命周期、实例创建由DI容器统一管理，便于后续替换实现类、编写单元测试（可轻松注入Mock）
• 缺点：注册代码会随依赖增多变长，但通过扩展方法可以完美解决

方案2：使用工厂模式初始化SDK1 #

这个方案适合SDK1存在复杂初始化逻辑（比如根据环境配置动态创建实例）的场景：

• 定义SDK1Factory类，专门负责SDK1Service的实例创建，在工厂内部处理SDK1及依赖SDK2的初始化：

public class SDK1Factory
{
    public SDK1Service Create()
    {
        // 初始化SDK2依赖
        var sdk2Interface3 = new SDK2Class3();
        var sdk2Interface4 = new SDK2Class4();
        _ = new SDK2Service(sdk2Interface3, sdk2Interface4);

        // 初始化SDK1依赖
        var sdk1Interface1 = new SDK1Class1();
        var sdk1Interface2 = new SDK1Class2();

        return new SDK1Service(sdk1Interface1, sdk1Interface2, sdk2Interface3);
    }
}

• 之后在ProductService中注入SDK1Factory，调用Create()获取实例即可
• 优点：把SDK1的初始化逻辑封装到工厂，ProductService无需关注细节；支持多场景的实例创建（比如提供多个重载的Create方法）
• 缺点：手动创建实例会丢失DI容器的优势（比如自动生命周期管理、依赖自动注入），后续依赖变更时，工厂代码需要同步修改，灵活性不如DI方案

方案3：在SDK1中编写SDK2的初始化逻辑 #

这个方案确实是反模式，核心问题如下：

• 违反单一职责原则：SDK1的核心职责是提供自身业务能力，不应该承担依赖SDK2的初始化工作
• 强耦合：SDK1与SDK2绑定过紧，SDK2的依赖变更会直接影响SDK1；如果其他服务仅需SDK1，也会被迫初始化SDK2
• 失去灵活性：无法在不同场景下替换SDK2的实现（比如单元测试时无法注入Mock）

最终推荐 #

优先选择方案1，通过扩展方法封装SDK注册逻辑，兼顾简洁性与规范性。如果SDK1有特殊的动态初始化需求，可以结合方案2的工厂模式，但建议基于DI容器实现工厂（比如在工厂中注入服务提供者，而非手动创建实例），平衡灵活性与封装性。

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