c# - IFile RepositoryProvider 处理上传的文件

Question

根据我们的系统所在的环境，它将使用不同的“文件系统”来管理用户上传的文件。例如，在我们的开发环境中，我们使用 Windows 文件系统，但在生产环境中，我们使用 Azure blob 存储。

使用提供者模型，我创建了以下接口(interface):

public interface IFileRepositoryProvider
{
    void SaveFile(string fileName, Stream fileStream);

    void DeleteFile(string fileName);

    bool Exists(string fileName);

    Stream GetStream(string fileName);
}

• 如何保存/删除文件等的详细信息完全由 IFileRepositoryProvider 的具体实现封装。
• Azure Blob 存储存在一些限制。我不一定能为文件提供直接的“URI”，就像它托管在 Web 服务器上的某个虚拟目录中一样。 出于这个原因，我决定完全使用流。由客户端代码根据需要处理流。

问题:

• FileStream 还是 MemoryStream 更好？
• 将文件公开为字节数组有好处吗？
• 您能看出这种方法有什么严重的缺点吗？

Answer 1

您是否使用 FileStream 或 MemoryStream 或其他流类型并不重要；您的界面应该只接受 Stream，然后可以处理各种不同的输入。

我想说流比字节数组更灵活。不过，需要注意的一件事是，在将流传递到界面之前，您通常必须记住在流上设置position=0。

您还应该考虑异步以及是否要处理正确的流 - 即写入 Azure Blob 存储，同时仍然从客户端接收数据(这对于 Azure 存储 API 的工作方式可能有点棘手)。

我要说的一件事是，您的界面看起来就像您试图使 Azure blob 存储表现得像文件系统一样，重点是文件名。 Azure Blob 存储对于文件的名称有一定的限制；本质上，您的“名称”需要进行 URI 编码。我发现更好的方法是接受 Azure Blob 存储有效地处理标识符的想法，然后尝试在文件系统上模拟它。因此，当您“保存”文件时，您将传入一个名称和一个流，并将返回一个字符串，该字符串是一个标识符(它实际上是一个 URI 或 URI 的一部分)。客户端必须存储该标识符，并且在想要检索文件时必须提供该标识符。

这样做的另一个好处是您的实现负责生成标识符，因此可以在标识符中包含 Guid 以避免任何名称冲突。

最后，如果您计划在 Azure Blob 存储中存储大量文件，您应该意识到浏览速度很慢并且几乎无法搜索。因此，为了让支持变得更容易，请仔细考虑如何构建标识符。虽然从技术上讲 Blob 存储是扁平的，但您可以通过在标识符中包含“/”来模拟文件夹结构。因此，例如，您可以创建一个标识符，例如年+“/”+月+“/”+日+“/”+guid+'/'+Uri.Encode(filename)。或者您可以在标识符中包含一些上下文特定信息。