如何为图片存储接口的不同实现传递额外参数/信息？

针对你这个用接口解耦图片存储实现（Azure、文件系统、未来的S3）、需要给不同实现传递额外参数的场景，我整理了几个实用的方案，你可以根据参数的类型和使用场景来选择：

1. 依赖注入时通过配置类传递静态初始化参数 #

如果参数是启动时就确定、全局通用的（比如Azure的连接字符串、文件系统的根存储路径、S3的区域信息），最优雅的方式是给每个存储实现对应一个配置类，然后通过依赖注入把配置注入进去。

举个代码例子：
首先定义接口和配置类：

// 核心存储接口
public interface IImageStorageProvider
{
    Task SaveImageAsync(Stream imageStream, string imageName);
}

// Azure存储的配置类
public class AzureStorageConfig
{
    public string ConnectionString { get; set; }
    public string ContainerName { get; set; }
}

// 文件系统存储的配置类
public class FileSystemStorageConfig
{
    public string RootPath { get; set; }
}

然后实现Azure存储类，构造函数接收配置：

public class AzureImageStorageProvider : IImageStorageProvider
{
    private readonly AzureStorageConfig _config;

    public AzureImageStorageProvider(IOptions<AzureStorageConfig> config)
    {
        _config = config.Value;
    }

    public async Task SaveImageAsync(Stream imageStream, string imageName)
    {
        // 使用_config里的ConnectionString和ContainerName来操作Azure Blob
        // ...具体实现
    }
}

最后在Startup/Program.cs里注册配置和服务：

// 绑定配置文件中的Azure存储配置
builder.Services.Configure<AzureStorageConfig>(builder.Configuration.GetSection("AzureStorage"));
// 注册Azure存储实现
builder.Services.AddScoped<IImageStorageProvider, AzureImageStorageProvider>();

// 文件系统存储同理
builder.Services.Configure<FileSystemStorageConfig>(builder.Configuration.GetSection("FileSystemStorage"));
builder.Services.AddScoped<IImageStorageProvider, FileSystemImageStorageProvider>();

这种方式的好处是配置集中管理，存储实现不用关心配置来源，完全符合依赖倒置原则。

2. 调用时通过参数对象传递动态参数 #

如果有些参数是每次调用都可能变化的（比如用户指定的存储目录、S3的存储类别、Azure的Blob访问层级），可以定义一个通用的参数基类，让每个存储实现根据自己的需求继承扩展。

示例代码：

// 通用参数基类
public abstract class StorageOperationParameters { }

// Azure专属参数
public class AzureStorageParameters : StorageOperationParameters
{
    public string BlobName { get; set; }
    public PublicAccessType AccessType { get; set; }
}

// 文件系统专属参数
public class FileSystemStorageParameters : StorageOperationParameters
{
    public string SubDirectory { get; set; }
}

// 更新接口方法
public interface IImageStorageProvider
{
    Task SaveImageAsync(Stream imageStream, StorageOperationParameters parameters);
}

然后在ImageService里，根据当前要使用的存储类型，创建对应的参数对象传递：

public class ImageService
{
    private readonly IImageStorageProvider _currentProvider;

    public ImageService(IImageStorageProvider currentProvider)
    {
        _currentProvider = currentProvider;
    }

    public async Task SaveImageAsync(Stream imageStream, string imageName, bool isPublic)
    {
        if (_currentProvider is AzureImageStorageProvider)
        {
            var @params = new AzureStorageParameters
            {
                BlobName = imageName,
                AccessType = isPublic ? PublicAccessType.Blob : PublicAccessType.None
            };
            await _currentProvider.SaveImageAsync(imageStream, @params);
        }
        // 其他存储类型同理
    }
}

这种方式适合处理动态变化的参数，保证了接口的通用性，同时每个实现能拿到自己需要的专属信息。

3. 利用上下文对象传递请求级别的上下文信息 #

如果需要传递的是请求上下文相关的信息（比如当前用户ID、请求ID、租户ID），可以定义一个上下文接口，通过依赖注入的Scoped生命周期传递。

示例代码：

// 存储上下文接口
public interface IStorageContext
{
    string CurrentUserId { get; }
    string RequestId { get; }
}

// 基于Http请求的上下文实现
public class HttpStorageContext : IStorageContext
{
    private readonly IHttpContextAccessor _httpContextAccessor;

    public HttpStorageContext(IHttpContextAccessor httpContextAccessor)
    {
        _httpContextAccessor = httpContextAccessor;
    }

    public string CurrentUserId => _httpContextAccessor.HttpContext.User.FindFirst(ClaimTypes.NameIdentifier)?.Value;
    public string RequestId => _httpContextAccessor.HttpContext.TraceIdentifier;
}

然后在存储实现里注入这个上下文：

public class FileSystemImageStorageProvider : IImageStorageProvider
{
    private readonly FileSystemStorageConfig _config;
    private readonly IStorageContext _context;

    public FileSystemImageStorageProvider(IOptions<FileSystemStorageConfig> config, IStorageContext context)
    {
        _config = config.Value;
        _context = context;
    }

    public async Task SaveImageAsync(Stream imageStream, StorageOperationParameters parameters)
    {
        // 用当前用户ID创建专属目录，避免文件冲突
        var userDirectory = Path.Combine(_config.RootPath, _context.CurrentUserId);
        Directory.CreateDirectory(userDirectory);
        // ...保存文件到该目录
    }
}

记得注册上下文服务：

builder.Services.AddHttpContextAccessor();
builder.Services.AddScoped<IStorageContext, HttpStorageContext>();

这种方式适合处理和当前请求绑定的信息，不用在每次调用时手动传递，代码更简洁。

4. 结合策略模式灵活切换实现与参数 #

如果你的ImageService需要根据不同条件动态切换存储实现（比如根据用户等级选Azure还是文件系统），可以结合策略模式，把每个存储实现和对应的参数处理逻辑绑定起来。

示例代码：

// 定义存储类型枚举
public enum StorageType
{
    Azure,
    FileSystem,
    S3 // 未来扩展
}

// 给存储接口添加类型标识
public interface IImageStorageProvider
{
    StorageType Type { get; }
    Task SaveImageAsync(Stream imageStream, StorageOperationParameters parameters);
}

// ImageService中注入所有实现，根据类型切换
public class ImageService
{
    private readonly IDictionary<StorageType, IImageStorageProvider> _providers;

    public ImageService(IEnumerable<IImageStorageProvider> providers)
    {
        _providers = providers.ToDictionary(p => p.Type);
    }

    public async Task SaveImageAsync(Stream imageStream, StorageType storageType, StorageOperationParameters parameters)
    {
        if (_providers.TryGetValue(storageType, out var provider))
        {
            await provider.SaveImageAsync(imageStream, parameters);
        }
        else
        {
            throw new NotSupportedException($"不支持的存储类型：{storageType}");
        }
    }
}

这样ImageService不用关心具体实现的细节，只需要根据传入的存储类型和对应的参数调用即可，后续扩展S3时只需要新增一个实现类和对应的参数类，完全符合开闭原则。

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