如何以恰当方式向具体仓储类传递特定信息？

我完全理解你的顾虑——工厂模式的核心职责是创建对象，如果把特定仓储的参数（比如CsvRepository的路径）硬塞进工厂方法里，确实会让工厂的职责变得模糊，后续添加新仓储时还得修改工厂逻辑，违反开闭原则。下面给你几个实用的方案，既能保持工厂的单一职责，又能优雅地给CsvRepository传递路径参数：

方案1：让仓储从外部配置源自行获取参数 #

这是最解耦的方式——让CsvRepository自己负责读取所需的路径，而不是通过工厂传递。比如你可以用配置文件、环境变量，或者注入一个配置服务：

// 定义仓储接口
public interface IRepository
{
    void SaveData(List<Data> data);
}

// CsvRepository 自行读取配置
public class CsvRepository : IRepository
{
    private readonly string _filePath;

    public CsvRepository(IConfiguration configuration)
    {
        // 从配置服务读取路径
        _filePath = configuration.GetValue<string>("CsvSettings:FilePath");
    }

    public void SaveData(List<Data> data)
    {
        // 写入CSV逻辑
    }
}

// SqlRepository 不需要额外参数
public class SqlRepository : IRepository
{
    public void SaveData(List<Data> data)
    {
        // 写入SQL逻辑
    }
}

// 工厂类只负责创建实例，不处理参数
public class RepositoryFactory
{
    private readonly IServiceProvider _serviceProvider;

    // 注入服务容器，用于获取依赖
    public RepositoryFactory(IServiceProvider serviceProvider)
    {
        _serviceProvider = serviceProvider;
    }

    public IRepository GetRepository(string type)
    {
        return type switch
        {
            "csv" => _serviceProvider.GetRequiredService<CsvRepository>(),
            "sql" => _serviceProvider.GetRequiredService<SqlRepository>(),
            _ => throw new ArgumentException("Invalid repository type")
        };
    }
}

这种方式下，工厂完全不用关心仓储的参数需求，所有依赖都由依赖注入容器处理，职责非常清晰。

方案2：使用配置对象传递差异化参数 #

如果不想依赖配置服务，你可以定义一个通用配置基类，让不同的仓储配置继承它，工厂只负责把配置传递给对应的仓储：

// 通用仓储配置基类
public abstract class RepositoryConfig { }

// Csv专属配置
public class CsvRepositoryConfig : RepositoryConfig
{
    public string FilePath { get; set; }
}

// 仓储接口保持不变
public interface IRepository
{
    void SaveData(List<Data> data);
}

public class CsvRepository : IRepository
{
    private readonly string _filePath;

    // 构造时接收专属配置
    public CsvRepository(CsvRepositoryConfig config)
    {
        _filePath = config.FilePath ?? throw new ArgumentNullException(nameof(config.FilePath));
    }

    public void SaveData(List<Data> data)
    {
        // 写入CSV逻辑
    }
}

public class SqlRepository : IRepository
{
    // 不需要配置，直接构造
    public SqlRepository() { }

    public void SaveData(List<Data> data)
    {
        // 写入SQL逻辑
    }
}

// 工厂方法接收配置对象，按需传递
public class RepositoryFactory
{
    public IRepository GetRepository(string type, RepositoryConfig config = null)
    {
        return type switch
        {
            "csv" => new CsvRepository(config as CsvRepositoryConfig ?? throw new ArgumentException("Csv repository requires CsvRepositoryConfig")),
            "sql" => new SqlRepository(),
            _ => throw new ArgumentException("Invalid repository type")
        };
    }
}

// 使用方式
var factory = new RepositoryFactory();
var csvRepo = factory.GetRepository("csv", new CsvRepositoryConfig { FilePath = "./data.csv" });

这里工厂只是传递配置，而不是处理具体的参数细节，既满足了CsvRepository的参数需求，又没有让工厂承担额外职责。

方案3：创建仓储时延迟初始化参数 #

如果你的场景不适合提前准备配置，也可以给CsvRepository加一个初始化方法，工厂返回实例后再设置参数：

public class CsvRepository : IRepository
{
    private string _filePath;

    // 初始化方法
    public void Initialize(string filePath)
    {
        _filePath = filePath ?? throw new ArgumentNullException(nameof(filePath));
    }

    public void SaveData(List<Data> data)
    {
        if (string.IsNullOrEmpty(_filePath))
            throw new InvalidOperationException("CsvRepository not initialized with file path");
        // 写入CSV逻辑
    }
}

// 工厂使用方式
var factory = new RepositoryFactory();
var csvRepo = factory.GetRepository("csv") as CsvRepository;
csvRepo?.Initialize("./data.csv");

不过这种方式需要额外的类型转换，而且存在未初始化的风险，适合简单场景使用。

个人最推荐方案1，它完全遵循单一职责原则，且扩展性最好——后续添加新的仓储类时，工厂不需要做任何修改，只需要在依赖注入容器中注册即可。

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