c# - 如何使用每个实现的附加参数/信息实现接口(interface)

Question

我的 MVC webapp 允许用户添加和删除图像。 UI 在我的业务层中调用 ImageService.SaveImage(...)，它在内部使用一个标志来告诉方法保存到 Azure 或文件系统。我最终可能会将 S3 添加到我认为这里的接口(interface)会很好用。

这就是我想象中的代码在我的 ImageService 类中的样子。它不关心文件的保存方式或位置。

// Service the UI uses
public static class ImageService
{
    public static void SaveImage(byte[] data, IImageProvider imageProvider)
    {
        string fileName = "some_generated_name.jpg"
        imageProvider.Save(fileName, data);
    }
}

所以我创建了这些实现

public interface IImageProvider
{
    void Save(string filename, byte[] imageData);
    byte[] Get(string filename);
    void Delete(string filename);
}

// File system implementation
public class FSImageProvider : IImageProvider
{
    public void Delete(string filename)
    {
        File.Delete(filename);
    }

    public byte[] Get( filename)
    {
        return File.ReadAllBytes(filename);
    }

    public void Save(string filename, byte[] imageData)
    {
        File.WriteAllBytes(filename, imageData);
    }
}

// Azure implementation
public class AzureBlobImageProvider : IImageProvider
{
    private string _azureKey = "";
    private string _storageAccountName = "";

    public AzureBlobImageProvider(string azureKey, string storageAccount)
    {
        _azureKey = azureKey;
        _storageAccountName = storageAccount;
    }

    public void Delete(string filename)
    {
        throw new NotImplementedException();
    }

    public byte[] Get(string filename)
    {
        throw new NotImplementedException();
    }

    public void Save(string filename, byte[] imageData)
    {
        throw new NotImplementedException();
    }
}

问题 1) 传递每个提供商可能需要的附加信息的最佳方式是什么？ IE。 Azure 需要知道容器名称、blob 名称(文件名)和 storageAccount 名称。 S3 可能还需要更多。一个很好的例子是文件路径。这对于每个提供商可能不同，或者根本不存在。 Azure 需要一个容器名称，文件系统需要一个目录名称。如果它们对于每个提供商都不同，我该如何将其添加到界面中？

问题2)我应该在业务层的ImageService类中使用依赖注入(inject)来解析接口(interface)，还是应该在UI中解析并传递给类？

Answer 1

首先，将 IImageProvider 传递给 SaveImage 方法存在重大的体系结构缺陷。在需要跨方法控制 IImageProvider 的生命周期的情况下，您需要这种函数签名。在你的情况下，你只是保存图像并且几乎不关心任何类的任何生命周期，但仍然使用这种方法并且它最终会使你的代码困惑，呃 - 你甚至不特别关心这个提供者(这就是为什么你将它包装到我认为的界面中)

问问自己:

"Is my IImageProvider actually used anywhere outside of ImageService? If not, why everyone (methods, classes) need to even know about it's existance?"

其次，不是创建提供者 - 使您的 ImageService 简单类(删除静态)，为其定义接口(interface)，并为 Azure/FS/等实现。具体实现使用工厂:

public interface IImageService
{
    void SaveImage(byte[] bytes);
}

public interface IImageServiceFactory
{
    IImageService Create(/*here goes enum, string, connections strings, etc*/);
}


internal sealed class AzureImageService : IImageService {/*implmentation*/}
internal sealed class FileSystemImageService : IImageService {/*implmentation*/}

总体

不要在方法中传递依赖关系。您的方法应该看起来简单，没有任何杂乱无章，例如 ILogger、IImageProvider 等您认为可以传递给内部的方法。如果您在某些实现中的某个时刻需要它们 - 只需创建类，它通过构造函数获取所需的所有依赖项(因此 static 修饰符几乎总是被禁止并且仅用于语言扩展)。您可以更轻松地管理您的依赖项并重构您的代码，而不会在甚至不需要的地方不断重复使用相同的界面而造成任何间接损害。