我们有一个MVC网络应用程序，它有一个Claim管理向导（类似于典型的Order条目）。声明可以有多个项目，每个项目可以有多个与之相关的文件。
声明 - ＆gt;项目 - ＆gt;文件
添加新版权声明时，我们希望允许用户向其添加一个或多个项目，并允许这些项目的文件上传。但我们希望将所有内容保留在内存中，直到Claim实际保存为止 - 这样，如果用户没有完成Claim条目或丢弃它，则不会进行数据库交互。
我们能够通过会话处理数据级内存管理。我们在会话中序列化Claim对象（它还包括一个Claim.Items属性）。但是如何管理文件？
我们将文件存储在＆lt; ClaimID＆gt; \＆lt; ItemID＆gt;文件夹但在创建新文件时 在记忆中声称我们在记录存在之前没有任何ID 保存在数据库中（两者都是自动增量int）。
目前，我们要限制用户上传文件，直到保存声明为止。
答案 0 :(得分：1)
为什么不与数据库交互？听起来你打算在多个请求之间保持数据到应用程序，数据库对此有好处。
您不必将其持久保存在相同的表中，甚至与更长期的持久数据保持在同一数据库实例中。也许为“瞬态”数据创建表或数据库，或者不打算长期持续直到达到某个状态的数据。或者可能将其存储在与长期数据相同的表中，但也可以跟踪状态以将其标记为“不完整”或以其他方式标记为瞬态。
您可以进行离线处理，不时清理旧数据。如果长期数据表中的删除成本很高，那么这就是将瞬态数据移动到自己的表中的一个很好的理由，针对大量写入/删除进行了优化，而不是随着时间的推移进行大量读取。
或者，您可以使用临时ID作为内存中对象，以便在将其保留到数据库之前将它们与磁盘上的文件相关联。甚至可能将文件关联ID与记录的主ID分开。 （我假设您正在为主键使用自动递增整数，而这是您需要从数据库获取的ID。）
例如，您可以在记录中使用另一个标识符Guid（SQL中为uniqueidentifier），以便将记录链接到磁盘上的文件。这样，您可以在内存中创建标识符并将其持久保存到数据库，而无需最初与数据库交互以生成ID。这还有一个额外的好处，即能够重新关联不同的文件或以其他方式根据需要更改该标识符而不会弄乱密钥。
在许多情况下，Guid不应该用作主键，因此您可能不希望走这条路线。但拥有一个单独的ID可以解决问题。