我会试着解决这个问题。我们有一个类似的应用程序，我们采用了自己的方法。用户可以通过我们的应用程序界面上传文件（图片、文档等），这些文件具有用户/公司/角色敏感权限。为了缓解一些安全问题和其他原因，我们实施了以下措施：
在 Web 应用程序中，我们创建了一个“资源”文件夹，用于存储所有用户生成的内容。然后，我们使用子文件夹来帮助分段内容（标志、文件等）。
在 web.config 中，我们配置了该文件夹不可从浏览器访问（类似于 App_Data 或 bin 文件夹），使用以下代码（我们这样做是为了确保这些文件不能直接从浏览器访问。有关第4点的更多信息，请参见）：
<system.webServer>
<security>
<requestFiltering>
<hiddenSegments>
<add segment="Assets"/>
</hiddenSegments>
</requestFiltering>
</security>
一旦文件上传完成，我们就会将有关该文件的相关信息（类型、大小、名称、注释）存储在数据库中。这也使我们能够将角色和用户安全信息与文件相关联。
为了检索文件，我们实现了一个控制器，其中包含一组操作，它们需要请求的文件名和用户信息（因为您必须登录），并从Assets文件夹返回文件。对于最终用户而言，所有文件都存储在/Files/Docs/FileID或类似位置，但实际上这只是一个前端“门卫”，用于保护文件本身。如果您未经授权或请求错误的文件，则此控制器/操作方法将返回404。对于文件命名，我们只生成GUID，并将文件命名为“GUID.relevantExtension”（检查是否已存在）。
我想，对于教训或其他方面来说，最重要的事情是不要直接暴露文件，特别是如果用户没有共享内容的话。另外，这可能是个人喜好，如果不小心可能会引发争端，我不太喜欢将文件存储在数据库中，因为它似乎会导致分页和缓存性能问题（不是指SQL 2008文件列）。希望这可以帮到您！
编辑- 在进行来自VS的发布时，请注意。这些上传的文件不是您解决方案的一部分，如果您执行删除上传类型的发布，将会影响您的用户文件。只是提醒（我也遇到过这种情况 :/）
我认为你最终会得出“从头开始编写所有内容”的结论。
对于我来说，我有一个“文件”文件夹，然后我为每个用户创建子文件夹，如果有很多类型，我在这个UserFolder子文件夹中为每种数据创建子文件夹。
在我的数据库中，我只存储获取这些文件的“路径”。
如果您使用multipart/form-data的enctype创建表单，则可以在控制器中接收HttpPostedFileBase。
在视图中：
<form action="/MyController/MyAction/" method="post" enctype="multipart/form-data">
在控制器中：
public ActionResult MyAction(HttpPostedFileBase httpPostedFileBase)
{
// 在此处编写您的代码。
}
httpPostedFileBase参数将由默认模型绑定器映射。